1

スケーラブルな MySQL スキーマを作成する方法についてできる限り読んでいますが、これが良いアイデアかどうかはまだわかりません。

価値があるので、RDS を使用して EC2 でこのプロジェクトをホストしています。

私のデータベースには、読み取りよりも書き込みが多くなるコアテーブルがあります (約 70% の書き込みと 30% の読み取りが推測されます)。

ただし、テーブルに新しい行を作成するときは、5 秒ごとに更新を追加する必要があります。全体として、複数の行が毎秒追加/更新されるため、UPDATE ステートメントが約 1 秒ごとに実行されていることを意味します。

私が読んでいたことに基づいて、MySQLには、テーブルに書き込んでいるときに発生するテーブルロックと呼ばれるものがありますか? このテーブルも大量に読み取られるため、行で UPDATE ステートメントを使用すると、オーバーヘッドやロックが多すぎますか?

私のオプション（私が知る限り）は次のとおりです。

  1. 大きなテーブルに対して UPDATE ステートメントを頻繁に (1 秒ごと、またはそれ以上) 実行します。
  2. 行を作成して更新し、準備ができたら (行が完成するまで約 20 分)、ステージング テーブルからメイン テーブルに行を送信するステージング テーブルを用意します。

ステージング テーブルは、ユーザーがコンテンツを表示するまでに 20 分ほど待たされるので避けたいのですが、必要悪なのかどうか疑問に思っています。

他のアイデアはありますか？提案？

ありがとうございました！

4

2 に答える 2

2

テーブル ロックが適用されるかどうかは、ストレージ エンジンによって異なります。MyISAM はテーブル ロックを行い、InnoDB は行ロックを行います。

行を読み書きしたいので、各行への同時アクセスを許可する InnoDB を使用する必要があります (リーダーはライターをブロックせず、ライターはリーダーをブロックしません)。

主キーに基づいて行を更新すると、かなり高速になるはずです (サーバーがこれによって生成される IO に追いつくことができる場合)。

于 2011-03-11T23:07:47.130 に答える
0

Update ステートメントのコストが高いかどうかに関係なく、とにかく実行する必要があるようです。テーブルを更新しないオプションがあれば、明らかにパフォーマンスが向上しますが、そうではないと思います。

とにかく、あなたが尋ねているように見える本当の質問は、パフォーマンスよりも並行性に関するものです。具体的には、多くの小さな更新で同時実行性が向上するか、同じ合計数の変更を含むバッチ更新が少ないかを尋ねているようです。

私の経験では、同時実行のためにバッチ処理を行うよりも、小規模な更新を多数行う方がはるかに優れています。ただし、一般に、バッチ処理を行うと (更新の場合) パフォーマンスが向上します。

もう 1 つ理解しておくべきことは、ロックには複数の種類があるということです。更新と選択のためのテーブルのロックは同じではなく、ステートメントが行、ページ、またはテーブル全体をロックするかどうかについての考慮事項もあります。通常、ロックはかなりローカライズされていますが、このタイプのアプリケーションでは、ロック戦略の詳細と、特定のニーズに合わせてそれらを操作する方法について読む必要があります。

于 2011-03-11T23:21:56.110 に答える