面對海量資料，如何才能查得更快?

我們知道，原始資料的資料量太大了，能存下來就很不容易了，這個資料是沒法直接來給業務系統查詢和分析的。有兩個原因，

• 一是資料量太大了

• 二是也沒有很好的資料結構和查詢能力，來支援業務系統查詢。

一般的做法是，用流計算或者是批計算，把原始資料再進行一次或者多次的過濾、匯聚和計算，把計算結果落到另外一個儲存系統中去，由這個儲存再給業務系統提供查詢支援。這裡的“流計算”，指的是 Flink、Storm 這類的實時計算，批計算是 Map-Reduce 或者 Spark 這類的非實時計算。

分析類系統應該如何選擇儲存？

擇什麼樣的儲存系統、使用什麼樣的資料結構來儲存資料，直接決定了資料查詢、聚合和分析的效能。

分析類系統對儲存的需求一般是這樣的：

1. 一般用於分析的資料量都會比線上業務大出幾個數量級，這需要儲存系統能儲存海量資料；

2. 能在海量的資料上做快速的聚合、分析和查詢。注意這裡面所說的“快速”，前提是處理 GB、TB 甚至 PB 級別的海量資料，在這麼大的資料量上做分析，幾十秒甚至幾分鐘都算很快了，和線上業務要求的毫秒級速度是不一樣的；

3. 由於資料大多數情況下都是非同步寫入，對於寫入效能和響應時延，一般要求不高；

4. 分析類系統不直接支撐前端業務，所以也不要求高併發。

哪些可供選擇的儲存產品:

• 如果你的系統的資料量在 GB 量級以下，MySQL 仍然是可以考慮的，因為它的查詢能力足以應付大部分分析系統的業務需求。並且可以和線上業務系統合用一個資料庫，不用做 ETL（資料抽取），省事兒並且實時性好。這裡還是要提醒你，最好給分析系統配置單獨的 MySQL 例項，避免影響線上業務。

• 如果資料量級已經超過 MySQL 極限，可以選擇一些列式資料庫，比如：HBase、Cassandra、ClickHouse，這些產品對海量資料，都有非常好的查詢效能，在正確使用的前提下，10GB 量級的資料查詢基本上可以做到秒級返回。高效能的代價是功能上的縮水，這些資料庫對資料的組織方式都有一些限制，查詢方式上也沒有 MySQL 那麼靈活。大多都需要你非常瞭解這些產品的脾氣秉性，按照預定的姿勢使用，才能達到預期的效能。

• Elasticsearch（ES），ES 本來是一個為了搜尋而生的儲存產品，但是也支援結構化資料的儲存和查詢。由於它的資料都儲存在記憶體中，並且也支援類似於 Map-Reduce 方式的分散式並行查詢，所以對海量結構化資料的查詢效能也非常好。

轉變思想：根據查詢來選擇儲存系統

儲存系統沒有銀彈，不要指望簡單地更換一種資料庫，就可以解決資料量大，查詢慢的問題。

在特定的場景下，通過一些優化方法，把查詢效能提升幾十倍甚至幾百倍，這個都是有可能的。這裡面有個很重要的思想就是，根據查詢來選擇儲存系統和資料結構。

那用什麼樣的儲存系統儲存這些物流資料，才能滿足這些查詢需求呢？顯然，任何一種儲存系統，都滿足不了這麼多種查詢需求。我們需要根據每一種需求，去專門選擇合適的儲存系統，定義適合的資料結構，各自解決各自的問題。而不是用一種資料結構，一個資料庫去解決所有的問題。

• 按照時間分片是對查詢最友好的分片方式

總結

對於海量資料來說，選擇儲存系統沒有銀彈，重要的是轉變思想，根據業務對資料的查詢方式，反推資料應該使用什麼儲存系統、如何分片，以及如何組織。即使是同樣一份資料，也要根據不同的查詢需求，組織成不同的資料結構，存放在適合的儲存系統中，才能在每一種業務中都達到理想的查詢效能。