2

イベント ロガー用の mysql テーブルの設計についてアドバイスをお願いします。

私たちのニーズ: - 多くのアクションを追跡する - 毎秒 10,000 アクション - 現時点で 10 億行

当社のハードウェア: - 2*Xeon (システムでは 32 CPU として認識) - 128 GB RAM - 6*600 SSD (Raid 10)

私たちのテーブルデザイン:

CREATE TABLE IF NOT EXISTS `log_event` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `id_event` smallint(6) NOT NULL,
  `id_user` bigint(20) NOT NULL,
  `date` int(11) NOT NULL,
  `data` bigint(20) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `id_event_2` (`id_event`,`data`),
  KEY `id_inscri` (`id_inscri`),
  KEY `date` (`date`),
  KEY `id_event_4` (`id_event`,`date`,`data`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8


ALTER TABLE `log_event`
  ADD CONSTRAINT `log_event_ibfk_1` FOREIGN KEY (`id_inscri`) REFERENCES `inscription` (`id_inscri`) ON DELETE CASCADE ON UPDATE CASCADE;

私たちの問題: - プライマリとして自動インクリメントがありますが、実際には使用されていません。それを取り除くのは問題ですか？削除すると主キーがなくなります => 行を識別する方法は?

  • パーティショニングをしたいのですが、外国人では無理そうですか？

  • 一括挿入は行いません。インデックスなしでメモリ テーブルに挿入し、5 分ごとにデータをコピーすることをお勧めしますか?

最適化するアイデアはありますか? この種のシステムのベストプラクティスはありますか?

ありがとう ！

フランソワ

4

1 に答える 1

0

リレーショナル テーブル (リレーション) の主キーには、次の 2 つのタイプがあります。

  1. 自然- サブジェクト領域に存在し、リレーショナル テーブルの各行を完全に決定します。自然主キーは、単純(1 つの列のみで構成されている場合) または複雑(複数の列で構成されている場合) の場合があります。大きな文字列列に自然主キーを設定することはお勧めしません。

  2. 人工- テーブルのパフォーマンスを向上させるためにデータベース設計者/開発者によって挿入される特別な列で、自然キーが複雑で、関連するテーブルで使用する必要がある場合 (何かの外部キーである場合)、または単純であるが大きくて生成される場合関連するテーブルに外部キーとしてコピーされるときのデータ オーバーヘッド、または検索が複雑な場合 (たとえば、ID に対する CRUD 操作はVARCHARID に対するものよりも遅くなる可能性がありますINT)。他にも理由があるかもしれません。TL;DR : 人工キー - 1 つの特別な列で、リレーショナル テーブルの各行を完全に決定し、CRUD 操作のパフォーマンスを向上させるのに役立ちます。

プライマリとして自動インクリメントがありますが、実際には使用されていません。それを取り除くのは問題ですか？削除すると主キーがなくなります => 行を識別する方法は?

テーブルを (ソースとして) 別のテーブルに参照する必要がない場合は、影響を与えずに人工キーを削除してもかまいません。PRIMARY KEYそれでも、データの重複を避けるため、および明白にするために (重要な場合)、このテーブルに他の値を設定することをお勧めします。

テーブル自体（適切に正規化されている場合）は、「キー候補」の1つとして自然キーを持ちます。複雑なものかもしれません（いくつかの列で構成されています）。正常です。ただし、文字列にプライマリを設定しないでください。PRIMARY常にインデックスがあり、データのオーバーヘッドが発生します。INTまたは「小さい」VARCHAR列の組み合わせであれば正常です。

オプションとして検討してください: id_event + id_user+ date.

一括挿入は行いません。インデックスなしでメモリ テーブルに挿入し、5 分ごとにデータをコピーすることをお勧めしますか?

それは悪い考えではありません。しかし、適切にテストされるまでは、良い考えではありません。実際に使用する前に、負荷テストを実行してみてください。

他のテーブルを参照しない場合MEMORYでも、他のInnoDBテーブルと結合できます。ただし、InnoDB機能が失われます (参照整合性)。親テーブルの損失がON DELETE CASCADE ON UPDATE CASCADE問題にならない場合は、それが行われる可能性があります。私に関してInnoDBは、あなたの場合、テーブルエンジンを切り替えるのはそれほど遅くありません。

于 2013-05-17T08:07:42.430 に答える