web-dev-qa-db-ja.com

Percona上のTokuDBエンジンをより速く削除する方法

私はperconaのWebサイトでいくつかの読書をしましたが、特に MySQL Partitioning：A Flow Chart は、パーティションではなくinnoDBよりも高速な（er）削除のソリューションとしてTokuDBを推奨しています。

サンプルテーブルを取得し、両方のテーブルに同じ2000万行を追加しました。次に、通常は静かなマシン（追加のラップトップ）で約200k行を削除してテストを実行しています。

InnoDBとTokuDBで20万行を削除しても速度に違いはありません。それらは時間的に数％以内です（つまり、45秒vs 43秒）。

Percona 5.6をTokuDBエンジンと一緒にUbuntuにインストールしましたが、それ以外の構成は行いませんでした。

誰かが私が欠けているかもしれないものを提案できますか？

テーブルは次のようになります。

CREATE TABLE `testTable` (
    `id` int(11) NOT NULL AUTO_INCREMENT,
    `filename` varchar(200) DEFAULT NULL,
    -- 20-ish columns
    PRIMARY KEY (`id`),
    KEY `filename` (`filename`),
    CLUSTERING KEY `clstr_key` (`filename`),
    -- 3 or 4 other indexes
) ENGINE=TokuDB AUTO_INCREMENT=20000000 DEFAULT CHARSET=uft8

次のような結果を測定するために、いくつかの方法で削除を試みました。

DELETE FROM testTable WHERE id BETWEEN :start AND :end;
DELETE FROM testTable WHERE filename IN ('FilenameA', 'FilenameB', 'FilenameC');
-- Where dateCol is indexed
DELETE FROM testTable where dateCol BETWEEN :start AND :end;

結果はすべての方法でTokuDBとInnoDBの両方でかなり類似していた。

mysqlperconatokudb
3
Erik

テーブルに1つ以上のセカンダリインデックスがある場合、各削除ではプライマリキーインデックスを読み取り、各セカンダリでの削除に必要なフィールドを取得する必要があるため、InnoDBに対するTokuDBの利点の多くが失われます。また、削除パターンが「左端」である場合、または特定のキー範囲で大量の削除を実行している場合は、フラクタルツリーインデックスにかなりのガベージが生じ、クリーンアップする必要があります。テーブル/インデックスの最適化。

3
tmcallaghan

（この回答は、TokuDBではなくInnoDBに関連しています。）

:startと:endが本当に「最も古いデータ」である場合は、パーティションのスライドセットについて説明できます。そのような場合、DROP PARTITIONを使用して、数百万の行を「瞬時に」削除できます。 さらなる議論 。

約50を超えるパーティションがあると、パフォーマンスが低下します。したがって、何百ものファイル名がある場合、それぞれを別々のパーティションに配置することはお勧めできません。

200K行を「瞬時に」削除する必要がない場合は、別のアプローチについて説明しましょう。テーブルをウォークスルーして、一度に1000行を削除します。他の活動を著しく妨げることはありません。おそらく43秒よりも長くかかります。突然の大きな削除のように、元に戻す/やり直しログが詰まることはありません。そして、いくつかのコードが必要になります。 here は、それを効率的に行う方法の説明です。

1
Rick James