3

約100GBのデータを約10MBの.csvファイルに保存しています。このデータに対する数千のクエリのルックアップ速度を最適化するにはどうすればよいですか？具体的には、どのテクノロジーを検討するか、または相対的なパフォーマンスをどのように見積もるかがわかりません。

各ファイルは日付に固有であり、複数の人のデータが含まれています。次に例を示します。

...
2005-07-03, "Daffy Duck", ...
2005-07-03, "Daffy Duck", ...
2005-07-03, "Mickey Mouse", ...
2005-07-03, "Mickey Mouse", ...
...

数千の日付/名前のペアについて、特定の日付/名前に対応するすべての情報を取得したいと思います。同等のSQLクエリはSELECT * FROM myDB WHERE Date='2005-07-03' AND Name='Mickey Mouse'。

現在、データベースにデータをロードしていません。「クエリ」を実行するために、適切な日付ファイルを見つけて、探している名前で行をフィルタリングします。リレーショナルデータベース、noSQLデータベース、またはその他の方法でデータを保存すると、パフォーマンスが向上しますか？もしそうなら、なぜそしてどのくらいですか？

4

4 に答える 4

10
于 2012-11-28T19:29:44.463 に答える
5

私はここで悪魔の擁護者の手足に出かけて、このすべてのデータを入れるのに必要な作業と比較して、この特定の操作のためのリレーショナルデータベースまたは他のデータベース「システム」ではそれほど良いパフォーマンスが得られないかもしれないと言いますデータベース。

ある種のデータベース（つまり、本格的な体系化されたデータ管理システム）にデータをロードすることをお勧めしますが、ファイルは非常に小さいものです。あなたの質問から、一定時間で必要なファイルを特定でき、最大10MBのデータを読み取ってフィルタリングするだけでよいように思えます（おそらく正規表現を使用しますか？）、なぜリレーショナルデータベースが必要なのですか？

ファイルを特定してgrepにパイプするだけで、完了ですよね？それはかなり効率的です。

適切なインデックス（日付、名前）を備えたリレーショナルデータベースは、2番目のステップをより効率的にするだけであり、それでも、データセットはかなり小さく、各10MBファイルに数千行ありますか？

これは、すべてをテキストファイルに保存することで問題を解決するための非常に大まかな方法​​のように聞こえますが、単純にしてください。データの解析、検証、およびデータベースへのロードを管理してから、データベース形式などでのデータの追加ストレージを管理する必要があります。

この検索を実行する必要がある頻度、結果として取得したデータをどのように処理するか、またはその他のパフォーマンスと運用上の要件についての情報は提供されていません。

この特定の操作を1秒間に何度も実行する必要がある場合、またはより創造的な方法でデータに柔軟に対応したい場合、または現在別々のファイルにあるデータなど、さまざまな種類の分析を実行したい場合は、リレーショナルデータベースは、データ管理の最良のオプションとしてすぐに現れます。

于 2012-11-28T20:25:44.283 に答える
2

他の人はすでにいくつかの良い点を提供しています、私は物理的なデータベース構造について少し話させてください...

可能であれば、クラスタリング1をサポートするDBMSを選択し、PKが{Date, Name, No}2であるクラスター化（別名インデックス編成）テーブルを作成します。SELECTは、単純なインデックス範囲スキャンでヒープアクセスがまったくない（テーブルヒープも存在しない）ので、悪いクラスタリング係数について心配する必要はありません。実用的なパフォーマンスは優れており、現在よりもはるかに多くのデータに対応できる必要があります。

DBMSが最先端のインデックス圧縮をサポートしている場合は、DBMSをオンにして、この複合プライマリ/クラスタリングインデックスのBツリー構造で値を繰り返すことによるストレージ（およびキャッシュ）コストを排除します。

1例：Oracle、MS SQL Server、MySQL / InnoDB ..

2ここで、同じでNo同じ上の複数の行を区別します。または、より細かくして（たとえば、1秒に正確にする）、クエリを次のように変更し、PKフィールドの順序を逆にして、変更されたクエリを満たします。DateNameDateSELECT * FROM myDB WHERE Name='Mickey Mouse' AND Date >= '2005-07-03' AND Date < '2005-07-04'){Name, Date}

于 2012-11-28T21:15:39.510 に答える
1

私は間違いなくデータベースを使用しますが、問題に適切なデータベースを選択するには、特にデータの形式について、もう少し情報が必要になります。これが私の推奨事項であり、どちらを選択するかについての詳細があります。

関連した：

すべてのデータが同じスキーマに適合する（すべて同じフィールドを持つ）場合、リレーショナルは理にかなっています。あなたの質問から、必要なインデックスは2つだけであるdateとおっしゃいnameました。

各エントリに他の多くのデータがあると仮定すると、SQLデータベースは（クエリのようなものを使用して）非常に理にかなっています。

利点：

  • あなたはそれがどのように機能するかをすでに知っているようです
  • 物事を行うCSVスタイルに非常に似ています
  • SELECT / JOINを使用できます（後で必要な場合）

欠点：

  • 未使用のフィールドのための無駄なスペース
  • うまくスケーリングしない（より多くのスペースが必要な場合）
  • 問題は恥ずかしいほど関係的ではないので、やり過ぎかもしれません

NoSQL：

データが同じスキーマに適合しない場合（共有キーが2つしかない多くの異なるキー）、ドキュメントストアの方が理にかなっています。データは一種のリレーショナルであるため、MongoDBは非常に理にかなっています。

データベースには次のJSONガイドを使用します。

{
    "name": "MickyMouse",
    "date": ...,
    other fields...
}

SQLの例のように、インデックスを設定nameしてインデックスにします。dateMongoDBは高速であり、余分なキーのためのスペースを占有しません。

このアプローチの利点：

  • 本当にうまくスケーリングします（ノードとシャードを追加できます）
  • 本当に簡単に操作できます

欠点：

  • 必要な機能を提供していない可能性があります

結論：

どちらも優れたアプローチですが、実際にはデータがどのように見えるかによって異なります。一般に、データベースはクエリに非常に優れていますが、ファイルシステムは、特にデータが大きくなるにつれて、そうではありません。

私は個人的にNoSQLルートを使用しますが、データセットと使用パターンに関する詳細情報が本当に必要になります。データをスケーリングする必要がある場合は、これがおそらく最良のオプションです。

私は実際には専門家ではありませんが、SQLを使用するのはあまり好きではありません。データが恥ずかしいほどリレーショナルである場合、SQLは非常に理にかなっていますが、実行していることはすべて1つまたは2つのテーブルに収まるようです。

于 2012-11-28T19:35:32.673 に答える