多數據表，大數據量，更新頻率較高，以搜索為主的業務，推薦什么搜索服務/系統架構?

一、多數據表，大數據量，更新頻率較高，以搜索為主的業務，推薦什么搜索服務/系統架構

多數據表，大數據量，更新頻率較高，以搜索為主的業務，每個月1000萬數據量的增量并不大，主要是每個表里面的冗余字段太多，導致文件比較大，個人覺得針對業務分離列表數據調用和搜索數據調用，另外搜索使用sphinx和lucene做實時增量索引+定時合并不影響業務和性能。

這個是分布式時序數據庫的典型場景。提供一個使用DolphinDB解決類似場景的案例。

（1) 客戶幾百個業務場景，每天產生200多億條時序日志記錄（每條記錄10個字段左右，維度+指標），所有數據寫入采用雙副本，并提供強一致性保證。每天產生數據2個T，雙副本大概4個T，壓縮之后1個T。數據保留15天左右。

（2）寫入的同時有并發的查詢和計算。大概分三種。

根據業務場景和時間范圍，讀取原始數據，每次讀取最近一個小時左右的數據，約幾十萬條數據

按設備或按業務場景等維度進行分類統計過去24小時內每分鐘的統計量（均值）

按設備或按業務場景等維度進行分類統計過去24小時內各種指標的95百分位，供實時監控使用。

這三種query涉及的數據量都比較大，每分鐘大概2000~3000個這樣的query。單個查詢和計算的延遲在幾十毫秒到2秒之間。

（3）部署了6臺(36核，256G內存的服務器）物理機的DolphinDB集群解決上面的場景。實際上內存和cpu的使用率都不是很高，可以使用更少的資源來完成。

你的場景數據量少很多，但是要保留更長的時間。一臺16~24核，128~256G內存，6~12個hdd硬盤的物理機（售價6~10萬），安裝DolphinDB時序數據庫就可以搞定。你的業務場景非常簡單，數據在DolphinDB中按照日期和設備兩個維度分區就可以了。日期采用值分區，每天一個，設備采用范圍或哈希分區，分成100個。這樣每個分區的數據量大概在100萬條左右，非常好的平衡了查詢延時和吞吐量。

延伸閱讀：

二、SQL是什么

Structured Query Language

‘SQL’是結構化查詢語言，是一種用來操作?RDBMS?的數據庫語言，當前關系型數據庫都支持使用SQL語言進行操作,也就是說可以通過?SQL?操作 oracle,sql server,mysql,sqlite 等等所有的關系型的數據庫