4

Facebook のサブセットのようなソーシャル ネットワークに取り組んでいます。これは、アプリケーションが書き込みよりも読み取りの方が多いことを意味すると思います (つまり、INSERTS、UPDATES、または DELETES よりも SELECTS の方が多い)。

MyISAM を使用して、データベースに MySQL を使用する予定です。データベースの各テーブルには、次の 3 つのフィールドが含まれます。

  • CREATED- レコードが作成された時刻を含む日付フィールド
  • UPDATED- レコードが変更された時刻を含む日付フィールド
  • ROWSTATUS- レコードがアクティブ、非アクティブ、または削除されているかどうかを示す単一の文字フラグを含む CHAR(1) フィールド (それぞれ値 'A'、I、およびDを使用)。

PHP ラッパー クラスを介して、すべての SELECT クエリに ROWSTATUS が含まれるようにし、UPDATE クエリも UPDATED 列を更新し、INSERT クエリが CREATED 列を更新するようにします。

実際にレコードを削除するつもりはありません。代わりに、そのレコードの ROWSTATUS フィールドを更新して、D削除されたことを示すようにします (つまり、ソフト削除)。

10 日後に削除されたデータを物理的に削除する SQL 手順があります。

ただし、この記事を読んでいたところ、オーバーヘッドがロックされているため、物理的に削除する必要はないと主張しています。むしろ、著者は次のスキームを使用することを提案しました。

SELECT e.eventid,e.title
    FROM events e
   WHERE NOT EXISTS
    (SELECT * FROM event_deletes ed WHERE ed.eventid = e.eventid);

私のスキームがこの提案されたメカニズムとどのように比較され、どちらが優れているのだろうか? 自分だけでは決定的な答えにたどり着けませんでした。

4

2 に答える 2

2

@ Pentium10が言うように、あなたの計画には本質的に何も悪いことはありません。これは実際にはかなり標準的なアプローチです。

問題は、MyISAMを使用している場合、クエリの実行中にUPDATEによってテーブル全体がロックされることです。一度に更新または削除できるのは1つのレコードのみであるため、ボトルネックが発生します。

MyISAMを使用する理由がない限り、データベースエンジンとしてInnoDBに切り替えることをお勧めします。InnoDBは行レベルのロックを使用するため、UPDATEクエリが他のUPDATEをブロックすることはありません。また、トランザクションのサポートや参照整合性制約など、その他の優れた機能もあります。

于 2010-12-16T06:44:22.283 に答える
0

ここで私が目にする唯一の問題は、その記事と比較して、DELETE 呼び出しのロックのみを処理していることです。

UPDATE および DELETE ステートメントは常に MyISAM テーブルに対して排他ロックを発行する必要があることを知っておく必要があります。

そのため、記事では UPDATE 行ステータスの代わりに INSERT を使用することを推奨しています。記事の通りに行くべきです。削除された ID を格納する専用のテーブルを作成し、select で推奨される結合を使用して、削除されていないレコードを取得します。このように、エンド ユーザーの削除操作では、テーブルに挿入するだけで、テーブルで UPDATE ロックが発生することはありません。両方のテーブルに適切なキーを追加すると、結合はインデックスでのみ実行され、SELECT で高速になります。

更新の時間を保存すると、オーバーヘッドも発生します。役に立たないので、そのアイデアを削除する必要があります。また、レコードがいつ更新されたかを知るために使用することもありません。

于 2010-12-16T06:33:04.100 に答える