NoSQL 和 SQL 的選用

時間 2019-11-24

標籤 nosql sql 選用欄目 NoSQL 简体版

原文原文鏈接

專欄 | 九章算法
網址 | www.jiuzhang.com程序員

NoSQL 有分不少種，其中key-value NoSQL (Redis, MemcacheD, etc) 的選用相對比較清楚些，大可能是當後端Data storage的cache層來用。這篇主要想請教Column Family NoSQL (e.g. Cassandra, Hbase) 和SQL之間的選用。其中包含一些我的的理解，如有錯誤的地方煩請不吝指教！面試

我理解上，Column Family NoSQL的schema和SQL schema大多可以互相做邏輯轉換。也就是說，給一個DB，裏面有不少table，table裏有不少column，而後跟你說我query的型態會長怎樣 (等同告訴你app layer的join要怎麼作)。咱們多半能把這些DB schema轉成CF NoSQL的schema。反之亦然。算法

對single box(單一機器)來講，CF NoSQL能承受的qps比SQL要高；不過在multiple machines的狀況下，可對SQL去做sharding & replicas來增長其performace和availability/reliability。這邊甚至可混用cosistent hashing的架構來做SQL sharding/replication。也就是說後端

在多臺機器可用的環境下
CF NoSQL 和 SQL 的效能
是能夠做到差很少的數組

事實上，Facebook 開發了Cassandra，但內部用的仍是用SQL 居多Lol。回到問題, 關於選用CF NoSQL vs SQL, 這邊分三種cases考慮。微信

1.Data相關性極低架構

Data很是不relational (require no join or few joins)，這時用SQL 就有點浪費，可能會有沒必要要的overhead。app

2.Data相關性極高ui

這時用CF NoSQL可能要處理大量的de-normalization，雖然disk便宜，但duplicated data太多的話可能也會爆容量。並且update時要處理de-norm data間consistency的問題。
e.g. 一個data可能屬於(row_key_A, column_key_A)同時也屬於(row_key_B, column_key_B)，這樣更新這data時就要同時更新這兩個row。感受這種狀況選用SQL會較佳。設計

3.Data相關性通常

去除以上兩個極端cases，一般data是介於中間。這時候感受

用 CF NoSQL 和 SQL是差很少的

用SQL的話，developer要本身處理sharding/replication。不過相對而言SQL expert的數量遠大於Cassandra/Hbase expert, SQL communities也相對成熟許多。

這樣看來，面試時若面臨到CF NoSQL和SQL的選用時，感受仍是選SQL比較安穩點。
用CF NoSQL感受會被質疑的點比較多，並且其schema有時不是這麼好設計。

推薦閱讀：