數據壓縮如何比搜索性能的索引更有效？

Question

對於我們的應用程序，我們保留大量由三個整數列（源，類型和時間）索引的數據。加載大量的數據可能需要一些時間，我們已經實施了各種措施來減少爲更大的查詢而必須搜索和加載的數據量，例如爲不需要高分辨率的查詢存儲更大的粒度（時間-明智的）。

在我們的備份存檔中搜索數據時，其中的數據存儲在雙向壓縮文本文件中，但基本上具有相同的結構，我注意到將標籤解壓縮並通過grep進行管道傳輸比將其解壓縮要快得多磁盤和grep文件。實際上，untar-to-pipe甚至比僅對未壓縮文件進行擦除（即折扣磁盤解壓縮）顯着更快。

這讓我想知道磁盤I/O的性能影響是否比我想象的要重得多。所以這裏是我的問題：

您是否認爲將多行數據放入單行的（壓縮）blob字段並在提取過程中實時搜索單行可能比通過搜索相同行更快表索引？

例如，代替具有該表

CREATE TABLE data (`source` INT, `type` INT, `timestamp` INT, `value` DOUBLE); 

我不得不

CREATE TABLE quickdata (`source` INT, `type` INT, `day` INT, `dayvalues` BLOB); 

用大約100-300行中用於的QuickData各行數據和搜索所需的時間戳在解壓和解碼blob字段期間飛行。

這對你有意義嗎？我應該調查哪些參數？可能連接什麼字符串？什麼數據庫功能（任何數據庫管理系統）存在達到類似的效果？

Answer 1

這讓我想知道磁盤I/O的性能影響是否比我想象的要重得多。

當然。如果你不得不使用磁盤，性能要比內存大好幾個數量級。這讓我想起了經典的吉姆格雷紙，Distributed Computing Economics：

計算經濟學正在改變。今天，在（1）一個數據庫訪問，（2）10個字節的網絡流量，（3）100,000條指令，（4）10個字節的磁盤存儲，以及（5）兆字節的磁盤帶寬之間存在大致的價格平等。這對於如何構建互聯網規模的分佈式計算意義重大：爲了避免昂貴的網絡流量，儘可能將計算放在儘可能接近數據的位置。

問題是，你有多少數據，你能承受多少內存？

如果數據庫中獲取真的大 - 在沒有人可以永遠買得起這麼大的內存，即使在20年內 - 你需要聰明的分佈式數據庫系統，如谷歌的BigTable或Hadoop。

Answer 2

在數據庫中使用Python時，我做了一個類似的發現：訪問磁盤的成本非常高。事實證明，要求一整塊數據並且在python中迭代它的速度要快得多（即接近兩個數量級），而不是創建七個較窄的查詢。 （對於數據，每天有一個問題）

當我獲得小時數據時，它甚至進一步被吹滅。全天候24x7大量查詢！