1

具体的な例で私の質問を説明するのが最善です。

レストランが顧客から注文を受けるために使用する注文管理アプリケーションを考えてみましょう。それらすべてを格納する orders というテーブルがあります。

現在、毎日テーブルのサイズが大きくなり続けていますが、アクセスされるデータの量は一定です。通常、レストランは最終日かそこらに受け取った注文のみに関心があります。たとえば、100 日後、「興味深い」データはテーブル サイズの約 1/100 にすぎません。1 年後は 1/365 などです。

もちろん、古い注文をすべて保持したいのですが、現在の注文のみに関心があるアプリケーションのパフォーマンスは低下し続けます。では、古いデータが「興味深い」データに干渉しないようにする最善の方法は何ですか?

私の限られたデータベースの知識から、2 つの同一のテーブル (order_present と order_past) を同じデータベース内に作成するという 1 つの解決策が思い浮かびました。新しい注文が「order_present」に入り、cron ジョブが 2 日以上前に処理されたすべての注文を「order_old」に転送し、「order_present」のサイズを一定に保ちます。

これは、この問題に対処するための許容可能な解決策と見なされますか? 他にどのようなソリューションが存在しますか?

4

1 に答える 1

1

データベース サーバーは、ボリュームの処理に優れています。ただし、パフォーマンスは物理ハードウェアによって制限される可能性があります。IO レイテンシーが気になる場合は、いくつかの解決策を利用できます。ユースケースに最適なものを評価する必要があります。

例えば：

  1. テーブルを分割して、複数の物理ディスクに分散できます。
  2. シャーディングを実行して、データを異なる物理サーバーに配置できます
  3. データとアプリケーションに最適な別のストレージ エンジンを使用して評価できます。MyISAM は、InnoDB よりも優れた読み取りパフォーマンスを提供しますが、ACID への準拠は低くなります。
  4. リード レプリカを使用して、すべての (ほとんどの) 「選択」クエリをメイン データベース サーバー (マスター) のレプリカ (スレーブ) に委任できます。

最後に、MySQL Performance Blogは、このトピックに関する優れたリソースです。

于 2013-10-29T16:43:29.007 に答える