堅持寫NoSQL技術部落格以來的幾點感想..
在學習的時候，我一直保持著記筆記或者做簡單總結的習慣，內容比較隨性，但這些內容有助於自己的快速回顧。在技術領域，最好的總結是一個直觀的流程圖，所謂”一圖勝千言”，然後配以簡單的文字說明。但可惜，那時沒有想過寫作公開的技術部落格，周邊也缺乏這樣的氛圍。
幾個月前，正式決定開始寫部落格和公眾號。初衷還是希望能督促自己在業餘時間的學習，當正式開始以後，如下幾點內容感受非常深刻：
- “以輸出倒逼輸入”，這就要求每天必須堅持學習。如果寫作只是將自己知道的內容寫出來，對於我，那將變成一件枯燥而無趣的事情。
- 公開的內容對質量會有更高的要求，進一步提高了對學習的要求。
- 如果寫作的內容得到其他人的認可，可以帶給自己更多堅持下去的信心。
但頻繁更新卻是一件極其艱難的事情。技術總結內容，通常需要細緻的閱讀原始碼細節，如果追求高質量輸出，難以在短時間內快速完成。另外因日常工作方面的原因，自由可支配的時間時常不受控制。
上面這些內容，更多的是自己的幾點感受。希望閱讀了此文的同學們也能開始自己的技術寫作，對於已經開始的，也應該長期堅持下去。
接下來是關於NoSQL技術的一些漫談內容。最初，對於這個公眾號名稱，我曾糾結過一段時間。NoSQL一詞，儼然已過了風頭正盛的時期，甚至聽起來像一個”過時”的概念。關於這個公眾號，主要想探討如下領域的內容：
- 分散式KeyValue系統
- 稀疏矩陣形態的寬列儲存技術
- 搜尋技術
- 圖資料庫技術
- 文件資料庫技術
- 時序/時空資料庫技術
- 多模資料庫技術
- 分散式索引技術
- NewSQL技術
- 分散式計算技術
認真思考一下，也只有NoSQL一詞可將其儘可能的囊括起來。每一種技術，都有自己獨特的精彩實現內容，但更多的是一些通用的技術，如RPC通訊技術，索引技術，分散式共識演算法，MVCC， SQL能力等等。
對比於NoSQL，NewSQL聽起來像是一個更新潮的概念。Google對於NoSQL與NewSQL技術架構的影響可謂深遠，我們先來看看Google從Bigtable到Spanner/F1的演進過程，下面列舉了每一種技術的設計關鍵點：
Bigtable:
- LSM-Tree架構
- Auto-Scaling
- 基於分散式檔案系統GFS/Colossus
- 稀疏矩陣
- Schema less設計
- 行級事務
- 非同步容災（Paper中提及但最終未實現）
Megastore:
- 基於Bigtable構建
- 在NoSQL與RDBMS之間做了妥協，支援半關係型模型
- 支援SQL介面
- 支援多種二級索引型別
- 基於Paxos協議實現了跨DataCenters間的同步容災
- 支援Entity Group級別的跨行事務
Spanner:
- 參考了Bigtable的設計後全新實現
- Auto-Scaling
- 半關係型模型
- 支援SQL介面
- 支援同步容災
- 支援廣泛的分散式事務能力
F1:
- 基於Spanner構建
- 分散式SQL查詢能力
- 支援事務一致性的二級索引
- 支援非同步的Schema變更
- 支援樂觀事務
- 資料變更歷史記錄跟蹤
關於NoSQL與NewSQL，這篇文章《NewSQL是否是NoSQL的取代者？》做了更詳細的探討。這裡僅簡單的羅列一下觀點：
– NoSQL通常指一種非關係型儲存技術，涉及的範圍廣泛，本身與是否具有SQL介面能力無關。
– NewSQL更多是指一種分散式的關係型資料庫技術，典型意義上的NewSQL包括Spanner， CockroachDB， NuoDB以及國內的TiDB，它通常會更加強調分散式事務能力。
NewSQL更多是RDBMS與NoSQL技術結合的一種產物，對於傳統的應用，會更加友好，也具有廣泛的普適性。在可預見的未來，它也一直會有可觀的市場空間。而每一種NoSQL技術更像是一種專業化能力的存在：
- HBase：稀疏矩陣，基於KeyValue提供了簡單的讀寫介面
- Elasticsearch：提供分散式搜尋能力
- Druid：基於事件資料的OLAP能力
- Neo4j：提供圖資料庫能力
- OpenTSDB/InfluxDB：提供時序資料庫能力
在”nosql-database.org”這個網站中，收錄了大量的NoSQL技術，大家可以參考一下。
如果每一種技術只提供一種專業的能力，那就帶來了通用性方面的問題，同一份資料時常需要在不同的系統中各複製一份是一個無法忍受的問題。從應用的角度來看，大家更期望一種”One Size Fit More/All”的技術，但這在技術實現上幾乎不可能。多模資料庫似乎是一個不錯的答案，它的設計理念為：
“基於一套儲存引擎，提供多種模型，多種訪問介面”
以當前火熱的AZure Cosmos DB為例，支援如下三種模型：
– Document
– Graph
– KeyValue
AZure Cosmos DB基於上面三種模型，提供了多語言(Java/Python/Node.js/.NET)訪問介面，並且提供了MongoDB Document API以及基於SQL的訪問介面。
再以ArrangoDB為例，它同樣支援如下三種模型：
– Document
– Graph
– KeyValue
ArrangoDB主要提供了AQL(SQL-Like)介面以及HTTP介面。
多模資料庫像是NoSQL技術的大雜燴，但的確不失為NoSQL技術一個不錯的演進方向。隨著公有云，人工智慧，物聯網等行業的快速發展，以及即將到來的5G技術，需要儲存和查詢的資料量也會變得越來越大，相信NoSQL技術會生生不息，一定會取得更廣泛的應用場景。 這也是我堅持在”NoSQL”領域寫技術部落格的一個關鍵原因。
本文源自：NoSQL漫談(nosqlnotes.com)
除非特別註明，本站文章均為原創，未經授權，嚴禁轉載。