1

すでに 1,200 万件の投稿があり、人々は物事をチャットとして使用しているようです。非常に多くのエントリを持つデータベースで最後の 10 件のメッセージをデータベースにスキャンさせるよりも、多数の小さなテーブルを用意する方が効率的かどうかはわかりません。ベンチマークする必要があることはわかっていますが、同様の状況にあったことがあるかどうか、観察や逸話があるかどうかを尋ねるだけです。

編集追加スキーマ:

create table reply(
id int(11) unsigned not null  auto_increment,
thread_id int(10) unsigned not null default 0,
ownerId int(9) unsigned not null default 0,
ownerName varchar(20),
profileId int(9) unsigned,
profileName varchar(50),
creationDate dateTime,
ip int unsigned,
pic varchar(255) default '',
reply text,
index(thread_id),
primary key(id)) TYPE=MyISAM;
4

3 に答える 3

4

変数テーブル名を使用することはお勧めできません。別のテーブルに変換される列にインデックスを付けた場合、データベースは、別のテーブルを作成するよりも、インデックスを使用してより適切に機能します。それが、データベースが設計された目的です。

于 2012-07-01T03:13:05.123 に答える
2

動的テーブルは、通常、リレーショナル スキーマでは非常に悪い考えです。キー/値ストアはさまざまなトレードオフを行うため、動的テーブルのようなものに優れているものもありますが、データの整合性/一貫性の保証が弱いなどの犠牲を払っています. 外部キー参照を定義していないようで、MyISAM を使用しているため、データの整合性/信頼性はおそらく優先事項ではありません。理解しておくべき重要なことは、設計が異なれば得意とする点も異なるため、ある DB にとって優れた設計が、別の DB にとっては不適切な設計になる可能性があるということです。

私は Pg に焦点を当てているため、他に多くのことを手伝うことはできません。これは MySQL の質問です。タグを外します。

(少なくとも PostgreSQL では、リレーション セットに対する多くの操作は O(n) であるため、膨大な数のリレーションは非常に有害である可能性があることに注意してください。)

于 2012-07-01T11:21:15.410 に答える
2

ここでの「スレッド」とは、投稿のプール内のスレッドを意味すると思います。

ここで長期的なスケーラビリティを実現する方法は、複数のデータベース インスタンスを持つことができるアーキテクチャを開発し、すべてのインスタンスで実行する必要があるクエリを避けることです。

同じ DB に複数のテーブルを作成しても、スケーラビリティの点ではあまり役に立ちません。(実際には、DB のキャッシュの負荷が増加するため、スループットが低下する可能性さえあります。) しかし、アプリケーションでは、異なるデータベースのメッセージの「プール」に分割できるように思えます。メッセージへの返信は、返信先のメッセージと同じプールに入ります。

発生する問題は、特定のことがすべての DB インスタンスのデータにまたがるクエリを伴うことです。この場合、ユーザーのすべてのメッセージを一覧表示したり、キーワード検索を行ったりする可能性があります。そのため、パーティショニングを実現する最善の方法を見つけるには、全体像を見る必要があります。相対頻度を考慮して、すべてのクエリを分析する必要があります。そして最終的には、データベースをパーティション分割できるようにスキーマを非正規化することが解決策になるかもしれません。

于 2012-07-01T03:15:49.303 に答える