大資料資料庫儲存-NoSQL比較及效能差異(VII)

在大資料資料庫儲存的最終篇將比較各NoSQL的差異和效能的比較。

NoSQL 比較

Experiment Environment

Hardware and Network Topology

Software Version

MySQL VS Big Data

 Insert Data

 Update Data

Look-up Data

Delete Data

大資料資料庫儲存-Memcache和Redis介紹(VI)

Memcahce和Redis都是大多數被拿來當Cache system用途的NoSQL。他們的共通點是都是以Key-Value的形式將資料存在記憶體中。因此R/W的IO非常的快。

而兩個比較大的差別是，Redis可以將資料儲存在Local Drive中，而Memcache只能存在memory。另外一點則是，Memcache的value沒有型別而Redis則支援多種型別ex. map, set, list etc.

Memcahce

Memcache Use Scenario

REDIS

REDIS Data Type

大資料資料庫儲存--MongoDB介紹(V)

前一篇介紹了HBase，接著將繼續介紹MongoDB

MongoDB

MongoDB是由10gen這一家公司開發的，與Cassandra和Hbase不同的是，MongoDB是一個document base的一個NoSQL。他支援Auto-sharding的功能另外一個比較特別的是，它內建了以javascript來利用map-reduce的概念搜尋資料。

Data Structure

MongoDB既然說是一個Document base的資料庫，那麼舉個最簡單應用的例子來說明他的優點。假設我們有一個database是紀錄post文章和每個文章的comment。以RDBMS最簡單的方式就是建立兩個table分別存放文章和comment。因此要撈出某一筆文章和其留言就必須要兩個query。

那麼MongoDB呢?既然他是Document base，那麼我們可以在一個document記錄了文章和留言，因此，撈出一篇文章和留言就只需要一個request！

Write Path

MongoDB有三個角色，分別是存放Data的mongod、Cmongod存放shard key和mongos負責做load balance和將使用者的request導到對的shard server。

 When to use MongoDB?

MongoDB可以非常lightweight(有人想要取代sqlite)，當你沒有複雜的transaction ex. 不是banking的系統就可以看看MongoDB。

大資料資料庫儲存--HBASE介紹(IV)

前一篇介紹了Cassandra，而在這裡將繼續介紹Cassandra。

HBase

Hbase是一個Apache top-level的project。他強調的是CAP理論中的CP也就是consistency 和Partition tolerance。

HBase Data Model

既然前一篇介紹了Cassandra，那麼在這裡就以Cassandra的範例來比較Hbase和Cassandra的不同。

Hbase最大的不同是，他的每一個CF(Column family)即為一個map，而每一筆資料的CF的ket set可以是不同的。而另外一點是，在hbase裡，所有的data都為byte array。

HBase Data Path 

Hbase有一張很嚇人的圖，它的特點是箭頭特別多。但是我們可以很簡單的理解這張圖

 以下圖為例，Hadoop的Data node其實就是很多台可以存放data 的node。以上圖為例，負責回應request的Hbase 節點有兩個。
P.S. Hbase是可以把資料存放在local disk而非HDFS不可的。

 使用者(client)會先留到zookeeper，zookeper會將使用者導到其中一台hbase server。使用者Insert依資料時，hbase會先存成hlog(在損毀時可以roll back)然後存到memstore(可以想像成memory 的小database)接著把資料存到HDFS中稱作Hfile。

NoSQL DON'Ts

在NoSQL風靡了幾年之後，開始有人反思：到底NoSQL真的有比傳統的RDBMS好嗎?或者說，我們真的需要NoSQL嗎?

在選擇之前，必須要先了解NoSQL 做不到的事:

另外一個迷思是，很多人認為在大資料的時代下，傳統的RDBMS是無法應付的?真的是如此嗎? 以Facebook為例，他們是使用sharding來存放使用者的post。你的資料有比他多嗎?

大資料資料庫儲存--Cassandra 介紹(III)

上一篇 我們介紹了什麼是NoSQL，在這裡，我們即將慢慢地介紹常見的NoSQL。

Cassandra

Cassandra是Apache Software foundation的top-level project。他是key-value的結構，比較不一樣的是它是tunable的consistency。什麼意思呢?就是說他可以選擇consistency的程度，例如確保2個data node的資料都被更新了才return 成功或是全部都更新了才回傳成功。

Cassandra Data Model

Cassandra的Data model主要有Keyspace對應RDBMS的database、Column family對應Table、Row key對應Primary key和Column name/key對應Column name。

我們可以簡單地把Keyspace裡面的column family(RDBMS的Table)看成是一個map of a sorted map。一個column family是一個sorted map，他的key就是每個row的row key，而value是一個map，存放每一個column 的value e.g. map<column name, column value>。

Cassandra的Column family有兩種分別是Static column Family和Dynamic column family。Static column Family和RDBMS很像，在create column family(table)的時候就定義好schema。而Dynamic column family則是在Insert data的時候，data的你仍舊可以插入未定義的column。舉例來說，假設我們的schema定義了name, email, address，你仍舊可以插入一個叫state的column的data。

另外一個不一樣的是，在RDBMS插入一個空的內容仍舊會佔去空間的。舉例來說，假設插入了一筆資料，其中一個定義4 byte char的欄位是空的，仍舊會佔去4 byte。Cassandra則沒有這個問題。

Cassandra write path

Cassandra Tunable Consistency

Cassandra分了6個consistency level如下表:

大資料資料庫儲存--What is NoSQL(II)

在上一篇大資料資料庫儲存--傳統的解決方案(I)介紹了在傳統在大資料量的解決方法，而前幾年開始熱門的NoSQL又是什麼東西?對於大資料量又有什麼不一樣的解決方式呢?

The CAP Theorem

在聊NoSQL之前有必要先介紹有名的CAP理論。Wiki是這樣說的:

In theoretical computer science, the CAP theorem, also known as Brewer's theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:^[1][2]

• Consistency (all nodes see the same data at the same time)

• Availability (a guarantee that every request receives a response about whether it was successful or failed)

• Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

簡單來說就是在一個分散式的系統裡面只可能同時間滿足consistency, availability和partition tolerance中的其二。

What is NoSQL?

 較早之前有人會以為NoSQL就是字面上的意思e.g. 不要SQL。事實上，NoSQL應該被解釋為not only relational database。意思是說有別於關聯式資料庫的資料庫。

NoSQL要解決的是傳統的Relational Database比較難解決(非不能解決)的scalability-尤其是scale-out的方式。當資料量及Request一多的時候怎麼存放這麼多的資料及應付龐大的資料存取問題。而另外一個很大的差別則是schemaless，也就是不像Relational Database在Insert data之前一定要有定義好的schema。

下一篇我們將開始介紹常見的NoSQL

大資料資料庫儲存--傳統的解決方案(I)

The problem

以MySQL為例，在一個table裡面存放10,000筆資料絕對不是問題。但是，當我們的資料上升到十萬筆、一百萬筆甚至一千萬筆，這個時候對資料庫的影響是什麼?當使用者數量一多，資料庫是否依舊能夠在一定的時間內回覆使用者的要求呢?

Traditional Solution

傳統的解決方法不代表是個落伍的、被淘汰的方法。相對的，是一個被證明可以有效解決是個能夠在Production中實作的一些方法。而事實上，大多數的網站仍舊使用這些方法來解決既有大資料量的問題。

Partition和Sharing最大的差別在-Partition是將一個table的資料切割放置到多個table；而sharing則是將一個table的資料放置到多個database中(通常是多台資料庫實體)。

Pros and Cons

那麼，partition和sharing各有什麼優缺點呢?

 Partition

大多數的資料庫其實都已經支援了Partition。Partition的設定方式主要是告訴資料庫要以哪一個column為依據，設定切割的條件。例如int的欄位，可以設定成1~1000為一個table、2000~3000一個table、剩下的一個table。

Partition相對於sharding最大的好處是不需要重寫SQL Logic。資料庫會根據搜尋的條件至相對應的table做query。

但最大的缺點是，儘管是切割成多個table但仍舊是放在同一個database。通常，隨著資料量增加也代表使用者變多了，當然request也變多了。資料庫的效能仍舊受限於該台資料庫所能提供的throughput。

Sharding

Sharding顧名思義的就是將一個table的資料切割放置到多台資料庫中。在實作上，我們可以自己改寫SQL Logic根據我們切割的條件來決定該request要發送到哪一台database。或者，我們也可以看到有許多framework來幫助你完成這件事。例如，MySQL Fabric, Vitess, Gizzard, Jetpants等等。

Sharding好處是資料庫的throughput可以隨著資料庫實體的增加而提升也就是scale out的solution。但最大的壞處是，因為資料散落在不同的資料庫，因此你可能做不到join沒有ACID transaction而且因為所有的查尋會因為資料切割的條件變得更複雜。

How about Big Requests?

前面有提到，資料量的提升通常也代表使用量變多隨之而來的request也變多了。假設我們已經把資料shard到不同資料庫了，我們要怎麼分散流量呢? Open Source的Load balancer solution是  HAProxy, Nginx或是MySQL Proxy(beta)，當然也可以購買貴鬆鬆Hardware load balancer。

另外，MySQL也有MySQL Cluster可以做到load balancer、auto sharding等等。不過就不在本篇的討論中了。