按照id查詢，mysql、es、hbase三個哪個更快？

03-16

我看網上的一些說法，對於優化數據存儲和查詢比較常見做法，是用es做索引庫，然後再按照id查詢具體的mysql 或 hbase? 因為我具體沒實踐過，想知道這樣好處是什麼，難道按照id查詢真的mysql更快？
=================
如果都很快，為什麼要用es+mysql分庫分表配合使用呢

KV型數據，哈希比B樹索引快，內存比SSD快。這跟用了什麼資料庫沒關係，主要看索引類型和緩存效率。

像題主這種問題，根本沒辦法回答。

數據量、實時性要求、檢索條件的複雜度、ID辨識度……

如果數據規模小，ID是唯一鍵類型的，推薦MySQL。

另外：es一般用在檢索條件複雜和多變的場景，hbase在數據規模大的場景提供了更好的擴展性，MySQL簡潔成熟普通場景首選。

反正常用的硬碟的儲存結構翻來翻去也就是在B樹上折騰，或者說利用數據的排序性質做折騰

我們把索引的排序+寫入的數據的排序拆開來看，做排列組合

主鍵索引將索引欄位排序寫入+數據按主鍵id排序寫入=MySQL InnoDB引擎

索引排序寫入+數據不排序寫入=MySQL MyISAM引擎上建立索引

下面在普及下NoSQL里的LSM Tree

LSM Tree相當於多顆b樹一起組成一顆樹

主鍵索引將索引欄位排序寫入+數據按主鍵id排序寫入+LSM=Hbase/Cassandra

索引排序寫入+LSM+數據根據offset讀取寫入=Mongo

ES沒研究過，不過索引上肯定也是LSM樹

然後以下是我做的一個benchmark

可以看出兩個已排序的樹的Join的開銷其實很低，那麼只要在LSM Tree下的每顆B樹上帶上一個時間戳，那麼通過多棵樹的Join+時間戳新的數據覆蓋時間戳舊的數據，然後保證每顆B樹不可變，要變也是通過MergeJoin的方式將兩顆B樹合併成一顆更大的B樹，然後內存裡面維護一顆可變的排序樹，當這顆樹到達一個閾值時（一般32M），直接刷入硬碟，這樣就能做到每次insert只讀取內存里的數據，不讀取硬碟上的數據，從而達到只要NoSQL的可變樹緩存沒擊穿，CPU沒到100%，配合索引欄位的分區寫入多集群，寫入性能就沒有瓶頸的效果，相應的，這樣來說讀取的時候有幾棵樹就要讀取幾次，其中讀取每顆B樹的性能可以視作和MySQL讀取B樹的性能一致，其他的性能差距就是在緩存策略上的差距罷了，配合合理的設計和參數調整能夠規避很多問題

然後是針對某個id查詢的問題，一般來說NoSQL會取你的RowKey做布隆過濾器，能夠篩掉很大一部分的沒有此id的B樹不去讀取，這種情況查詢id性能和MySQL差不多，但是如果這個id是在長時間一直update的，那麼布隆過濾器有和沒有是一樣的了，有幾個B樹包含了此id就慢幾倍

所以可以這麼看

HBase這種是按範圍讀寫+MySQL寫入能力跟不上時使用的資料庫

ES可以看作採用了HBase類似的儲存結構，但是自動幫你從文本中提取出索引欄位的資料庫，省了你自己維護全文索引的各種坑，硬要當HBase那樣用估計也可以，但是人家不是為這種情景做設計的，估計有或多或少的設計上根本不會去想的坑在裡面，比如一致性，可用性之類的問題，真要用前提是有人幫你踩過坑，否則還是老老實實用HBase

MySQL這種是你寫入完全不是什麼問題的時候，讀多於寫，要並發，要事務，要靈活，要快速開發，要容易運維，關係型資料庫完爆NoSQL

三樣不是一個東西。

場景不夠明確。按key查詢太基本了。

脫離事務性、擴展性、一致性、索引性能等等無法作出評價。

如果非要解答，那我說，都很快。

首先速度，一般情況下es更快，數據量越大快的越多。mysql關係型資料庫主要在關係二字，適合存儲有業務關係的數據，方便進行事務處理。es，nosql非關係型，沒有事務等數據處理能力。es優勢在於非關係型數據對於分散式支持更好，作為基於lucence伺服器的全文搜索能力，非常適合全文搜索的環境，比如日誌查閱。

總結mysql 優勢在於事務，鎖，業務關係。還有簡單的使用方式t-sql.當然許可權等等

es的有事在於對於非關係型的，尤其json結構數據處理更快速，容易實現分散式和ha。

我們選用2atlas+2haproxy+2keepalived+vip+3個mysql的解決方案，重了點，查詢基本都是按客戶號hash查詢，基本能滿足需求

純理論的話，按ID查這種場景，查一數字主健的一條數據，意味著你要定位一條數據，MySQL最快，應該毫無疑問。

但是，只要不是ID這個欄位，結果就待定了。

有人說hash最快，這個也有可能，數據組織帥的話，按地址一步定位你牛逼。但在比較多數據背景下，你hash的目標應該是非數字類型的，另外，hash的結果還是數，和ID數據類型一樣，幾乎無用。想一想，把1億個數hash成另外一億個數，好處在哪裡。

es之所以快，是它在導入數據時，花費了精力面向文本分詞，建立反向索引這種數據結構。對ID來講，應該無用。（ID，你可以理解成典型的正向索引）

以上是我未經實驗的想法。

並發請求，數據量都說了再問吧

場景呢