根據本人淺薄的經驗，了解乙個資料引擎可能涉及以下問題：
目錄
1. 概念
2. 架構
3. 部署
4. 元資料
5. 寫資料鏈路
6. 查詢鏈路
階段總結
一些經常被關心的功能和特點
7. 舊資料清理
8. 資料的hash
9. 離線檔案匯入匯出
10. 故障恢復時間
11. 對比其他db
先粗略看看是否適合自己的需求，從官網/社群/技術部落格，初步了解這個kv適合哪些場景，最佳實踐，不適合哪些場景（不一定完善，不完善的自己進行測試不要人云亦云）。不適合的場景也跑一跑，看看到什麼程度（資料大小到什麼級別，請求量到什麼級別會有比較大的效能拐點）看看效能到底什麼樣？
都有哪些節點，每個節點負責什麼功能，通過什麼協議進行互動的
部署起來跑一跑：使用一下api看看基本的相應時間和支援的操作
元資料管理，元資料資訊分發，客戶端是否有快取？
flush?,資料副本是同步傳送還是非同步傳送，序列還是廣播？、一致性,故障時候如何保證不丟失資料，故障到什麼程度會阻止寫入/讀取？
資料只能從乙個程序查詢還是從多個服務程序查詢？是否可以寫在乙個節點，讀在另外的節點？
給出一句話的總結：適合什麼場景，不適合什麼場景。
總結就是總結，不要給長篇大論看半天 還不知道到底是否適合自己的需求
ttl，後台檔案合併：hbase的compaction，opentsdb的compaction，druid的檔案合併
資料按什麼策略分到不同的程序中的？hbase可以做預分割槽。es是根據分片策略進行分發
是否有工具是否支援跨集群
故障恢復時間決定了這個服務大部分適合對接線上需求還是更適合離線場景
和其他在應用方面類似的系統/db進行對比:
* 資料型別支援哪些不支援哪些
* 支援哪幾種api操作
* 資料匯入匯出是否有工具支援
* 擴容如何進行對使用者是否有影響
* 底層支援的儲存的資料量
* 一條資料最優大小
* 一次操作最優資料size
* ttl:表級別？列級別？ cell級別？
* 事務支援級別
* 其他獨有特性：hbase支援動態列，其他引擎的二級索引
* 其他引擎有哪些效能優化的點
擴縮容機制、方案
效能瓶頸點：如何「明顯」提公升效能（**或其他策略）資料結構，演算法，新**
如何判斷合適該擴容，何時該縮容，是否有明確的演算法
索引機制
一致性問題處理過程中的邊界條件判斷，極端場景的處理，
從0開始，編寫乙個驗證函式（工具函式）
之前寫專案的時候，一般都是在登入註冊，修改密碼的時候有需要些正則的需求，所以每次用到的時候都是直接從前面的 copy過去就好了，直到後台開始寫後台管理系統類的專案，複製貼上已經完全不可行了。怎麼能做乙個只會ctrl c，ctrl v的程式猿呢！簡直不能忍，於是就想到了自己寫乙個驗證函式，每次需要做驗...
從 0 開始手寫乙個Tomcat，7 步搞定！
tomcat，這只3腳貓，大學的時候就認識了，直到現在工作中，也常會和它打交道。這是乙隻神奇的貓，今天讓我來抽象你，實現你！tomcat 是非常流行的 web server，它還是乙個滿足 servlet 規範的容器。那麼想一想，tomcat 和我們的 web 應用是什麼關係？從感性上來說，我們一般...
如何開始乙個專案
需求核對表 是否定義了系統的全部輸入，包括 精度，取值範圍，出現頻率等 是否定義了全部輸出，包括目的頁面，精度，取值範圍，出現頻，格式等 是否定義了所有的輸出可格式，包括頁面，等 是否詳細定義了所有軟體外部介面 是否定義了全部通訊介面，包括握手協議，糾錯協議，容錯處理，通訊協議等 是否列出了使用者需...