我了解上，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 的效能，是可以做到差不多的。
1、Data相關性極低
Data非常不relational (require no join or few joins)，這時用SQL 就有點浪費，可能會有不必要的overhead。
2、Data相關性極高
這時用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有時不是這麼好設計。
九章算法，國内&矽谷一線工程師線上直播授課，已經幫助30000+人成功拿到心儀offer。