mysql - 書き込みは多いが読み取りは少ない - どの Mysql ストレージ エンジンを使用すればよいでしょうか?

Question

使用するストレージ エンジンの種類について誰か提案があるかどうか疑問に思っていました。プログラムは、データベースに対して多くの書き込みを実行する必要がありますが、読み取りはほとんど実行しません。

[編集] 外部キーは必要ありません。データは単純ですが、書き込みを非常に高速に実行する必要があります。

Answer 1

jpipesから：

MyISAMとテーブルレベルのロック

行レベルのロックを採用するInnoDBとは異なり、MyISAMは非常に粗いロックシステムを使用して、データが保護された方法でデータファイルに書き込まれるようにします。テーブルレベルのロックはMyISAMの唯一のロックレベルであり、これにはいくつかの結果があります。

• MyISAMテーブルに対してUPDATEまたはDELETEを発行する接続は、MyISAMテーブルの排他的書き込みロックを要求します。他のロック（読み取りまたは書き込み）が現在テーブルに配置されていない場合、排他的書き込みロックが付与され、あらゆる種類の要求（DDL、SELECT、UPDATE、INSERT、DELETE）を発行する他のすべての接続は、排他的スレッドが存在するまで待機する必要があります。書き込みロックは、必要なレコードを更新してから、書き込みロックを解放します。
• テーブルレベルのロックしかないため、（InnoDBの場合のように）1つまたは少数のレコードセットのみをロックして、他のスレッドがテーブルデータの他の部分からSELECTできるようにする機能はありません。

重要なのは、書き込みには、InnoDBの方が優れているということです。これは、ロックされるリソースが少なくなり、より多くの並列アクション/要求を実行できるようになるためです。

Answer 2

「書き込みを非常に高速に実行する必要がある」というのは漠然とした要件です。何をするにしても、データベース内の競合によって書き込みが遅れる可能性があります。アプリケーションがデータベースへの監査レコードの書き込み時にブロックする必要がない場合は、監査の書き込みを非同期にし、ディスクまたはメモリに監査データの独自のキューを保持する必要があります（メインワーカーのスレッド/プロセスをブロックしないようにします）

InnoDBは同時挿入を許可する場合がありますが、リソースの競合やインデックスページなどの内部ロックによってブロックされないという意味ではありません。

MyISAMでは、次の状況で1つのインサーターと複数のリーダー（「コンカレントインサート」）を使用できます。

• テーブルには「穴」がありません
• UPDATEまたはDELETEを実行しようとしているスレッドはありません

毎日再作成する（または5.1パーティションを使用する場合は毎日新しいパーティションを作成する）追加専用テーブルがある場合は、これを回避できる可能性があります。

MyISAMの同時挿入は、使用できる場合はほとんどの場合非常に優れています。

監査レコードを作成するときは、可能であれば一度に複数の作業を行ってください。これは、使用するストレージエンジンに適用されます。監査プロセスでは、レコードを「バッチ処理」して、一度に複数の挿入を行うことをお勧めします。

Answer 3

考えられる提案をするのに十分な情報を私たちに実際に提供していません-外部キーを使用したいですか？行レベルのロック？ページレベルのロック？トランザクション？

原則として、トランザクションを使用する場合は、InnoDB/BerkeleyDB。そうでない場合は、MyISAM。

Answer 4

私の経験では、MyISAMは、挿入後、読み取り専用である限り、高速書き込みに最適です。私がよく知っている他のどのオプション（インデックスのサポートを含む）よりも速く追加し続けるでしょう。

ただし、レコードの削除またはインデックスキーの更新を開始し、（テーブルまたはインデックスの）空の穴を埋める必要があるとすぐに、説明はさらに複雑になります。

ただし、従来のログタイプまたはジャーナルタイプのテーブルの場合は、非常に満足しています。