0

簡単に言うと、私が取り組んでいるアプリケーションの一部は、アプリケーションの別の部分が後で取得できるように、ある程度大量のデータをデータベースに格納する必要があります。通常、これは 2000 行未満ですが、場合によっては 300,000 行を超えることがあります。データは一時的に保存する必要があり、後で削除できます。

色々と考えていて、今日ふと思いついたことがあります。データ型はLONGTEXT最大 2^32 バイト (4 GB に相当) を格納できます。さて、1 つの表の行に詰め込むには多くの情報が必要です。データはおそらく最大でも 60 ～ 80 MBを超えることはありません。しかし、私の質問は、実際にそれを行うのは良い考えですか?

私が現在使用しようとしている2つのソリューションは、次のようなものです。

  • すべてのデータを個々の行として「一時」テーブルに挿入し、終了後に切り捨てます。
  • LONGTEXTすべてのデータをシリアル化された文字列として、終了後に削除される行の列に挿入します。

純粋にパフォーマンスの観点から、データを潜在的に 300,000 を超える個々の行として保存するか、60 MBLONGTEXTのエントリとして保存する方がよいでしょうか?

LONGTEXTそれがウォッシュである場合、データを取得するアプリケーションの部分を書きやすくするため、おそらくオプションを使用します。また、アプリケーションの全体的なパフォーマンスを向上させるさらに別の部分との連携も強化されます。

これについて何か考えていただければ幸いです。

4

5 に答える 5

2

そのすべてのデータをシリアル化してLONGTEXT...冒涜!! :)

まじめな話ですが、そうすると、すべてを 1 つの巨大な断片に抽出する以外に選択肢がなくなるのではないかと思います。一方、それを個々の行に広げると、フロントエンドで小さなバッチでフェッチすることができます。

少なくとも、その選択肢を自分に与えることは賢明なことのように思えます。(1 回のデータの将来のサイズ要件を過小評価すると、致命的なエラーになる可能性があることに注意してください!)

また、テーブルを正しく設計すれば、300.000 行にまたがる 60MiB のデータが、60MiB のテキストをフェッチしてフロントエンドで解析するよりも効率が悪いとは思えません。

最終的な問題は、MySQL がテキストをフェッチするよりも、フロントエンドがテキストを効率的に解析できると思いますか?

于 2010-01-19T07:21:14.297 に答える
1

This should be fine as long as you use a memory storage engine. In MySQL, this means using the MEMORY storage engine instead of InnoDB or MyISAM. Otherwise disk usage will bring your app to its knees.

于 2010-01-19T07:44:27.390 に答える
0

いつでも 300,000 行形式でデータベースに保存し、memcached を使用してデータをキャッシュできるので、再度行う必要はありません。memcached はそれをマシンのメモリに保存することに注意してください。したがって、このデータを大量に使用する場合は、有効期限を低く設定することができます。しかし、memcached を使用すると、ページが読み込まれるたびにクエリを実行する必要がないため、データを取得する時間が大幅に短縮されます。

于 2010-01-19T07:50:03.963 に答える
0

どのようなデータがどのように使用されますか? おそらく、アプリケーションのメモリに保存して処理する方がはるかに優れています。少なくとも、はるかに高速になり、DB エンジンをロードしなくなります。

于 2010-01-19T06:33:43.637 に答える
0

大規模な一時 BLOB を書き込むだけの場合は、代わりに共有ファイル システム上の一時ファイルに書き込むことを検討してください。

于 2010-01-19T08:04:53.743 に答える