「強靭な骨」に敢えて挑む、オープンソース分散データベース TiDB はどのようにして誕生したのでしょうか?

[[245066]]

[51CTO.com からのオリジナル記事] 現在、ハードウェアのコスト効率はますます高くなり、ネットワークの伝送速度はますます高速になり、データベースの階層化のトレンドが徐々に現れています。ストレージに関するすべての問題を解決するために、1 つのソリューションを使用する必要はなくなりました。代わりに、階層化を通じて、キャッシュとデータベースはそれぞれが得意とするビジネス シナリオを担当します。

HTAP データベースである TiDB は、高性能な OLTP 機能を実装するだけでなく、リアルタイムのトランザクション データに基づくリアルタイムのビジネス分析ニーズも提供します。

2018年5月18日〜19日、51CTO主催のグローバルソフトウェアおよび運用技術サミットが北京で開催されました。

「ビッグデータ処理技術」セッションでは、PingCAP CTO Huang Dongxu が「HTAP がどのように役立つか: ATiDB ストーリー」と題した基調講演を行いました。

彼は、TiDB の設計アイデア、実際のアプリケーション シナリオ、および TiDB クラスターの展開と運用に関するベスト プラクティスを共有しました。

TiDB とは何ですか?

[[245067]]

TiDB はデータベースです。市場には MySQL や Oracle のようなデータベースが数多く存在していることはご存じのとおりです。新しいデータベースが必要なのはなぜですか?

皆さんの 90% が MySQL を使用したことがあると思います。しかし、MySQL のデータ量が大きい場合や同時実行をサポートできない場合、どのような選択肢があるのでしょうか?

[[245068]]

実際のところ選択肢はそれほど多くありません。 1つは、MySQLをまったく使用せず、NoSQLを使用することです。たとえば、データベースとして HBase や Cassandra を使用できます。

しかし、それに伴う代償として、SQL の複雑なクエリ機能と MySQL エコシステム全体が失われます。

NoSQL は水平方向の拡張機能をもたらしますが、ビジネス コード全体を書き直す必要があります。多くのシナリオではこれは現実的ではありません。

そのため、多くの場合、依然として MySQL を使用する必要がありますが、MySQL には量の面でさまざまな制限があります。したがって、過去に実行できたのは、シャーディング、水平パーティショニング、ライブラリとテーブルの分割でした。

しかし多くの場合、水平方向のセグメンテーションを実行してデータベースとテーブルを分割したとしても、スケールは依然として非常に大きな問題となります。

もう 1 つのポイントは、読み取りと書き込みの分離を使用する場合、または Cassandra のような使い捨てシステムを使用する場合、この新しい請求額は開発者にとって比較的大きくなるということです。

強力な一貫性と永続性を備えたストレージ システムがない場合、特に一部の金融シナリオや高い一貫性要件を持つビジネスでは、ビジネス レイヤーのコードを記述することが困難になります。

さらに、当社のデータ ウェアハウス、ビッグ データ分析ソリューション、データベース ソリューションは基本的に完全に分離されています。

過去 2 年間で一般的に使用されるようになった RabbitMQ や Kafka などのパイプライン システムは、データベースとデータ ウェアハウスの間に橋を架けようとする試みです。データベース レベルで直接リアルタイム OLAP を実行する方法はありますか?

または、現在 MySQL Sharding を使用しており、単純なクロスビジネス結合分析を実行したい場合は、分析のために ETL を介してデータを Hadoop またはデータ ウェアハウスにインポートする必要があります。

ETL プロセスの維持は、かなり面倒な作業です。もうひとつの問題は、データアナリストはエンジニアや高度な技術力を持った人ではない可能性があるため、技術の選択にさまざまな制約が生じることです。

データベース上で直接インプレースクエリを実行することは可能ですか?これは質問です。もう 1 つの大きなトレンドは、データベースなどのビジネスを既存のクラウド アーキテクチャと統合する方法について誰もが考えていることです。

たとえば、コンテナがクラッシュするとデータが失われるため、MySQL インスタンスをコンテナに直接配置することはできません。

クラウド環境やコンテナ環境向けに、弾力的にスケーラブルなデータベースをどのように設計するかは、実は大きな問題です。

もう一つの特に大きな問題点は、高可用性を確保する際に人がミスをしてしまうことです。データベースを構築するときにこれらの問題が発生する理由は何でしょうか?

個人的には、MySQL や Oracle などのリレーショナル データベースは分散用に設計されていないと思います。

さらに、データベースとテーブルを分割するなどの操作を実行できたとしても、本質的には MySQL を再度コピーしているだけであり、分散システムとしてストレージとコンピューティングを最適化しているわけではありません。

これが問題であり、ビジネス間クエリや物理マシン間クエリおよび書き込みを実行するのが面倒だと感じる理由です。

しかし、2000 年以降、分散システム理論が主流になり始めたため、この状況は最終的に変化しつつあります。

これには歴史的な背景があり、昔はハードウェアが高価で、ネットワーク環境も悪かったのです。したがって、可能な限りローカルで計算を行うようにしてください。

SSD の登場により、ディスク IO は基本的に大きな問題ではなくなり、Intel はまもなく永続メモリをリリースする予定です。このようなテクノロジーは基本的に、データベース IO 層の問題を解決します。

現在、Google では、リモート ディスクの読み取りと同じデータセンター内のローカル ディスクの読み取りのスループットとレイテンシは基本的に同じです。

この場合、データセンター全体をコンピューターとして考えることができ、データベースを再設計すると、本質的には分散システムになります。

3つ目のポイントは、人々の考え方が変化しているということです。人々はもはや、すべてのストレージ問題を解決する完璧なソリューションを夢見ていません。

メンテナンスが簡単

TiDB プロジェクトは 3 年前に始まりました。上記で紹介したプロジェクトの背景です。私はこれまで Wandoujia で MySQL クラスターを保守してきました。

その後、リレーショナルデータベースはメンテナンスが難しいため、MySQLとNoSQLの利点を組み合わせたデータベースがあるのではないかと考えるようになりました。

これが当初の本来の意図です。私たちは、少なくとも一般的に使用される複雑なクエリとサブクエリについては、既存のものと互換性のある完全に機能する SQL を作成したいと考えています。

同時に、顧客やユーザーに MySQL プロトコルと使用方法を説明する必要があります。これは、ユーザーが製品を試すためのコストを大幅に削減できるため、非常に重要です。

取引

2点目は、絶対に欠かせない事務です。過去 10 年間の NoSQL コミュニティの大きな問題は、スケーラビリティを追求してきたものの、強力に一貫性のあるトランザクションのサポートを放棄してきたことであり、これは間違いだと思います。

これまでこの機能を実装しなかった理由は、システムの遅延やパフォーマンスの低下を引き起こす可能性があるためでした。しかし、データの正確さを犠牲にしてこの機能を実現するのは非現実的だと思います。

これは、データベースがこのタスクを実行する必要があるにもかかわらず、これらの NoSQL システムがビジネス レイヤーにこのタスクを強制的に実行しているという事実に相当します。これはライティング業務に大きな問題を引き起こします。

もう 1 つは、拡張の容易さ、つまりそれが実現可能かどうかです。私はこれをプッシュ ボタン スケーリングと呼んでいます。

再シャーディングや構成の変更を行わずに、単にマシンを投入するだけで、システムは拡張され、自動的に再バランスが取られました。これは、従来のシャーディング ソリューションとは根本的に異なります。

高可用性

ではHAとは何でしょうか? HA は高可用性の略で、従来のソリューションでは解決が難しい問題です。つまり、データの検証やトラフィックの切り替えなど、すべて手作業が必要になります。

真の HA を実現する方法はありません。データベースは自動的に操作、保守、修復し、システムの可用性を確保できますか?

私たちもこの分野でいくつかの作業を行ってきました。以下のデータ モデル全体でマスター スレーブ モデルを完全に廃止し、Raft や Paxos などの分散選択アルゴリズムに完全に基づいています。

これは非常に重要です。システムの可用性を保証できない場合、特に OLTP システムの場合、パフォーマンスについて語ることは意味がありません。

私のシステムは、Spark または Hadoop を使用してクラスター全体のコンピューティング リソースと機能を活用し、複雑な SQL クエリを高速化しながら、ACID トランザクションをサポートできますか?これは実際に実行可能です。

オープンソース

第一のポイントは、オープンソースでなければならないということです。一般的な技術ソフトウェアは、オープンソースでなければ将来性がありません。

時代が変わったからです。密室で製品を開発し、多数の営業担当者を雇用し、ドアをノックして試用したいかどうかを尋ねるという従来のアプローチは、特にプラットフォームベースのソフトウェアの場合、間違っています。

さらに、オープンソースはソフトウェアのプロモーションにも役立ちます。ユーザーが増えれば増えるほど、より多くのフィードバックが得られます。

これは、社内でソフトウェアを開発するよりもはるかに高速になります。そのため、プロジェクト開始からわずか 3 年で、顧客数は 2,000 社を超えています。

TiDBデータベースの4つの「キラー機能」

ここで、皆さんのビジネスで活用できる TiDB データベースのアプリケーション シナリオをまとめてみましょう。

ユースケース 1: MySQL のシャーディングとマージ

最初のシナリオは MySQL です。例えば、既存の業務でMySQL Shardingを使用している場合は問題ありません。現在、TiDB はビジネス レイヤーで MySQL のアクセス プロトコルとリアルタイムで互換性があります。

また、TiDB を MySQL マスターのスレーブとして使用できる Syncer というツールも開発しました。ビジネス層のフロントエンドでは、マスターデータベース MySQL になることができ、スレーブデータベースとしての TiDB は、大規模な MySQL と見なすことができます。

以前は「1 つのマスターと複数のスレーブ」と言われていましたが、TiDB では代わりに「複数のマスターと 1 つのスレーブ」と言うことができます。

これらの複数の MySQL グループの異なるテーブル、異なるビジネス、異なるライブラリのリアルタイム Binlog データを同期し、大規模な分散 MySQL に集約できます。

この分散型 MySQL が TiDB です。この MySQL では、join や groupby などのより複雑なクエリを使用できます。これはユーザーシナリオです。

[[245069]]

Syncer とは何ですか?先ほど簡単に触れましたが、Syncer は MySQL スレーブに偽装してデータを同期できるツールです。

これは本質的に、MySQL の Binlog をリッスンし、それをデータベース ステートメントに変換する Binlog リスナーです。

ユースケース 2: MySQL の代替品

もう 1 つのアプリケーション シナリオは非常に単純で大まかです。最も単純なケースは、ビジネスが急速に成長しているものの、元のビジネスが MySQL で記述されており、シャーディング、テーブル シャーディング、アーキテクチャなどについては考慮されていなかったというものです。

Mobike は初期の頃は MySQL を使用していました。その後、ビジネスが急速に成長し、チーム規模が 30 人になった時点で TiDB の使用を開始しました。

その後、1 年以内に会社全体の従業員数は 800 人に増加し、データセットは非常に小さなデータセットから TiDB 上の数十 TB のデータにまで拡大し、データベースやテーブルをシャードする必要がなくなりました。

したがって、TiDB は、ビジネスが急速に成長しているシナリオでは適切な選択肢であり、OLTP ビジネスにも適しています。

スループットの点では、TiDB は基本的に線形拡張を実現できます。マシンの数が増えるほど、パフォーマンスは向上します。レイテンシに関しても、TiDB のパフォーマンスは非常に優れています。

ユースケース 3: データ ウェアハウス

もう 1 つの使用シナリオは、TiDB をデータ ウェアハウスとして直接使用することです。 TiDB は OLAP パフォーマンス評価において非常に優れたパフォーマンスを発揮します。

特に複雑な SQL がある場合、TiDB の SQL レイヤーではそれを処理できません。私は TiSpark というオープンソース プロジェクトも開発しました。

これは実際には Spark プラグインであり、ユーザーは Spark SQL を直接使用して TiKV でビッグ データ分析をリアルタイムで実行できます。

3 番目のアプリケーション シナリオは、TiDB 自体がストレージとコンピューティングを分離するプロジェクトであるというものです。その下の Key-Value レイヤーも個別に使用できます。行間トランザクションをサポートしながら、Hbase の代替として使用できます。

TiDB プロジェクトは実際には Google Spanner システムに触発されており、NoSQL レイヤーを通じてトランザクションをサポートしています。

TiKV は 2 層の API を提供します。 1 つのレイヤーは、銀行間の取引をサポートする API です。第 2 層 API は弱い API と呼ばれ、主に単一行のトランザクションに使用されます。行間トランザクションに対する ACID サポートは提供されませんが、その代わりに全体的なパフォーマンスとレイテンシがさらに向上します。

したがって、必要に応じて、トランザクションはトランザクション API を使用できます。パフォーマンスは必要だが、強い一貫性を持つ銀行間トランザクションは必要ない場合は、弱い API を使用します。弱い API の一貫性レベルは Hbase と同じです。

ユースケース4: 他のシステムの構成要素として機能

ユニバーサル KV レイヤーに基づいて、やりたいことが数多く実現できます。 TiDB は単なる単純なデータベース プロジェクトではありません。これは他の分散システムの構成要素となるはずであり、他のシステムを構築するための基礎として機能することができます。

TiDB 自体は外部への MySQL インターフェイスを提供しますが、コミュニティの友人は TiKV レイヤーの Redis プロトコル レイヤーを直接カプセル化します。

その後、ユーザーは Redis プロトコルを直接使用して TiKV を実行できます。これにより、永続的でスケーラブルな Redis が実現します。

次に、Toutiao が使用する、外部に S3 を提供する別のケースがあります。独自の S3 を構築したい場合でも問題ありません。

ただし、S3 の構築で最も難しいのはデータ ノードではなくソース情報の管理であるため、クロストランザクションをサポートするソース情報ストレージ システムがすでにある場合は、S3 を自分で構築できます。

コミュニティの一部の人々が、まったく新しい分散ストレージ サービスを構築したことを知っています。 APIはまだオープンソースではありませんが、近い将来オープンソースになると思います。

MySQL から TiDB に移行するにはどうすればいいですか?

TiDB は非常に優れているので、MySQL を TiDB に移行するにはどうすればよいでしょうか? TiDB は実際には MySQL エコシステムに基づいているため、もちろん MySQLDump を使用できます。

私たちは Lightning と呼ばれる独自のデータインポートおよびエクスポートツールを作成しました。なぜこれをするのですか?

たとえば、以前は、MyDumper と Myloader を使用して MySQL プロトコルを直接使用していた場合、エクスポートとインポートは単純で大まかなものでした。

それで、TiDB は何をしたいのでしょうか?ご存知のとおり、MyDumper がダンプするのは MySQL ステートメントです。

次に、TiDB 側では、すべてを SQL からそのパーサー、実行プラン、トランザクション ガイダンス、KV に渡し、最終的にスタンドアロン RocksDB に書き込む必要があります。

このプロセスは何度も繰り返されますが、以下に示すように、非常に遅いプロセスです。

途中のすべての処理をバイパスし、MyDumper によってダンプされた SQL ステートメントを直接使用して、基礎となる RocksDB データの形式を直接生成する方法があるかどうか疑問に思いました。もちろんできますよ。

ライトニングはまさにそれをやっているのです。これは、SQL ステートメントを直接ダンプする MySQLDumper のアップグレード バージョンと考えることができます。

次に、TiDB Lightning プロジェクト内で Record to KV を直接実行し、基礎となるキーと値のペアを直接生成しました。そして、同時に内部的にデータのシャーディングが行われ、それが事前に行われます。

3 番目の方法は、途中のすべての SQL ステートメントをバイパスし、RocksDB SSD ファイルを直接生成することです。これは、ストレージ形式のファイルを別のマシンに送信するのと同じです。その後、このマシンはファイルを直接データベースにロードし、プロセスが完了します。

TiDB をデプロイするために Ansible を選択しました。すべてのデプロイはワンクリックで完了できます。パフォーマンスチューニングを含むすべてが完全にオープンソースになります。

現在、TiDB プロジェクトを CNCF Foundation に寄付し、Kubernetes と統合しています。現在はテスト段階ですが、将来的には間違いなくオープンソースになります。

もちろん、ローカルで自分で試してみたいという場合は、TiDB には非常に多くのコンポーネントがあるため、1 つのコマンドを使用して、テスト用に完全な TiDB Cluster をローカルで構築できますか?もちろんできますよ。

ここには Docker Compose があり、これには 2 つのパスがあります。1 つは git clone、もう 1 つは startup です。

ダッシュボード、データ移行、視覚化、TiDB MySQL サービス エンドポイントが開始され、TiSpark がすべて Docker コンテナー内に作成されます。

さらに、これだけでは十分ではありません。いくつかのコアアルゴリズムが正しいことを数学的手法を通じて正式に証明します。

TLA+ のソースコードファイルはオープンソースです。 TLA+ を使用して独自の分散システムで数学的な証明を行う場合は、私たちが作成したドキュメントを参照してください。ですから、テストは実はこの会社の最も重要な資産であると私は考えています。

要約する

***、この間ずっと考えてきた大きな問題がいくつかあります。たとえば、クラスター全体をクラウドベースにした後、データベース レベルでマルチテナントをどのように実装すればよいでしょうか?つまり、より効果的なリソースの分離と再利用を実現するにはどうすればよいでしょうか?

IO 全体の分離が依然として大きな問題であるため、現時点では適切な解決策はありません。

2つ目は自律性です。このデータベースはインテリジェントになり得ますか?つまり、手動での操作やメンテナンスは不要になります。

このデータベースは、それ自体で展開、保守、更新できます。データに問題がある場合は、自分で修正できます。パフォーマンスに問題がある場合は、自分で最適化することができます。

また、いくつかの運用メトリックを Tensorflow にインポートして、自動的に最適化を実行しようとしています。この作業は実行中であり、CMU はさらに興味深い作業を行う必要があります。

ソフトウェアとハ​​ードウェアの組み合わせ、つまり、これらの新時代のハードウェアを使用してデータベース全体の安定性を向上させる方法もあります。

[[245070]]

PingCAP の共同創設者兼最高技術責任者、Huang Dongxu 氏。彼は分散システムとデータベース開発の専門家です。彼は分散ストレージに関する豊富な経験と独自の洞察力を持っています。彼は、広く使用されている分散 Redis キャッシュ ソリューションである Codis と、分散リレーショナル データベースである TiDB の共同創設者です。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]