June 14th - 20th: I have been continuing to work on raftstore as guided by @little-wallace but he has been unable to work with me due to a hectic schedule that he is currently facing at his full time position, thus my GSoC designated mentor @yiwu-arbug has decided to take back charge of my project and will be guiding me in the venture from here on.
June 7th - 13th: As had been discussed in last week's conversations with my mentor @little-wallace, it was noted that I had to focus not on writing an interface with EBS but rather find out locations in the code of components/raftstore
and figure out ways of removing redundant writes made to both KVDB and RaftDB, this was something I had not been clear upon in the first week, but I have started work on reading the details of raftstore::store
, starting with the FSM
module, where there are multiple details that are a bit unclear for me, this is especially due to the fact that I am extremely new to the source-code. I intended to figure out the exact mechanism of write to DB, by further researching through the source code.
I started the coding phase of GSoC with a very simple understanding of the task at hand and have been trying to materialise and better understand the exact implementation details of the project over the past 20 days, ever since @little-wallace provided me with the proposal document. I would like to document the process in a few concise notes that shall later be collected into a memoir/blog.
May 30th - June 6th: Work on coding the EBS integration into TiKV begins with research into rusoto_ec2, a crate that allows for AWS EC2 instance interaction from within rust programs. rusoto_ec2::EbsBlockDevice
is a struct within the mentioned crate of particular importance to the project and it provides an interface for the program with EC2/EBS volumes. Creating a new
I shall be documenting my understanding of the cloud native paradigm of application development as I progree through the learning journey on my way to building a cloud native KV datastore with the TiKV project.
A Cloud Native service espouses the properties of replicability(can be replaced/replicated), disaster recovery and most importantly scalability. A product in this realm is supposed to provide it's users with the ability to create applications that aren't heavily impacted by issues that might come from each service, truly abstracting them from the background details.
According to the CNCF the following definition is valid:
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined
This is an introduction to TiKV, a Key Value Datastore that I have been selected to work on for Google Summer of Code 2020. I am supposed to be making it a cloud native product that espouses the properties of cloud nativity as defined by the Cloud Native Computing Foundation which is the organization I am to work under.
A KV datastore is a much more distributed and scalable version of the Python dictonary or JSON model of key->value data storage. It provides a user with the option to GET or PUT data from/into a database that is semi structured and contains a mapping between the keys and their associated values.
So, I had recently contributed to the malluscript esoteric programming language. It was a quick fix to what I thought was broken, or more aptly, shabbily written piece of code. But even with my edits, it seemed to be smelling foul. So let's experiment with something new to see if it helps!
Here's the code we have at the offset
...
#[derive(Clone, Debug)]
pub struct Keywords {
pub list: HashMap,
Today, while discussing how to lower demand on computing resources while generating the Fibonacci sequence, especially when it is to be queried a lot of times within a program, we came to experiment with memoization. In a simple program by @shanavas786, he implemented memoization with HashMaps, but to make it simpler, and since the concepts are almost the same, I would like to use Vec instead.
The struct
in rust are sort of like classes, they can hold data and associated methods. Let's see how we can arrange the data.
struct Fib {
cache: Vec<u64>
}
Yes, that's it! The objects of Fib
will hold a Vec cache
. But there's more, while we could simply make an object with let seq = Fib { cache: vec![0] };
, that won't help us achieve our goal, we need constructors and methods. To define methods for a struct we impl
, as we do below.
Another use of the match
statement could be to handle termination conditions, this expands on what we discussed on day 1!
Here is a C function that prints the nth term of the fibonacci sequence.
int fibonacci(int n)
{
if(n==0 || n==1) return 1;
else return fibonacci(n - 1) + fibonacci(n - 2);
}
It is common in computing, to come across a conditional statement that contains a lot of ANDs, ORs and more. With rust-lang's powerful match
statement, a programmer can easily convey the message, let's see how.
match
statements takes pattern matching to another level. Using the simple syntax, one can also achieve what nested/ladder if
-else
blocks could. Here is a sample if
-else
code block.
if year%4 == 0 {
if year%100 != 0 || year%400 == 0 {
println!("Leap Year");
} else {
println!("Not a Leap Year");
}
In the last one we wrote and ran our first rust program from scratch, today let's add some code to make much more...
Yes, rust like every other computer program controls the flow or processing of data by using special schemes. Ever heard about the if-else
, while
or for
statements? They are the basics of what most programming languages are trying to achieve, but rust has more!
Yeah, so that's valid rust, considering this
is a boolean(either true
or false
) value as well as that
and what
are variables with the same type as the function is supposed to return.