1

特定の場所を中心に、いくつかの異なる縮尺の (半) リアルタイム フィードを保存するアプリケーションを作成しています。各スケールの重みは、スケールと同じ数の行のみを持つテーブルに配置されます。スケール アプリは、PHP Web アプリが 3 秒ごとに読み取る新しい重みを 1 秒ごとに MySQL データベースにフィードします。ハードドライブをページングするトラフィックが非常に多いようには見えないか、または違いが無視できるかどうかはわかりませんが、メモリ/ヒープテーブルと通常の MyISAM テーブル。

4

3 に答える 3

2

数百から数千の同時読み取り/書き込み要求 (典型的な OLTP の使用法を考えてください) では、innodb は myisam ハンドダウンを実行します。

それは他の人々の観察ではなく、トランザクション/アシッド サポートではなく、従来の myisam エンジンよりもはるかに優れた innodb のアーキテクチャに関するものです。

たとえば、innodb はクラスター化された主キー インデックスhttp://dev.mysql.com/doc/refman/5.0/en/innodb-index-types.htmlをサポートしています。

さらに、innodb には、myisam テーブル レベルのロックよりも、同時負荷の下ではるかにパフォーマンスの高い行レベルのロックがあります。

私は先に進むことができましたが、innodb が OLTP に適した選択肢である理由について、誰かがすでに非常に優れた要約を提供しています: http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB

于 2010-08-20T17:36:20.130 に答える
1

さて、あなたが大量のデータを期待しているなら、私はあなたがほとんど行かなければならないと思いますMyISAM。すべてをメモリテーブルに保存すると、メモリが不足する可能性があります。言うまでもなく、HEAPエンジンを使用すると、電力が失われるとすべてのデータが失われます（ユースケースによっては、それが必要になる場合があることに注意してください）...

于 2010-08-19T00:05:56.340 に答える
0

この質問は時代遅れになりつつあり、おそらく今では非常に優れた解決策を講じていることはわかっていますが、これを読んでいる可能性のある人に、おそらくリレーショナルデータベースはこの問題を解決する最良の方法ではないことを指摘したかっただけです. 私には、これは明らかにフラット ファイル データベースが理想的なソリューションであるケースのように見えます。これらの値をバイナリ ファイルに書き出し、単純な数学演算を使用して行とフィールドを選択するだけで、大量のオーバーヘッドを節約できたはずです。

于 2011-09-07T11:03:57.307 に答える