問題タブ [tokudb]

データ構造 ：

メインテーブル (5 億) :

テーブルの作成USER_DETAILS(

visitor_idvarchar(50) デフォルト NULL、

partition_id INT、

related_text ロングテキスト、

creation_dateタイムスタンプ DEFAULT CURRENT_TIMESTAMP,

主キー ( visitor_id,partition_id) )

ENGINE=トクDB

PARTITION BY LIST (partition_id) (

PARTITION p0 VALUES IN (0) ENGINE = TokuDB,

PARTITION p1 VALUES IN (1) ENGINE = TokuDB,

PARTITION p2 VALUES IN (2) ENGINE = TokuDB,

PARTITION p3 VALUES IN (3) ENGINE = TokuDB,

PARTITION p4 VALUES IN (4) ENGINE = TokuDB,

PARTITION p5 VALUES IN (5) ENGINE = TokuDB,

PARTITION p6 VALUES IN (6) ENGINE = TokuDB,

PARTITION p7 VALUES IN (7) ENGINE = TokuDB,

PARTITION p8 VALUES IN (8) ENGINE = TokuDB,

PARTITION p9 VALUES IN (9) ENGINE = TokuDB);

中間テーブル (10 ～ 20 ミリオン):

テーブルの作成USER_DETAILS_INTERMEDIATE(

idbigint(20) NOT NULL AUTO_INCREMENT、

Visitor_id` varchar(50) DEFAULT NULL,

partition_idint(11) デフォルト NULL、

related_text長文、主キー ( id));

問題 ：

中間テーブルからメイン テーブルにデータを転送するときに時間がかかりすぎます。

次の解決策を試しました：

解決策 1:

REPLACE INTO USER_DETAILS(visitor_id, partition_id, json_list)

SELECT ビジター ID 、パーティション ID 、関連テキスト

FROM USER_DETAILS_INTERMEDIATE a

解決策 2 (ループで次のステートメントを実行: ループごとに 10000 行):

REPLACE INTO USER_DETAILS(visitor_id, partition_id, json_list)

SELECT ビジター ID 、パーティション ID 、関連テキスト

FROM USER_DETAILS_INTERMEDIATE a

WHERE id BETWEEN var_min_id AND var_max_id ;

上記のクエリには両方の時間がかかります。

これを改善する別の方法はありますか..？

何度か試した後、最終的に Homebrew を使用して Macbook に Percona をインストールし、MySQL Workbench 経由で正常に接続しましたが、XtraDB テーブルを作成したい場合:

TokuDB でも同じエラーが発生します。

Percona は InnoDB だけでなく、XtraDB と TokuDB の両方をサポートしていることを読みました。どこかでテーマを有効にする必要がありますか?!

私は2つの同時実行ステートメントを実行しています:

• Insert into tab2 select * from tab1 where ....; -- tab1 はパーティション化された tokudb テーブルです
• tab1 の値に挿入 (...);

tab1 はテーブル ロックを取得し、2 番目の挿入は「テーブル レベル ロックの待機中」を待機しています。

何か案は？

ありがとう、

次の 2 つのクエリは、国名を除いてまったく同じです。クエリ 1 では「マレーシア」、クエリ 2 では「インド」です。

クエリ自体が間違っています。私はac.country最初のサブクエリで " " を使用していますが、実際には " ass.country" を使用する必要がありましたが、クエリ 1 では結果を取得していますが、クエリ 2 では NULL を取得しています。

誰かがなぜこれが起こっているのか説明できますか.

クエリ 1:

クエリ 2:

注 : MySql のバージョンによって出力が異なることも付け加えておきます。

TokuDB 7.5で、バッチごとに約1000レコードの同時バッチ挿入があります。各バッチ更新は、1 つのトランザクション内で行われます。このテーブルには、約 1 億件のレコードも含まれています。

問題は、次の例外が時々スローされることです。

java.sql.BatchUpdateException: ロック待機タイムアウトを超えました。トランザクションを再開してみてください

使用されるトランザクション分離レベルは Repeatable_Read であり、記事で Repeatable_Read を使用すると SELECT クエリのギャップ ロックが発生することを読みました。

しかし、現時点では INSERTS しかありません。

このロック タイムアウトはギャップ ロックが原因である可能性がありますか?もしそうなら、同時 INSERTS はギャップ ロックによってどのように影響を受けますか?

スキーマ

)

Fedora 24 + MariaDB 10.1.17 では TokuDB が利用できないようです。

jemalloc と jemalloc-devel をインストールしました

じぶんの/etc/my.cnf/tokudb.cnf

さらに、/etc/selinux/config で SELinux が無効になっています。

20 ギガのデータを格納する新しいテーブルを作成しました。インデックスの設定を間違えました。実際、私のインデックスはすべて良好で、そのうちの 1 つは 3 つの列の間の UNIQUE KEY です。通常、このキーは PRIMARY KEY である必要があります。

テーブルを変更する時間のコストを見積もりました。そして、私はそれを買う余裕がありません.1日かかります.

私の質問は: UNIQUE KEY を PRIMARY に変更するのに本当に便利ですか?

パフォーマンスは向上しますか?

エンジン（TokuDB）が悪いものを選択し、パフォーマンスが大幅に低下するため、いくつかのリクエストで使用するインデックスを説明する必要があります。

個人的には、テーブルのデザインが悪いという事実を除けば、何かが変わるとは本当に思いません。

TokuDB だけでも、ベンチマークで InnoDB を約 25% 上回っていましたが、InnoDB をマスター/スレーブにすると、TokuDB が約 20% 勝っています。

何が起こっているのか

これは、r4.8xlarge aws マシンで実行されている conf です。

tokuDbエンジンを使用したmariadbテーブル。以下のエラーが発生しています-deleteステートメントのいずれかです。バックグラウンドの挿入負荷があり、その逆もあります。

Lock wait timeout exceeded; try restarting transaction

tokuDb は、ステートメントがタイムアウトするまでの待機時間を決定するために更新できる設定を使用しますか?

tokuDb ドキュメントに答えが見つかりませんでした。maria 変数はまだデフォルト値の 'lock_wait_timeout', '31536000' のままですが、私のタイムアウトは 1 年も経たないうちに戻ってきます。負荷テスト中にタイムアウトが発生します。エラーに時間の値は見つかりませんでしたが、数秒のように感じます。タイムアウトがスローされるまでに最大で数分。

ありがとう、ブレント