yuteh.shen's blog

Cassandra Introduction -- data model

Introduction:

With the more and more data insertions and queries from the database, we may face the situation that we need to scale out the architecture by increasing new machines to handle the amount of data. However, in the traditional MySQL database, it needs a lot of work to add a new machine (i.e. shading, we partition the data into different machines). And sometimes only key-value queries are needed instead of JOIN operation. We can't help but think that if there is an alternative solution for database system scalability. By searching on the internet, we find many distributed key-value database are develop for this situation. Among these database systems, Cassandra is a java-based distributed key-value database which is created by Facebook. It is different from MySQL which contains the JOIN operation, Cassandra is good at dealing with the distributed data. You may view the whole cluster as a big hash table with all fault tolerant and data partition are handle by it. It provides "incremental scalability" (which means you can increase throughput by adding new nodes). And Cassandra also supports "Column" feature, it is more convenient than only key-value database systems.

Let me show you the key elements of Cassandra :


Basic key-value database:

Table['key1'] = value1

With Column feature:


Table['Key1']['column family1']['Column1'] = Vaule1


Data Model:

In Cassandra, it can be thought of as a four or five dimensional hash table. From top to bottom, the hierarchy looks like this.



So the query will look like this:

get <ksp>.<cf>['<key>']['<col>']                             Get a column value.
get <ksp>.<cf>['<key>']['<super>']['<col>']              Get a sub column value.



Key Space:

    In Cassandra, you can define many Key Space. You can think it as the Table in MySQL. It contains {Row, [ColumnFamily]} list. Normally one Key Space per application.


Row:

    For row key, you can have data from relative Column Family. The data in each Column Family is sorted according row key's order. The row key does not have to contains data in all column family.

        
Column Family:

    In Column Family, it contains a list of Column or a list of Super Column. You must define it in config before Cassandra start. And each Column Family is stored in a separate file. The number of column in each column family is unlimited.


Column:

    It is the smallest element  of data, and it only contains a name, a value, and a timestamp. You can add new or delete column at anytime.


Super Column:

    Super Column is the container to  contain Columns.


Architecture:

Cassandra use consistent hash to do key distribution and partition. Each node in Cassandra cluster will take a token (0<token<2^32) in the ring. The size of the ring is 2^32. When the key is coming, it will make the md5 hash for the key and find the smallest token which is larger than the key md5. The the key is mapping the correspond node according to the token, so the data will be store in the corresponding node.

Like the following example, the key will be inserted into node 2.


Replicate method:

If you want to store two replicas of data in Cassandra cluster. It will store data in the next two nodes.

Adding a new node:

In consistent hash method, adding a new node will only affect the nodes in neighbors. In this case, we do not need to rehash all data. Some data store in node 1 will now store in new node 4. The new node will choose a token randomly, and find the corresponding location according to the md5 hash. 

Reference:

Gearman Distribute Computing Framework

Introduction:
Today many web services will need to to do some complex work which can cost some computations. As a result, we need some kind of job dispatcher to help us to dispatch jobs. Gearman provides a generic application framework to farm out work to other machines or processes that are better suited to do the work. It allows you to do work in parallel, to load balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events. In other words, it is the nervous system for how distributed processing communicates.

Here are some features about Gearman:

  • load balance
  • Client API: C, PHP, Python, Perl
  • no broadcast feature
  • auto dispatch task
  • persistent queue (sqlite, mysql)
  • client
    • blocking task
    • non-blocking (concurrent multi-task), callback function when complete or fail!
  • worker
    • blocking task handle

Under the following picture, you can see how Gearman works. Your application will use Gearman Client API to send task to Gearman Job Server. The Job Server will find which Worker had low workload, and send the task to the Worker through Gearman Worker API. All communication is through Gearman API, you don’t need to consider any TCP connection. And Client Node, Job Server, and Worker Node can be in different machine.

Job Server fail over:
The Worker and Client need to connect to all Job Server (it’s ok to set 2 or 3 Job Servers). Then if one Job Server fail over, there is still one Job Server remain. The Client can still work.

Cons:
No monitor tool, the cluster monitor tool is still under development.
Reference:
http://gearman.org/
http://blog.flier.lu/2010/04/gearman-performance-tunning/