Thursday, December 30, 2010

[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

No comments:

Post a Comment