5400万レコードのテーブルがあります。これがテーブルの構造です。
CREATE TABLE `metaplay` (
`track_id` int(11) NOT NULL DEFAULT '0',
`user_id` int(11) DEFAULT NULL,
`completed` int(11) DEFAULT NULL,
`skipped` int(11) DEFAULT NULL,
`created` int(11) DEFAULT NULL,
`updated` int(11) DEFAULT NULL,
`id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`id`),
KEY `created` (`created`),
KEY `updated` (`updated`),
KEY `skipped` (`skipped`),
KEY `track_id` (`track_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
これらのデータはすべて数値です。この時点で、1分あたり約300の挿入と約100の更新があります。また、このテーブルから、毎日、毎週、毎月のトラック再生レコードを引き出します。今私の質問は、建築設計と最高のパフォーマンスのために次のうちどれが優れているかです。ハードウェアの詳細も強調していただければ幸いです。
また、このようなテーブルにmysql固有のチューニングのヒントを提案しますか?
あ、どうしたの?
5400万レコードのテーブル
小さなテーブル。いいね。ここには85億行あるものがあります。
1分あたり!300の挿入と!100の更新があります。
うん。小さい。知っている。ここには1日に約5億個の挿入があるものがあります。つまり、毎分347222.2222222222です。
これらはすべて、標準のハードウェアで実行されています。真剣に。あなたが提案するものほど完全にローエンドではありませんが。
しかし、メトリックは完全にオフです。 54百万は25年前に大きい。今日では、誰かがミニ仮想マシンでデータベースサーバーを実行しようとしない限り、それは小さいです。
たとえば、5GBのメモリを搭載した非サーバー-痛い。
一般に-分析が必要であり、これがドキュメントスタイルのデータではない場合-MySqlに固執し、NoSqlデータベースを避け、関係理論を学習して、そこで何をするかを理解します。
SSDは素晴らしいですが、5GBのメモリが適切かどうかはわかりません-さあ、それは適切なワークステーションよりも少ないです。
日次/週次/月次の集計の場合は、DAILY集計を作成し、それらをより大きな集計の基礎として使用します。月は最大です。 31日-ほとんどの作業は1日1回(オフタイムに)行われます。私は、ebayレベルの安価な中古ハードウェアを使用することを再考します。
そのテーブルの生データは1.4GB(54m * 28バイト)であり、インデックスはデータをいくらか追加しますが、インデックスに5GBとしましょう。
だからあなたが何をするのですか?なぜ4GB RAMだけですか?成長の余地がある32GBにしてください。
SSD上のMySQLは非常に高速です。 NoSQLは何も意味しない流行語であるため、特定の製品を念頭に置いていない限り、質問のその部分は無視します。