[nosql] nosql 與 Cassandra 介紹

nosql起源於1998年，早期近乎無人所知，近幾年來隨著雲端技術知名起來，nosql也較廣為人知，目前開源社群以nosql ( not only sql )為種種分散式非關聯式資料庫的統稱。nosql資料庫種類繁多，詳情可見nosql-database.org，Google的BigTable, Amazon的Dynamo，與目前由Apache負責開發的Cassandra是nosql中較為出名的幾個，眾多大型網站也都運用nosql技術來處理龐大資料的需求，就我所知Ebay使用nosql處理超過2PB的資料量。

Cassandra 是Facebook為了一般關聯式資料庫(relational database)應付不來的龐大資料成長需求，所發展出來的一套系統，2008時Facebook將Cassandra轉給Apache社群負責繼續開發，目前使用Cassandra的知名公司有Digg, Facebook, Twitter, Cisco等等，目前已有使用open source Cassandra運行在150台機器上處理超過100TB的案例。

以Cassandra官方介紹來說，這是一套有著高度擴充性的次世代分散式資料庫，有著Amazon Dynamo的全分散式設計與Google Bidtable的ColumnFamily模式資料結構。

在面臨需要高效能(High performance)、大量資料(Huge Storage)、高延展性(High Scalability)與高可用性(High Availability)的狀況時，nosql可以扮演相當稱職的腳色，但是nosql並不是完美無缺的選擇。

在設計上，nosql系統考慮到現實狀況(機器、網路的出錯是必然的)，多半以CAP理論去設計，而非一般關聯式資料庫的ACID理論，CAP為一致性(Consistency)、可用性(Availability)與中斷容忍性(Partition Tolerance)，理論上C與A是互斥的，所以一般nosql系統不是選擇CP就是AP。

舉實例來說，nosql有著資料最終一致性的特點，就是在一個節點更動資料後，隨著時間過去，其他節點最終會資料一致，但是nosql不像關聯式資料庫有交易(Transaction)的設計，所以在分散的DB中資料進行同步時，若同時又對同一筆資料異動，就可能會發生結果不如預期的狀況，而這正是nosql開發上需要特別注意的地方。

另外，nosql在資料結構上與關聯式資料庫截然不同，查詢(Query)語法也因nosql系統不同而各有差異，大多nosql是都需要使用API去進行溝通，不過一般來說，熱門的nosql系統都會有相當不錯的資源。

以Cassandra來說，本身有cassandra-cli這個command line工具可使用，官方也有提供thrift這套API來與Cassandra溝通，而用於各種程式語言的API也都有人開發出來，Ruby, Perl, Python, Scala, Java, PHP, Clojure, Grails, C++, C#...等等都有API可支援，進入的難度並不甚高。

若有資料成長快速、需大量讀取/寫入的資料庫需求時，不妨考慮看看可以動態增加資料節點，對於龐大資料有高效能的nosql。

Twitter在選擇Cassandra時，列出了下面這六個優點 Flexible schema、True scalability、Multi-datacenter awareness、Range queries、List datastructures、Distributed writes ，有興趣可以看看這篇文章up and running with cassandra。