MySQLでシャーディングするなら、最初からTiDBで
続いて、「TiDBに特化したような設計や運用は必要か」との質問がなされた。これに対し北川氏は、書き込み時の性能を見ると高い並列度で処理し、拡張していくとQPSが少しずつ伸びることがTiDBの特長の1つであり、そこを意識して設計すべきだと指摘する。また、性能が発揮されない原因となるホットスポットを解消するために、“分割リージョン”のオプションを有効にしたと北川氏。他にも「TiUP」では監視などでも活用でき、当初から運用を容易にすることを念頭に置いてTiDBは構築されているようだとも話す。
一方、気になった点としては、パラメーターの設定方法が統一されていないことだと指摘すると、「監視などのメトリックが多すぎるとも感じますね」と北川氏。メトリックが多ければ状況は詳細に把握できるが、多すぎると情報の取捨選択に頭を悩ますことにもなる。さらに、アラートのレベルがクリティカル（Critical）、エマージェンシー（Emergency）、ワーニング（Warning）と3つに分かれているが、ワーニングの量が多いとも話す。
とはいえ、1年半ほどTiDBを稼働させている中、多くのワーニングアラートが上がってくる一方、障害はこれまで発生していないとのことだ。
また、MySQLとの使い分けについてはゲーム向けのサービスなど、シャーディングを用いて分散させることが想定されるような場合、最初からTiDBを採用しても問題ないと北川氏。
三谷氏は、指定したカラム（フィールド）にデータが追加されると、一意の値を自動的に付与する機能“AUTO_INCREMENT”の動きには注意が必要だと指摘する。TiDBでは性能を担保するために、PD（Placement Driver）から発番されたa-i番号をキャッシュするアーキテクチャとなっており、発番は単調増加にはならず順番がとばされるという。これはMySQLとは異なる動きでありTiDB独自の挙動のため、適宜発番がとばないような設定に変更する必要があるだろう。なお、メトリックがMySQLとは異なるため「自前の監視ツールなどを利用している場合、そのまま動かない可能性があります」ともアドバイスする。
これらTiDBに実際に触ったからこその意見を踏まえた上で、林氏から「MySQLからの移行にTiDBが利用できるか」との質問があらためて投げかけられた。LINEヤフーでは移行のための検証はしていないが「『LINEマンガ』のように急成長のため、MySQLのシャーディングに苦労しているようなサービスでは、TiDBに移行できると助かるでしょう」と北川氏。MySQLでは、シャーディングを想定していないものを変更することは大変であり、既存のMySQLをそのままTiDBに移行できるのならば負担は少なく、かなり便利だろうと述べる。
三谷氏は、MySQLとの互換性は高く、その上でデータベースのサイズが10TBと大きいケースでも、移行が1日で済んだと高く評価する。また、移行後のデータチェックツールなども標準で用意されている点は便利だという。その上で、実際にメルカリのサービスで利用しているMySQLをTiDBに移行させるかどうかは、レイテンシーへの要件次第だと三谷氏。TiDBは分散構成となるため、どうしてもレイテンシーの観点からは不利な側面もあるが、移行における課題となるケースもあると林氏も述べる。
なお、講演の中では、「検証において想定外の性能劣化などはあったか」との質問も投げかけられた。分散型データベースの構成では、多くのノードからデータを集めてくるようなクエリの場合、どうしてもレイテンシーに係わる問題が発生する。しかし三谷氏は、それは想定内であり、メルカリでは大きな問題はなかったという。JOINクエリについても問題は見られず、特にインデックスを追加することなく既存のMySQLのままで利用できたとした。
今回のパネルディスカッションでは「TiDBは使えるか討論 MySQLのプロがTiDBを斬る」をテーマに、TiDBの特長だけでなく実際に運用する上での注意点など、今後TiDBを検討しているイベント参加者に向けて、ユーザー目線の深い知見が共有された。大規模な本番環境を想定したTiDBの検証については、詳細な日本語情報がまだ多いわけでない。そのためもあってか、MySQLをよく知る両氏のリアリティのある話に満席となった会場では多くの参加者が熱心に耳を傾けていた。
