[再版] TiDBに関する10の質問：アーキテクチャ設計に関するいくつかの考えTiDB

TiDBの起源は、質問について考えることから始まります。なぜ、データベース分野には避けられないほど多くの穴があるのでしょうか。2015年に最初のコード行を記述して以来、過去3年間で数え切れないほどの問題に遭遇しました。考えながらそれを実行し、最小のコストで迅速に実行することを試みなければなりません。

TiDBはオープンソースプロジェクトとして、インフラストラクチャエンジニアとコミュニティの努力の成果です。TiDBは2.0にリリースされており、比較的安定した形式で、実稼働環境で使用される多数のパートナーを持っています。私たちが下す決定は、非常に慎重な思考と実践を経たものであり、内部およびコミュニティによるデモの結果であると責任を持って言えます。最高ではないかもしれませんが、この段階では私たちにとって最も適しているはずです。また、TiDBが急速に進化していることもわかります。

この記事は、TiDBの代表的な「なぜ」のトップ10についてです。私たちの背後にある選択肢を理解した後、TiDBをより上手に使用して、適切な環境でTiDBをより良い役割を果たすことができれば幸いです。

この世界には、自分が思っている以上に感じ、答えよりも多くの質問をする人がたくさんいます。疑問を解消していただきありがとうございます。結局のところ、多くの思考も非常に興味深いものである場合もあります。

1. 分散システムが特効薬ではない理由

実際、特にストレージの分野では、完璧ですべての病気を治療するテクノロジーはありません。データをMySQLにインストールでき、サーバーのプレッシャーが大きくない場合、または複雑なクエリのパフォーマンスが高くない場合は、実際に分散されます。データベースは特に良い選択ではありません。分散アーキテクチャを選択することは、追加のメンテナンスコストを導入することを意味します。このコストは、特に小規模ビジネスにとってそれほど費用効果が高くありません。高可用性機能が必要だと言っても、MySQLマスタースレーブレプリケーション+ GTIDソリューションは基本的に、十分ではないにしても、最近導入されたグループレプリケーションもあります。また、MySQLコミュニティは、Googleでのほとんどすべての一般的な質問に対する回答を見つけるのに十分な大きさです。

TiDBを作成する当初の目的は、MySQLを少量のデータで置き換えることではなく、スタンドアロンデータベースでは解決できないいくつかの重要な問題を解決しようとすることです。

多くの友人から、分散データベースを選択するのに適した時期はいつかと尋ねられました。それはすべての会社やすべてのビジネスで異なると思います。全体に共通の標準を与えたくありません（またはこの標準が存在しない可能性があります）が、いくつかのイベントが現れ始めます：たとえば、データベースが到着したことがわかりました。データのバックアップ、移行、拡張について毎日一生懸命考え始め、3日ごとにストレージスペースと複雑な低速クエリを最適化することを考え始めるか、無意識のうちにデータベースミドルウェアソリューションを調査し始めたとき、または人間の肉がコードの中にいるとき。シャーディングを行うときは、TiDBが役立つかどうかを思い出してください。

そして、その一方で、TiDBとMySQLの選択は万能のプロセスではありません。MySQLユーザーが移行と変換のコストを最小化できるように、データ全体の移行とグレースケールを可能にする多くのツールを作成しました。オンラインへの移行がスムーズになり、TiDBからシームレスに移行することもできました。小規模なデータ量のビジネスで引き続きMySQLを使用できます。したがって、ビジネスとデータ量がまだ小さい場合は、MySQLを自信を持って使用してください。MySQLはまだ揺るぎなく、TiDBは将来的にあなたを待っています。

第二に、なぜMySQLなのか

上記のように、MySQLが良くないということではありません。彼を置き換える必要がありますが、MySQL互換のエコシステムの選択は、ユーザーの実際のシナリオに最も近い選択です。

MySQLコミュニティは十分に大きく、特に優れた大規模な基盤を持っています。新しいデータベースとして、ユーザーが新しい構文のセットを習得する必要があり、大量のビジネス移行が伴う場合、新しいプロジェクトのコールドスタートには非常に好ましくありません。。
MySQLは長期間にわたって多数のテストケースを蓄積してきました。MySQLに依存するさまざまなサードパーティのフレームワークやツールのテストケースは、特に初期の段階では重要なテストリソースです。データベースが正しいことをどのように証明するのですか、MySQLテストは私たちの定規です。
MySQLを使用している既存の企業はすでに多数存在し、スケーラビリティの問題に直面していますが、この部分のシーンと直接的な問題があるユーザーをあきらめることも賢明ではありません。

一方、MySQLはOracleに買収されて以来、ここ数年でパフォーマンスと安定性の両方が着実に改善されており、特定のシナリオでも、Oracleに取って代わることができるようになりました。主要な開発動向の観点から非常に健康なので、この健全なコミュニティとともに成長することも、私たちのビジネス戦略です。

3. TiDBの設計でSQLレイヤーとストレージレイヤーが分離しているのはなぜですか

明らかな理由は、操作とメンテナンスのしやすさです。多くの人々は、この場所は直感に反すると思います。コンポーネントを1つ追加するだけで、導入の複雑さが増すのではないですか

実際、実際の本番環境では、運用と保守にはデプロイメントだけが含まれていません。たとえば、SQLレイヤーでバグが見つかり、緊急に更新する必要がある場合、すべてのコンポーネントが結合されていると、クラスター全体のローリング更新に直面します。適切に階層化されている場合、必要なのは更新のみです。ステートレスSQLレイヤー、およびその逆。

もう1つのより深い理由はコストです。ストレージとSQLは異なるコンピューティングリソースに依存します。ストレージはIOに依存し、計算にはより高いCPUとメモリが必要です。PCIe/ NVMe / Optaneおよびその他のディスクを構成する必要はなく、2つは必ずしも同等ではありません。それらがすべて一緒に結合されている場合、リソースのスケジューリングに適していません。TiDBの場合、目標はHTAPをサポートすることです。つまり、OLTPとOLAPは同じシステム内で完了する必要があります。明らかに、ワークロードが異なれば、SQLレイヤーの物理リソース要件も異なります。OLAP要求は、よりスループット優先の長いクエリです。OLTPは、短くて高速な要求を重視する一方で、多くのメモリを消費します。最適化はレイテンシとOPS（1秒あたりの操作）。TierSQLレイヤーはステートレスであるため、さまざまなワークロードをさまざまな物理リソースに振り分けて分離を実現できます。繰り返しになりますが、これはスケジューラーにとって使いやすく、スケジューリング期間のアップグレードでクラスター全体をアップグレードする必要はありません。

一方、基盤となるストレージはKVを使用してデータを抽象化しますが、これはより柔軟なオプションです。

1つの利点は単純さです。スケールアウトのニーズに対して、KVキーと値のペアをスライスすることの難しさは、複雑なテーブル構造を持つ構造化データの難しさよりもはるかに少ないです。さらに、ストレージレイヤーは、抽象化後に次のような新しいオプションを計算にもたらすこともできます。他のコンピューティングエンジンと接続し、それらをTiDB SQLレイヤーと並行して使用するTiSparkは、良い例です。

開発の観点から見ると、この分割によってもたらされる柔軟性は、開発するさまざまなプログラミング言語の選択にも反映されます。ステートレスコンピューティングレイヤーについては、Goなどの開発効率の高い言語を選択しました。ストレージレイヤープロジェクトTiKVについては、システムの下部に近く、パフォーマンスの影響を受けやすいため、すべてのコンポーネントでRustを選択しました。このようなオンデマンドの多言語開発を一緒に実行することは困難です。開発チームにとって、専門家は専門的なことも行うことができます。ストレージエンジンの開発者とSQLオプティマイザの開発者は並行して開発できます。さらに、分散システムの場合、すべての通信はほぼRPCであるため、より明確な階層化は自然で安価なオプションです。

第4に、MySQLのSQLレイヤーを再利用せず、自分で書き直すことを選択する理由

これは私たちと多くの友人の間で非常に異なる場所です。Auroraなどの多くの既存のソリューションは、MySQLのソースコードに直接基づいており、SQLレイヤーを保持しています。次の方法は、ストレージエンジンを置き換えて拡張を実現します。このソリューションには、いくつかの利点があります。まず、SQLレイヤーのコードが直接再利用されます。これにより、初期開発の負担が本当に軽減されます。2つ目は、ユーザー指向の側面が実際にMySQLアプリケーションと100％互換性があることです。

しかし、欠点も明らかです。MySQLは20年以上前の古いプロジェクトであり、設計の当初は分散シナリオは考慮されていませんでした。SQLレイヤー全体は、基礎となるものを置き換えるものの、より良いクエリプランを生成するためにデータ分散の特性をうまく利用できません。ストレージスキームにより、ストレージレイヤーはスケールに見えますが、計算レイヤーはそうではなく、いくつかのより複雑なクエリで見ることができます。さらに、大規模に拡張できる真に分散されたトランザクションが必要な場合、MySQLのネイティブトランザクションメカニズムに依存するだけでは不十分です。

最初はSQLレイヤー全体を自分で書き換えるのは難しいようですが、実際には、少なくともParserからはサポートされていない、ストアドプロシージャなど、現代のアプリケーションではほとんど使用されない構文が数多くあります。このレベルでは、ワークロードはそれほど大きくありません。同時に、オプティマイザ自身の記述の利点は、基礎となるストレージとよりうまく連携できることです。さらに、書き換えのためにいくつかのより現代的なプログラミング言語とツールを選択できるため、開発効率が高くなります。チョイス。

5. RocksDBとEtcd Raftを使用する理由

多くのエンジニアはホイール（おもちゃ）を作ることに熱心であり、私たちもそうですが、工業用グレードの製品を作ることはまったく異なります。現在の環境では、新しいデータベースを作成し、基礎となるストレージデータ構造を大まかに選択できます2つのタイプがあります：1. B +ツリー、2。LSMツリー。

ただし、B +ツリーの場合、すべての書き込みは少なくとも2回ディスクに書き込む必要があります：1.ログ内; 2.ダーティページを更新するとき、書き込みがバイトのみを変更する場合でも、このバイトもLSM-Treeにも書き込み拡大の問題がありますが、LSM-treeはすべてのランダム書き込みを順次書き込みに変換するという利点があります（Bに対応） +ダーティページを更新すると、ツリーがページ間で連続しない場合があります。一方、LSMTreeは圧縮に適しており、データストレージ形式はB + Treeよりもはるかにコンパクトです。Facebookは、MyRocksに関するいくつかの記事を公開して、InnoDBからMyRocks（RocksDBに基づくFacebookのMySQLストレージエンジン）への切り替えを比較しています。多くのスペースを節約できます。したがって、LSMツリーは私たちの選択です。

RocksDBを選択するための出発点は、RocksDBの背後に大規模でアクティブなコミュニティがあることです。同時に、RocksDBはFacebookに大規模なアプリケーションを備えており、RocksDBのインターフェースは十分に一般的であり、元のLevelDBと比較して、ターゲットにできる多くのパラメーターを公開しています。すばらしい。RocksDBの理解と使用が深まるにつれ、私たちはRocksDBコミュニティの最大のユーザーおよび貢献者の1人になりました。さらに、RocksDBのユーザーが増えるにつれて、このプロジェクトはどんどん良くなります。安定性が高いほど、学術界でLSM-Treeに基づく多くの改善がRocksDBに基づいていることがわかります。他のハードウェアメーカー、特にストレージ機器メーカーは、特定のストレージエンジン向けに最適化します。RocksDBも最初の選択肢の1つです。。

同様に、独自のストレージエンジンを開発することの利点と問題も同様に明白です。まず、開発から製品までのサイクルは非常に長くなり、産業レベルの安定性と品質を確保することは簡単なことではありません。多くの人的資源と材料リソースが必要です。利点は、独自のワークロードの設計と最適化をカスタマイズできることです。分散システムの自然な水平方向のスケーラビリティにより、単一のマシンの限られたパフォーマンスの向上は、クラスター全体のスループットと比較してあまり重要ではありません。高可用性とスケーラビリティに限られたエネルギーを投入するより経済的なオプションです。一方、LSM-TreeとしてのRocksDBは、工業用グレードのB + Tree（InnoDBを参照）よりも実装がはるかに簡単であり、マスタリングとメンテナンスの容易さの観点からも優れた選択肢です。もちろん、ストレージに対する理解が深まるにつれ、データベースに特化した多くの最適化をRocksDBに実装することが困難になっていることがわかりました。現時点では、CPUが画像処理を実行できるように、新しい特別なエンジンを再設計する必要がありますが、これはGPUよりもはるかに劣っており、GPUは機械学習専用のTPUほど優れていません。

Etcd Raftを選択する理由は同じです。なぜRaftなのかをお話します。TiDBプロジェクトが始まったとき、実際にはMultiPaxosとRaftの間で苦労していましたが、後でRaftを選んだと結論付けました。Raftのアルゴリズムの全体的な実装はより巧妙に設計されています。この論文からわかるように、RPCの構造もこの論文に記載されています。これは、産業での実装に非常に友好的なアルゴリズムであり、業界にはすでに多数のユーザーがいました。オープンソースの実装はEtcdです。Etcdを私たちにとってより魅力的にしているのは、テストに対する態度です。Etcdは、状態マシンの各インターフェイスを非常によく抽象化します。基本的にはオペレーティングシステムのAPIから分離できるため、単体テストの作成の難しさが大幅に軽減されます。エラーインジェクションなどの操作を実行するために多くのフックポイントが設計されていますが、設計者がテストを重視していることがわかります。

Raftを自分で再実装するのではなく、コミュニティを使用してお互いに成長することをお勧めします。現在、Etcdコミュニティへの積極的な貢献者でもあります。Learnerなどのいくつかの主要な新機能は、Etcdに設計されて提供されています。同時に、Etcdのバグは常に修正しています。

Etcdを完全に再利用しない主な理由は、ストレージエンジンの開発言語がRustを使用していることです。EtcdはGoで記述されています。必要な作業の1つは、RaftをRust言語で書き換えることです。これを実現するために、最初のステップは、Etcdの単体テストと統合テストを最初に移植することです（そうです、これもEtcdを選択する非常に重要な理由です。参照としてテストセットがあるため）、移行プロセスの正確さを損なわないようにします。一方、前述のように、Etcdとは異なり、TiKVのRaftはMulti-Raftモデルを使用しており、同じクラスター内に多数の独立したRaftグループが存在します。複数のRaftグループを分割、移動、およびマージするこのプロセスについては、私の記事で説明しました。

6、そのようなハードウェア構成要件がある理由

実際、本番環境のハードウェア要件は依然としてかなり高いです。ストレージノードの場合、SSDまたはNVMeまたはOptaneが必要です。さらに、CPUとメモリの使用要件も非常に高くなります。同時に、大規模なクラスターの場合、ネットワークにもいくつかの要件があります（詳細については、公式ドキュメントの推奨構成の関連する章を参照してください）。最も重要な理由の1つは、下部でRocksDBの実装を選択したことです。LSMツリーでは、書き込み増幅の自然な特性により、ディスクスループット要件これに対応して、特にRocksDBは並列圧縮などの機能も備えています。さらに、ほとんどの機械式ディスクマシンの構成では、（SSDと比較して）より大容量のディスクを配置する傾向がありますが、対応するメモリは一般に大きくありません（24T機械式ディスク+ 64Gメモリ、ディスクストレージなど）。データ量は多いように見えますが、多数のランダム読み取りがディスク読み取りに変換されます。現時点では、メカニカルディスクはIOボトルネックが発生しやすい傾向があります。一方、災害復旧やデータ移行にはあまり適していません。

加えて、様々な構成要素TiDB現在RPCフレームワークとしてgRPCを用い、gPRCに依存する HTTP2 単純なRPC実装の多くと比較して、基礎となるプロトコルとして、いくつかの追加のCPUのオーバーヘッドが存在することになります。TiKVのRocksDBの内部使用には、多くのプレフィックススキャンが伴います。これは、多くのバイナリ検索と文字列比較を意味します。これも、従来の多くのオフラインデータウェアハウスとは非常に異なるパターンです。これは、CPU集中型の操作になります。TiDBのSQLレイヤーの最後では、SQLは計算集約型のアプリケーションですが、言うまでもなく、メモリに対する一定の需要もあります。TiDBのSQLは完全なSQL実装であるため、表現力と多くのミドルウェアは同じ桁数ではありません。Hashjoinなどの一部の演算子は、Joinを実行するためにメモリ内に大きなメモリを開いて、クエリロジックを比較すると結合のサブテーブルが大きい場合（部分的にOLAPリアルタイム分析サービス）、メモリの需要も比較的高くなります。スタンドアロンデータベースと同じオプティマイザがありません。たとえば、Order byを格納できないため、ディスクでは、可能な限りメモリを使用することが私たちの哲学です。ハードウェアリソースが不足している場合は、実行が失敗して失敗することを拒否することにより、ユーザーにすぐに通知してください。ハーフデッドシステムはさらにひどい場合があるためです。

一方、パフォーマンス要件が比較的高いオンラインOLTPサービスを置き換えるために、多くのユーザーがTiDBを使用しています。最初は、インストールフェーズでユーザーのマシン構成を厳密にチェックしていませんでした。その結果、ハードウェアが明らかにビジネスのプレッシャーと一致しなかったときに多くのユーザーがオンラインになりました。最初は問題がないかもしれませんが、ピークのプレッシャーが発生し、障害が発生する可能性がありますが、TiDB TiKVとTiKVはレイヤーごとの内部電流制限を行いましたが、多くの場合それは役に立ちません。そこで、配置スクリプトの必須チェックとして構成チェックを使用することにしました。1つ目は、通信コストを大幅に削減し、2つ目は、ユーザーがオンラインに移行するときの心配をできる限り減らすことができるようにすることです。

7.ハッシュベースではなく範囲ベースのシャーディング戦略を使用する理由

ハッシュベースの問題は、順序付けされたスキャンAPIを実装するのがより難しいことです。私たちの目標は、標準のリレーショナルデータベースを実装することです。そのため、テーブルスキャン、インデックススキャンなど、多数の順次スキャン操作が行われます。ハッシュシャーディング戦略の問題の1つは、同じテーブルのデータが不連続になる可能性があることです。シーケンシャルスキャンの数行でも異なるマシンを横切る可能性があるため、この問題の選択肢はなく、レンジシャーディングのみです。ただし、範囲シャーディングは、小さなテーブルの頻繁な読み取りと書き込み、単一ポイントの順次書き込みなど、いくつかの問題を引き起こす可能性があります。まず、静的シャーディングが私たちのようなシステムには存在しないことを明らかにしましょう。たとえば、従来のミドルウェアソリューションと1対1で対応するデータシャードを物理マシンにマッピングする単純なシャーディング戦略では、次のような結果になります。

ノードを動的に追加した後、データの再配布を検討する必要があり、ここで動的なデータ移行を行う必要があります。
静的シャーディングは、ワークロードに基づくリアルタイムスケジューリングに適していません。たとえば、データにアクセスするためのホットスポットがある場合、システムはデータマイグレーションを迅速に実行して、異なる物理サービスプロバイダー間でホットスポットを分散できる必要があります。

レンジシャーディングに基づいて上記の問題に戻ると、シーケンシャルライトホットスポットの書き込みの問題は存在すると言いましたが、解決できないわけではありません。高圧下での順次書き込みのほとんどのシーンは、ログまたは類似のシーンです。このようなシーンの典型的な特徴は、読み取りと書き込みの比率が大きく異なり（読み取り<<書き込み）、更新とランダム削除がほとんどないことです。このシナリオでは、書き込み実際、この圧力は、TiDBの開発ロードマップにすでに含まれているパーティションテーブルによって解決できます。今年中にお会いしましょう。

小さなテーブルの頻繁な読み書きによって引き起こされるホットな問題もあります。その理由は、下部では、TiDBのデータスケジューリングの最小単位はリージョンです。これは、Key-Valueペア（デフォルトサイズは96Mです）であり、小さいテーブルの場合、合計サイズは96Mであると仮定していいえ、アクセスは特に頻繁です。現在のメカニズムでは、手動分割が必須ではない場合、スケジューリングシステムはデータがどこにスケジュールされていても、新しい場所にホットスポットが現れるため、この問題は本質的に解決できません。したがって、同様のアクセスパターンがある場合は、共通の小さなテーブルをRedisなどのメモリキャッシュに配置するか、ビジネスサービスのメモリ（直接）に直接配置することをお勧めします。

8.パフォーマンス（レイテンシ）が唯一の評価基準ではない理由

多くの友人が私に尋ねました、TiDBはRedisを置き換えることができますか？私はRedisとTiDBの愛情も理解していますが、残念なことに、TiDBはキャッシュサービスではなく、行全体で強力な一貫性のあるトランザクションをサポートし、不揮発性デバイス上の永続的なストレージをサポートしています。の。

簡単に言えば、ディスクへの書き込み（WAL、永続性）のIOオーバーヘッド、マルチコピーの高可用性、保証された分散トランザクションは、データセンター間の同期は言うまでもなく、必然的に待ち時間を犠牲にします。この時点で、必要に応じて、非常に低いレイテンシ応答速度（サブミリ秒レベル）は、ビジネス側でキャッシュする必要があります。TiDBの位置づけは、ビジネスにスケーラブルなSource of Truthを提供することです。ビジネスレイヤーのキャッシュに障害が発生しても、強力で一貫性のあるデータを提供できる場所があり、ビジネスは容量について心配する必要がありません。**一方、分散システムを測定するためのより意味のある指標はスループットです。同時実行性を向上させるために、この点を多くの記事で説明しました。システムスループットがクラスターマシンの数と遅延に比例して増加する場合安定していることだけが理にかなっており、このようにして無限の改善の余地があります。**実際の環境では、単一のTiDBクラスターの一部のユーザーが数百万のQPSを使用していますが、これは単一のマシンアーキテクチャで達成することはほとんど不可能です。さらに、近年のハードウェアの進歩は非常に速く、特にNVMe SSDの人気などのIO関連の革新、および使用したばかりの永続メモリなどの新しいストレージメディアは非常に高速です。多くの場合、ソフトウェアレベルで頭を悩ませ、コードの優雅さを犠牲にしてパフォーマンスを少し改善しますが、ディスクを変更することで、大幅に改善される可能性があります。

私たちの会社には格言があります：速くする前にそれを正しくしなさい。正確性と信頼性の位置はパフォーマンスの前ですが、結局のところ、不安定なシステムでのパフォーマンスについて話すことは意味がありません。

9、弾性スケーラビリティが非常に重要な理由

ビジネスの初期には、データの量が多くなく、ビジネスフローとプレッシャーが大きくない場合、基本的にどのデータベースでも取得できますが、特に一部のToCアプリケーションでは、ビジネスの爆発的な成長が期待できない場合があります。初期のTwitterユーザーは時々大きなクジラを嫌っていたはずです（サービスは利用できません）。最近では、過去2年間に人気の脚注アプリがありました。ビジネスとデータの量は短時間で爆発し、データベースはほぼこれらすべてのケースでコアボトルネックです。多くのインターネットDBAや若いアーキテクトは、ビジネスコードのリファクタリングの隠れたコストを過小評価します。ビジネスの早い段階で機能と要件を迅速に取得することが最も重要です。ビジネスの急速な成長を想像してください。毎日データベースの過負荷のためにサーバーが停止すると、DBAは方法がないと通知し、ビジネスを書き直してコンポーネントデータベーステーブルのフォームを書き直し、コードのあらゆる場所にシャーディングキーを追加します。すべての非シャーディングの主要な多次元リレーショナルクエリとシャード全体の関連する強整合トランザクションを犠牲にしてから、データの複数のコピーをコピーします...現時点では、リアルタイムはお金と同じであり、会社が生きているときにビジネスコードと機能コードを記述することはありません。それは、インフラストラクチャの制限が再構築を余儀なくされるためであり、実際には非常に悪いです。この時点で、ビジネスコードを変更せずにデータベースのスループットを直線的に拡張できるソリューションがある場合（脳とマシンは実際には最も安価です）、最も重要なことはビジネスの進化のために戦うことです時間、私はこの選択が実際にはまったく難しくないと思います。

実際、TiDBを行う本来の目的はまさにこれです。過去に類似した血や涙が多すぎて、これは本当に耐えられないことです。サブライブラリやテーブルにさまざまなミドルウェアを使用することは非常に簡単ですが、私たちが望むのは本当に解決することです多くの開発者とDBAが急いでいます。

最近の2人のユーザーの例には非常に感銘を受けました。1つはMobikeで、もう1つはターンアラウンドです。前者はTiDBの初期のユーザーで、データが急速に増大したときに彼ら自身がそれを使用し始めました。 TiDBは、迅速な開発プロセスにおいて、データベースの問題が原因でチェーンから脱落することはありませんでした。後者は、典型的な急速に発展しているインターネット企業であるオールインTiDB企業です。、そのため、ビジネスは、シャーディングキーの無限の選択、読み取りと書き込みの分離など、およびデータベースの競合に陥るのではなく、ビジネスコードを書くことに対してよりオープンになることができます。

ビジネス開発に、より柔軟で便利で低コストのインテリジェントな基本ストレージサービスを提供することが、TiDBの出発点であり足場です。分散型/高可用性/便利で柔軟なプログラミングインターフェイス/インテリジェントな心配、これらの一般的な方向性も将来に沿ったものです主流の技術開発動向。CEO、CTO、アーキテクトなどのマネージャーにとって、差し迫った問題を解決しながら、主要な技術的指示に従い、将来の変化するビジネスを埋めないで、会社は可能な限り迅速に開発します。これがコアです。考える質問。

10.実際の状況に応じて業界のユースケースを参照する方法

TiDBは汎用データベースであり、汎用データベースよりも用途が広くなることを望んでいます。TiDBは、長い間OLTPとOLAPの境界をマージすることを試みてきたデータベース製品です。HTAPの概念を実験室と紙から実際の製品に初めて導入しました一つ。この種の汎用基本ソフトウェアが直面する問題の1つは、垂直産業のユーザーが初期段階でTiDBを適切に使用するようにガイドすることが難しいことです。結局のところ、各フィールドには独自の使用シナリオと特性があります。、したがって、インターネット分野のアーキテクチャとシーンに精通しているのは当然ですが、たとえば、金融、ゲーム、eコマース、従来の製造業では、私たちは実際には専門家ではありませんが、今では多くの業界の専門家や開発者がいます。 TiDBはそれぞれの分野でよく使用されています。