TiDB移行後の性能と運用面での効果
HBaseからTiDBへの移行においては、MySQLからの移行のように公式ツールが用意されていない。サイバーエージェントでは大規模移行となったため、それを高速に行える仕組みも必要となった。そこで利用したのはSparkだ。Hadoop Inputフォーマットが利用でき、HBaseのスナップショットテーブルを読み込めるだけでなく、JDBCを用いてTiDBにデータを書き込める点が決め手になったという。
はじめにHBaseのデータを正規化してTiDBにテーブルを作り、HBaseとTiDBの双方に書き込む。このとき、HBaseとTiDBの双方で、書き込みが失敗した場合のリトライやエラーハンドリングを考慮しておく必要がある。その後、HBaseのテーブルスナップショットを作成すると、Sparkを利用して移行先のTiDBテーブルに書き込みを実行。二重書き込みを終了後、TiDBのみに書き込むように設定することで移行を完了できると渡邉氏。
なお、Sparkジョブの実装にはカスタムデータソースが用いられている。これは、JDBCデータソースでは「INSERT IGNORE」など特定のInsertオプションを使用できないためだ。また、HBaseからのデータ取得時にスキーマ変換を手動で行う必要があり、ここには時間と労力がかかってしまうという。実際にサイバーエージェントでは、こうした方法でダウンタイムなしに移行を完了している。もちろん、インクリメントやコンペアアンドスワップの操作など、データ間での依存関係が強い部分がある場合には、ダウンタイムなしで移行することが難しいケースもあるという。
現在、移行後の環境では、ノード障害などが発生するも問題なく自動復旧できており、障害対応にともなう運用負荷が上がることはないとする。また、マルチテント環境下でユーザー管理も問題なく実現されており、MySQL互換という特性からさまざまなツールが使えることも負担軽減につながっているという。
なお、スループットについては並列数を上げることで、HBaseと変わらない性能を発揮できており、レイテンシーは若干劣るが許容範囲に収まっているとした。
これについては、HBaseはクライアントから直接リージョンサーバーにアクセスするが、TiDBコンポーネントはステップ数が増加することが悪化の要因ではないかと渡邉氏。他にもバッチによる書き込みにおいて問題が発生した際には、RocksDBプラグインである「Titan」を適用することで解消できたとも説明する。
最後に渡邉氏は、HBaseからTiDBへの移行における留意点として、クエリエンジンの接続部分で問題が発生しやすかったり、バッチで書き込む際には追加実装やチューニングが必要だったりする点を挙げた。今後は、次世代のTiSparkの機能拡張で課題解決を進めていくだけでなく、ベクトル型データを格納したいとの要望も多いため、ベクトル探索機能の実装にも期待するとして講演を締めくくった。
