3

このアプリケーションでは、3 つの整数列 (ソース、タイプ、時間) によってインデックス付けされた大量のデータを保持します。そのデータのかなりのチャンクを読み込むには時間がかかる場合があります。私たちは、高解像度を必要としないクエリのために大きな粒度を保存するなど、より大きなクエリのために検索して読み込む必要があるデータの量を減らすために、さまざまな対策を実装しました (時間-賢い）。

データは bzip 圧縮されたテキスト ファイルに保存されていますが、基本的に同じ構造を持っているバックアップ アーカイブ内のデータを検索すると、ディスクに展開して grep するよりも、stdout に展開して grep でパイプする方がはるかに高速であることに気付きました。ファイル。実際、圧縮されていないファイルを grep するよりも、tar からパイプへの展開の方がはるかに高速でした (つまり、tar からディスクへの展開を割り引きます)。

これにより、ディスク 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 行のデータがあり、ブロブ フィールドの解凍およびデコード中にその場で目的のタイムスタンプを検索します。

これはあなたにとって意味がありますか？どのパラメータを調査する必要がありますか? どのような文字列が接続される可能性がありますか? 同様の効果を達成するために、どのような DB 機能 (任意の DBMS) が存在しますか?

4

2 に答える 2

4

これにより、ディスク I/O のパフォーマンスへの影響は、実際には思ったよりもはるかに重いのではないかと考えました。

絶対。ディスクに移動する必要がある場合、パフォーマンスへの影響はメモリよりも桁違いに大きくなります。これは、古典的な Jim Gray の論文Distributed Computing Economicsを思い出させます。

コンピューティングの経済学は変化しています。現在、(1) 1 回のデータベース アクセス、(2) 10 バイトのネットワーク トラフィック、(3) 100,000 命令、(4) 10 バイトのディスク ストレージ、および (5) 1 メガバイトのディスク帯域幅の間で、おおよその価格は同等です。これは、インターネット規模の分散コンピューティングを構築する方法に影響を与えます。高価なネットワーク トラフィックを回避するために、コンピューティングを可能な限りデータの近くに配置します。

では、問題は、どれだけのデータがあり、どれだけのメモリを確保できるかということです。

そして、データベースが非常に大きくなった場合 (たとえ 20 年間でさえ、これほど多くのメモリを購入できる人は誰もいなかったように)、Google のBigTableやHadoopのような巧妙な分散データベース システムが必要になります。

于 2008-08-25T13:43:41.643 に答える
0

Python でデータベースを操作しているときに、同様の発見がありました。ディスクにアクセスするコストは非常に高いのです。より狭い 7 つのクエリを作成するよりも、データのチャンク全体を要求して Python で反復する方がはるかに高速 (つまり、ほぼ 2 桁) であることが判明しました。(データについては、1 日 1 回)

時間ごとのデータを取得しているときは、さらに爆発しました。24 時間 365 日、大量のクエリを実行できます。

于 2008-08-25T14:12:29.657 に答える