1

オンライン調査を行うためのソフトウェアを開発しています。多くのユーザーが同時にアンケートに回答している場合、データベースの高い書き込み負荷を処理する際に問題が発生します。調査データを格納するための現在のテーブル (MySQL、InnoDB) には、次の列があります: dataID、userID、item_1 .. item_n。item_* 列には、特定のアイテムで取得されたデータのタイプに対応するさまざまなデータ タイプがあります。ほとんどの項目列は TINYINT(1) ですが、いくつかの TEXT 項目列もあります。大規模なアンケートには 100 を超えるアイテムが含まれる場合があり、100 を超える列を持つテーブルが作成されます。ユーザーは 1 回の http 投稿で約 20 項目に回答し、それに応じて対応する行を更新する必要があります。ユーザーは多くの項目をスキップする可能性があり、行に多くの NULL 値が発生する可能性があります。

書き込み負荷の問題に対する次の解決策を検討しています。多くの列を持つ 1 つのテーブルを用意する代わりに、使用するデータ型 (data_tinyint_1、data_smallint_6、data_text など) に対応するいくつかのテーブルを設定します。これらの各テーブルには、次の列のみが含まれます: userID、itemID、value (値列には、そのテーブルに対応するデータ型があります)。たとえば 20 個のアイテムを含む 1 つの http 投稿の場合、data_tinyint_1 に 19 行、data_text に 1 行を作成する必要がある場合があります (多数の列で 1 つの大きな行を更新するのではなく)。ただし、すべての項目について、(2 つのテーブル結合を介して) そのデータ型を決定する必要があるため、どのテーブルに新しい行を作成するかがわかります。私の zend フレームワーク ベースのアプリケーション コードは、このアプローチではより複雑になります。

私の質問:

  1. 私のソリューションは、重い書き込み負荷に適していますか?
  2. より良い解決策はありますか？
4

2 に答える 2

2

このスキーマを抽象化して実際のデータ型を模倣するところまで来ているので、代わりにサーベイごとに新しいテーブル セットを作成するのが理にかなっているかもしれません。利点は、負荷が耐えられなくなった場合に、ロックが軽減され、重い負荷を外部のマシンに分離できることです。

単一調査データベース構造は、実際の条件とデータ入力ハンドラーをより正確に反映できます。抽象化の頭痛の種がなくなるはずです。

その場でテーブルを作成することに問題はありません。一部の構成では、ソフト シャーディングが推奨されます。

于 2012-05-08T15:54:59.583 に答える
1

これは、ドキュメントデータベースを使用して高速書き込みを行い、 cron などを使用して MySQL への回答を非同期に一括挿入するという明らかな解決策のようです。ドキュメントデータベースでビューを作成して統計をすばやく作成できますが、ドキュメント DBMS が苦手な場合は、MySQ でのみフィルタリングやその他の複雑なものを使用できます。

于 2012-05-14T16:07:42.470 に答える