NoSQL概念課 筆記

CAP

主從架構：MongoDB
P2P架構：Cassandra

BASE 原則
用於一致性與完整性要求低，但量大(volume)且快速(velocity)

scale up vs. scale out
scale up  必須使用SAN 等裝置才能分散

schema-less:

RDBMS: 商業邏輯、會員資料
NoSQL: linear, region hot spotting 問題，因為不方便

Facebook作法：mysql存會員資料，memcached 資料庫快取、Cassandra 站內信箱資訊、HBase訊息&反向索引
memory相關的solution毀損的機率高，memcached 沒有持久、Redis可以持久

• Cassandra: 一致性相較比較慢、底層Java改成C++，效能10X, 可考慮採用C++版本
• MongoDB: 資料量大寫入會變慢，不太算能夠scale out ，適合大量log，BSON(binary json), sharding, re-balancing
• HBase: 非RDBMS的替代品、沒有太完整的SQL、anti-schema、想像成超大excel
• GraphDB: 減少join, 適合連結的資料、推薦引擎，不適合大量log
• RethinkDB: 10台server 每天處理上百萬篇文，好設定

NoSQL缺點：只有索引部份欄位可以快速查詢，對於secondary index比較弱
-> 搭配  elasticsearch 解決

note:
1~2 TB 的資料用SQL server 還可以
column的數量不會是效能瓶頸

Q. Hadoop 傳教士「王耀聰」提過每個大數據系統都是為了特定的需求而生，老師課堂中也提過不是拿一個 NoSQL 系統就直接來做各種應用，可能需要堆疊一些軟體。
不知道在實務上，雖然資料來源可能相同，是否是不同應用就使用不同的 NoSQL 系統叢集提供服務呢？
A. yes, 參考Facebook 的作法

Q. RDBMS 設計有所謂的「正規化」方法可以參考，NoSQL 系統的 key design 是否有一些經典的指引或設計方法呢？
A. refer to 10gen

Q. hbase 的 region hotspotting 之類的問題，是否亦存在於其他的 NoSQL 系統呢？(key/資料分割的困難)
A. yes