2

このテーブルには、id、content、および 1 つのプライマリ キー (id) の 2 つのフィールドがあります。

フィールド ID タイプは bigint です。フィールドのコンテンツ タイプは TEXT です。このフィールドは var-lenth であるため、一部のレコードは 20k になり、レコードの平均長は 3k になります。

テーブル スキーマ:

CREATE TABLE `events` (
  `eventId` bigint(20) NOT NULL DEFAULT '0',
  `content` text,
  PRIMARY KEY (`eventId`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Key-Value ストレージとして使用されるだけです。

私のテスト結果は次のとおりです。

InnoDB: 2200 records/second
TokuDB: 1300 records/second
BDB-JE: 12000 records/second
LevelDB-JNI: 22000 records/second(not stable, need test again)

結果は非常に悪いです。

3K は tokuDB には大きすぎますか?

My Application では、多くの挿入 (>2000 レコード/秒、約 100M レコード/日) があり、まれに更新/削除があります。

TokuDB version: mysql-5.1.52-tokudb-5.0.6-36394-linux-x86_64-glibc23.tar.gz 
InnoDB version: mysql 5.1.34
OS: CentOS 5.4 x86_64

InnoDB/TokuDB を選択する理由の 1 つは、パーティションのサポートとメンテナンスのしやすさが必要だからです。たぶん、LevelDB や他の Key-Value ストレージを試してみますか? どんな提案でも歓迎します。

===========

みなさん、ありがとうございました。最終的に、TokuDB と InnoDB の両方のパフォーマンスをテストして、私たちのユース ケースには十分ではありませんでした。

これで、bitcask のようなソリューションをストレージとして使用できるようになりました。Bitcask の追加専用スタイルの書き込みパフォーマンスは、予想よりもはるかに優れています。ハッシュ インデックスに関するメモリの問題を処理する必要があるだけです。

4

2 に答える 2

0

行を 1 つずつ挿入する場合は、可能であれば「insert into events (eventId,content) values (1,'value 1'), (2,'value 2'), ..." というのは、かなりの量のオーバーヘッド トランザクションが発生する可能性があるためです。また、TokuDB はリリースごとにパフォーマンスが向上しています。現在のリリースで実行することをお勧めします。

于 2012-09-14T02:28:50.590 に答える
-1

TokuDB の主な機能は次のとおりです。

  • ホット スキーマ変更:
    • ホットインデックスの作成: TokuDB テーブルは、インデックスがそのテーブルに追加されている間、ダウンタイムなしで挿入、削除、およびクエリをサポートします。innodb はB-Treeを使用しますが、インデックス作成にはフラクタル ツリーを使用します。
    • ホット列の追加と削除: TokuDB テーブルは、alter テーブルが列を追加または削除する際のダウンタイムを最小限に抑えて、挿入、削除、およびクエリをサポートします。

詳細については、TokuDB とは? TokuDB を mysql 5.1 にインストールするには?

于 2012-04-09T07:26:44.743 に答える