mysqlのテーブル構造-1つの非常に大きなテーブルですか？

Question

私は、ウェブサイトの訪問者分析に本質的に類似したプロジェクトに取り組んでいます。 これは、1日あたり平均10,000から100,000のページビューを持つ100のWebサイトで使用されるため、データ量は非常に大きくなります。

websiteidで単一のテーブルを使用するか、各Webサイトに個別のテーブルを使用する必要がありますか？

それぞれに個別のテーブルを持つ100のWebサイトを持つライブサービスに変更を加えることは、大きな問題のようです。一方、このような大きなデータでは、おそらくパフォーマンスとスケーラビリティが問題になるでしょう。提案、コメント、またはアドバイスは大歓迎です。

Answer 1

ウェブサイトごとに1つのテーブルパーティション分割 FK？

Answer 2

データが与えられた場合に最も意味のあるデザイン、この場合は1つの大きなテーブルを使用します。

レコードはすべて同じタイプで、同じ列になります。そのため、データベースの正規化の観点からは、同じテーブルにレコードを入れるのが理にかなっています。インデックスを使用すると、特に単一のインデックス内のデータでクエリ全体を満たすことができる場合に、特定の行を簡単に選択できます（多くの場合そうなることがあります）。

訪問者の分析には、多数の行を一度に操作する以外に最適化する簡単な方法がない場合、必然的に多くの操作が含まれることに注意してください。たとえば、カウント、合計、平均です。このようにリソースを集中的に使用する統計は、ライブで取得するのではなく、事前に計算して保存するのが一般的です。考えてみたいものです。

Answer 3

データが統一されている場合は、1つのテーブルに移動します。すべてのWebサイトを選択する必要がある場合 複数のテーブルを持つことは苦痛です。ただし、十分なスクリプトを記述すれば、複数のテーブルでスクリプトを作成できます。

MySQLのMERGEストレージエンジンを使用して、テーブル全体でSELECTを実行できます（ただし、良好なパフォーマンスは期待できません。また、オープンファイル数のWindowsハード制限に注意してください。Linuxでは、ulimitを使用してWindowsでそれを行う方法はありません）。

私は巨大なテーブルを多数の（数百の）テーブルに分割し、MERGEからSELECTを使用しました。これは、各小さなテーブルのオフラインでの作成と最適化を実行できるようにするためです。 （例：OPTIMIZEまたはALTER TABLE ... ORDER BY）。ただし、SELECT with MERGEのパフォーマンスにより、独自のカスタムストレージエンジンを作成することになりました。 （http://blog.coldlogic.com/categories/coldstore/'>ここで説明）

Answer 4

単一のデータ構造を使用します。パフォーマンスの問題が発生し始めると、水平パーティショニングとも呼ばれるウェブサイトIDでテーブルをパーティション分割したり、レプリケーションを使用したりするなど、多くのソリューションがあります。これはすべて、読み取りと書き込みの比率に依存します。

しかし、最初は物事をシンプルに保ち、適切なインデックスを付けた1つのテーブルを使用します。トランザクションが必要かどうかも判断できます。また、MyIsamやNDB（メモリクラスタリング）などのさまざまなmysqlストレージエンジンを利用して、パフォーマンスを向上させることもできます。また、キャッシュはデータベースから負荷をオフロードするのに非常に良い役割を果たします。ほとんどが読み取り専用で、簡単に計算できるデータは通常キャッシュに格納され、キャッシュはデータベースに移動する代わりにリクエストを処理し、必要なクエリのみがデータベースに送信されます。

Answer 5

MySQLでパフォーマンスの問題がない限り、1つのテーブルを使用します。

ここでは誰もパフォーマンスの質問に答えることができません。1つの大きなテーブルで十分かどうかを理解するために、パフォーマンステストを自分で行う必要があります。