私は最近ビッグクエリの作業を開始しました。それらが列指向のデータベースであり、このタイプのデータベースではディスクシークがはるかに高速であることを知りました。
リレーショナルデータベースと比較して、列指向データベースでディスクシークがどのように高速であるかを誰かが説明してくれますか?
私は最近ビッグクエリの作業を開始しました。それらが列指向のデータベースであり、このタイプのデータベースではディスクシークがはるかに高速であることを知りました。
リレーショナルデータベースと比較して、列指向データベースでディスクシークがどのように高速であるかを誰かが説明してくれますか?
大きな違いは、データがディスクに保存される方法にあります。
(過度に)単純化された例を見てみましょう。
50 列のテーブルがあるとします。一部は数値 (格納されたバイナリ) で、他は固定幅のテキストで、合計レコード サイズは 1024 バイトです。行数は約 1000 万で、合計サイズは約 10GB です。4GB の RAM を搭載した PC で作業しています。(通常、これらのテーブルはディスク上の個別のブロックに格納されますが、簡単にするために、データは 1 つの大きなブロックに格納されていると仮定します)。
ここで、特定の列 (レコードに 4 バイトとして格納された整数) のすべての値を合計したいとします。そのためには、1024 バイト (レコード サイズ) ごとに整数を読み取る必要があります。
ディスクから読み取ることができるデータの最小量はセクターであり、通常は 4kB です。したがって、すべてのセクターの読み取りに対して、値は 4 つしかありません。これは、列全体を合計するには、10 GB のファイル全体を読み取る必要があることも意味します。
一方、列ストアでは、データは別々の列に格納されます。これは、整数列の場合、4096 バイト セクターに 4 ではなく 1024 の値があることを意味します。(これらの値をさらに圧縮できる場合もあります) - 現在読み取る必要がある合計データは、10GB ではなく約 40MB であり、将来の使用のためにディスク キャッシュにも保持されます。
CPU キャッシュを見ると、さらに良くなります (データが既にディスクからキャッシュされていると仮定します): 1024 バイトごとに 1 つの整数は、CPU (L1) キャッシュには最適とは言えませんが、1 つのブロックに 1024 の整数があると、計算が劇的に高速化されます。 (これらは L1 キャッシュにあり、通常のメモリ アクセスよりも約 50 倍高速です)。
「ディスクシークがはるかに高速」は間違っています。本当の問題は、「列指向データベースがデータをディスクに保存する方法」であり、答えは通常、「シーケンシャル書き込みのみによる」(たとえば、通常はデータをその場で更新しない) であり、ディスク シークが少なくなるため、全体的にスピードゲイン。