新しいアイデアについて話す前に、これまでデータベーステクノロジーに注意を払っていなかった友人のために簡単な歴史的レビューを行い、次にクラウドネイティブデータベース設計における将来のデータベース分野、新しいトレンド、最先端の考え方について話します。まず、いくつかの主流のデータベース設計パターンを見てみましょう。
共通分散データベーススクール分散データベース
の開発過程は、年齢別に分類しており、これまで4世代に分かれています。第1世代は、データシャーディングと水平展開を行うための単純なサブデータベースサブテーブルまたはミドルウェアに基づいています。第2世代のシステムは、Cassandra、HBase、またはMongoDBで表されるNoSQLデータベースであり、インターネット企業で一般的に使用されており、水平方向のスケーラビリティが優れています。
個人的には、第3世代のシステムは、GoogleSpannerやAWSAuroraに代表される新世代のクラウドデータベースだと思います。SQLとNoSQLの拡張機能が統合され、SQLインターフェースがビジネスレイヤーに公開されているのが特徴です。使用済み。水平方向の拡張。
第4世代のシステムは、現在のTiDB設計を例にとり、ビジネス負荷が混在する時代に入りました。システムは、トランザクションを実行するだけでなく、高同時性のトランザクションを処理するという特徴を備えており、一部のデータウェアハウスを統合することもできます。または分析データベース。これはHTAPと呼ばれ、統合データベース製品です。
将来はどのようなものか、以下の共有で将来の見通しをいくつか紹介します。1970年代の開発から現在までのタイムライン全体の観点から、データベースは古代の産業と見なされています。各段階の具体的な開発については詳しく説明しません。
データベースミドルウェア
データベースミドルウェアの場合、第1世代システムはミドルウェアシステムです。基本的に2つの主流モデルがあります。1つは、ビジネスのデータベースユーザーなど、ビジネスレイヤーのサブデータベースとサブテーブルを手動で作成することです。 ;北京のデータは1つのデータベースに保存され、上海のデータは別のデータベースに保存されるか、別のテーブルに書き込まれます。これはビジネス層の最も単純な手動サブデータベースサブテーブルです。あなたはそれを操作したと思います。 。データベースの友達はとてもよく知っています。
2つ目は、データベースミドルウェアを介してシャーディングルールを指定することです。たとえば、ユーザーの都市、ユーザーのID、および時間はシャーディングのルールとして使用され、ミドルウェアはビジネスレイヤーなしで自動的に割り当てるために使用されます。
このアプローチの利点は単純さです。ビジネスが書き込みや読み取りなどの特に単純なケースの場合、基本的には1つのシャードで完了するように劣化する可能性があります。アプリケーション層が完全に適応された後でも、遅延は比較的小さいです。全体として、ワークロードの場合ランダムです。ビジネスTPSは線形拡張も実現できます。
しかし、欠点も明らかです。一部のより複雑なサービス、特にクエリや書き込みなどの一部のクロスシャード操作では、クロスシャード間で強力なデータ整合性を維持するのがより面倒です。もう1つの明らかな欠点は、大規模なクラスターの操作と保守が、特にテーブル構造の変更などの同様の操作を行うのがより難しいことです。シャードが100個あるとしたら、1列を追加したり、1列を削除したりすることは、100台のマシンで操作を実行することと同じであり、実際には非常に面倒です。
NoSQL-SQLだけでなく
2010年頃、多くのインターネット企業がこの大きな問題点を発見しました。ビジネスについて慎重に検討した結果、ビジネスは非常にシンプルで、SQLの特に複雑な機能を必要としないことがわかったため、ジャンルを開発しました。NoSQLデータベース。NoSQLの特徴は、高度なSQL機能を放棄することですが、利益と損失があります。または、放棄するといつでも何かを得ることができます。NoSQLは、ビジネスの透過的で強力な水平拡張機能と引き換えに、逆です。やってくるということは、あなたのビジネスがもともとSQLに基づいて書かれている場合、比較的大きな変換コストがかかる可能性があることを意味します。代表的なシステムには、MongoDB、Cassandra、HBaseなどがあります。
最も有名なシステムはMongoDBです。MongoDBも配布されていますが、それでもサブデータベースとサブテーブルのスキームに似ています。シャードのキーを選択する必要があります。その利点は誰もが知っている、つまりそこにあります。はテーブル構造情報ではありません。何を書くか、データを文書化する方がわかりやすいですが、欠点も明らかです。シャーディングキーが選択されているため、固定ルールに従ってシャーディングされる可能性があるため、そこにあると面倒になります。いくつかのクロスシャード集約要件があります。2つ目は、クロスシャードACIDトランザクションの適切なサポートがないことです。
HBaseは、Hadoopエコシステムでよく知られている分散型NoSQLデータベースであり、HDFS上に構築されたNoSQLデータベースです。Cassandraは分散KVデータベースであり、KV操作に複数の整合性モデルを提供することを特徴としています。欠点は、操作と保守の複雑さ、元のビジネス変革のためのKVインターフェイスの要件など、多くのNoSQLの問題と同じです。
シャーディングまたはサブデータベースサブテーブル、あるいはNoSQLについて言及した第3世代の分散データベースNewSQLは、どちらも煩わしいビジネス上の問題に直面しています。ビジネスがSQLに大きく依存している場合、これら2つのソリューションは大きく異なります。そのため、より高度なテクノロジーを備えた一部の企業は、SQLの表現力、トランザクションの一貫性など、従来のデータベースの利点だけでなく、スケーラビリティなどのNoSQL時代の優れた機能を組み合わせて、新しいデータベースを開発できるかどうかを検討しています。シンプルでスケーラブルなシステムですが、スタンドアロンデータベースと同じくらい便利です。この考えの下で、2つのジャンルが生まれました。1つはスパナ、もう1つはオーロラであり、どちらもこの問題に直面したときにインターネットのトップ企業が選択したものです。
シェアードナッシング流派
シェアードナッシングのジャンルはGoogleSpannerによって表されます。利点は、ほぼ無制限の水平拡張を実現できることです。システム全体にエンドポイントがありません。1T、10 T、100 Tのいずれであっても、ビジネス層は基本的にスケーラビリティについて心配します。2番目の利点は、彼の設計目標が強力なSQLサポートを提供することであるということです。断片化ルールや断片化戦略を指定する必要はありません。システムは自動的に拡張を支援します。3つ目は、財務レベルのサービスをサポートするために使用できるスタンドアロンデータベースのような強力で一貫性のあるトランザクションをサポートすることです。
代表的な製品はSpannerとTiDBです。このタイプのシステムにもいくつかの欠点があります。本質的に、純粋な分散データベースには、単一のマシンの動作とまったく同じではない多くの動作があります。たとえば、単一マシンのデータベースがトランザクショントランザクションを実行している場合、単一のマシンで完了することができますが、分散データベースでは、同じセマンティクスを実装する場合、トランザクションが操作する必要のある行異なるマシンに分散される可能性があり、複数のネットワーク通信と相互作用を伴う必要があり、応答速度とパフォーマンスは単一のマシンでの1つの操作ほど良くないため、スタンドアロンデータベースとの互換性と動作にはいくつかの違いがあります。それでも、多くの企業にとって、分散データベースには、サブデータベースやテーブルと比較して、依然として多くの利点があります。たとえば、使いやすさの点で、サブデータベースやテーブルよりもはるかに邪魔になりません。
SharedEverything流派
2番目のジャンルはSharedEverythingジャンルで、AWSAuroraとAlibabaCloudのPolarDBを表します。多くのデータベースはそれ自体をクラウドネイティブデータベースとして定義していますが、ここでのクラウドネイティブは、これらのソリューションが通常はパブリッククラウドであるというよりも多いと思います。テクノロジー自体はクラウドネイティブであるかどうかにかかわらず、サービスプロバイダーによって提供される統一された標準はありません。純粋に技術的な観点から、コアポイントは、このタイプのシステムのコンピューティングとストレージが完全に分離されていることです。コンピューティングノードとストレージノードは異なるマシンで実行されます。ストレージは、クラウドディスクでMySQLを実行するのと同じです。I個人的には、AuroraやPolarDBのようなこのアーキテクチャは純粋に分散されたアーキテクチャではないと考えています。
元のMySQLマスタースレーブレプリケーションはBinlogを使用します。クラウド上のShareEverything Databaseの代表として、Auroraの設計アイデアは、IOリンク全体ではなく、やり直しログの形式でのみIOフロー全体をレプリケートすることです。 Binlogを別のマシンに送信してから、Binlogを適用すると、AuroraのIOリンクが大幅に削減されます。これは大きな革新です。
ログレプリケーションユニットが小さくなります。つまり、Binlogではなく物理ログのみを送信し、ステートメントを直接送信しません。物理ログを直接送信すると、IOパスとネットワークパケットが小さくなるため、スループット全体が小さくなります。データベースシステムの効率は、従来のMySQLデプロイメントスキームよりもはるかに優れています。
Auroraの利点は、MySQLと100％互換性があり、ビジネスとの互換性が高いことです。基本的に、ビジネスは変更せずに使用できます。一部のインターネットシナリオでは、整合性要件が高くない場合、データベースの読み取りを水平方向に拡張することもできます。 、AuroraまたはPolarDBのどちらであっても、読み取りパフォーマンスには上限があります。
Auroraの欠点もわかります。本質的には、これはスタンドアロンデータベースです。すべてのデータが一緒に保存されるため、Auroraのコンピューティングレイヤーは実際にはMySQLインスタンスです。基になるデータの分散は考慮されません。大容量の書き込みまたは大容量のクロスシャードクエリのニーズがあります。大容量のデータをサポートする場合でも、サブデータベースとテーブルが必要になるため、Auroraはより優れたクラウドスタンドアロンデータベースです。
第4世代システム：分散型HTAPデータベース。第
4世代システムは新しい形式のHTAPデータベースです。英語名はHybrid Transactional and Analytical Processingです。名前からもわかりやすく、トランザクションを実行して実際に実行できます。同じシステムでの時間。分析。HTAPデータベースの利点は、NoSQLのように無制限の水平スケーラビリティを持ち、NewSQLのようにSQLクエリとトランザクションサポートを実行できることです。さらに重要なことに、混合ビジネスなどの複雑なシナリオでは、OLAPはOLTPビジネスに影響を与えません。 、同じシステム内でデータを移動する手間を省きます。現在、業界ではTiDB4.0とTiFlashアーキテクチャのみが上記の要件を満たすことができると思います。
分散HTAPデータベース：TiDB（TiFlashを使用）
TiDBが互いに影響を与えることなくOLAPとOLTPを完全に分離できるのはなぜですか？TiDBはコンピューティングとストレージ用の別個のアーキテクチャであるため、基盤となるストレージはマルチコピーメカニズムであり、その一部は列ベースのストレージに変換できます。OLAP要求は、列コピー、つまりTiFlashのコピーに直接ヒットして、高性能の列分析サービスを提供できるため、同じデータをリアルタイムトランザクションとリアルタイム分析に使用できます。これがTiDBのアーキテクチャです。レベルでの素晴らしい革新とブレークスルー。
次の図は、MemSQLと比較したTiDBのテスト結果です。ワークロードはユーザーシナリオに従って構築されます。横軸は同時実行数、縦軸はOLTPのパフォーマンスです。青、黄、および緑は同時OLAPの数です。この実験の目的は、OLTPとOLAPの両方をシステムで実行し、OLTPとOLAPの同時実行圧力を継続的に増加させて、これら2つのワークロードが相互に影響するかどうかを確認することです。TiDB側では、OLTPとOLAPの同時実行圧力を高めながら、これら2つのワークロードのパフォーマンスに大きな変化はなく、ほぼ同じであることがわかります。ただし、同じ実験がMemSQLで行われました。MemSQLのパフォーマンスが大幅に低下していることがわかります。同時OLAPの数が増えると、OLTPのパフォーマンスが大幅に低下します。
以下は、ユーザーの実際のビジネスシナリオにおけるTiDBの例です。OLAPビジネスクエリを実行する場合でも、OLTPビジネスはスムーズな書き込み操作を実現でき、遅延は低レベルに維持されています。
未来の
スノーフレークはどこにありますか
Snowflakeは、クラウド上に構築された100％データウェアハウスシステムです。基盤となるストレージはS3に依存します。基本的にすべてのパブリッククラウドはS3のようなオブジェクトストレージサービスを提供します。Snowflakeは純粋なコンピューティングおよびストレージ分離アーキテクチャでもあります。そこで定義されているコンピューティングノードは仮想ウェアハウスと呼ばれ、EC2ユニットと見なすことができます。ローカルキャッシュにはログディスクがあります。スノーフレークのメインデータはS3に保存されます。ローカルコンピューティングノードはパブリッククラウドの仮想マシン上にあります。
これは、SnowflakeがS3に保存するデータ形式の特徴です。各S3オブジェクトは10メガバイトのファイルであり、追加されるだけです。各ファイルにはソース情報が含まれ、列ストレージを介してディスクに保存されます。
Snowflakeの最も重要な機能は、計算のために同じデータに異なるコンピューティングリソースを割り当てることができることです。たとえば、クエリに必要なマシンは2台だけで、別のクエリにはさらに多くのコンピューティングリソースが必要ですが、それは問題ではありません。実際、これらのデータはすべてS3にあります。簡単に言えば、2台のマシンが同じディスクをマウントして、異なるワークロードを処理できます。これは、コンピューティングとストレージを分離する重要な例です。
Google BigQuery
2番目のシステムはBigQueryです。BigQueryはGoogleCloudで提供されるビッグデータ分析サービスです。そのアーキテクチャはSnowflakeに似ています。BigQueryデータはGoogleの内部分散ファイルシステムColossusに保存されています。Jupiterは内部の高性能ネットワークであり、上記はGoogleのコンピューティングノードです。
BigQueryの処理パフォーマンスは優れています。データセンターの双方向帯域幅は1秒あたり1PBに達する可能性があります。2000の専用コンピューティングノードユニットを使用する場合、月額約40,000ドルの費用がかかります。BigQueryは従量課金制のモデルです。1つのクエリで2つのスロットを使用でき、これら2つのスロットの料金が課金されます。BigQueryのストレージコストは比較的低く、1TBのストレージは月額約$ 20です。
RockSet
3番目のシステムはRockSetです。RocksDBがよく知られているスタンドアロンのKVデータベースであることは誰もが知っています。そのストレージエンジンのデータ構造はLSM-Treeと呼ばれます。LSM-Treeのコアアイデアは階層設計であり、より低温です。データは低くなります。RockSetは後者のレイヤーをS3ストレージの上に配置します。上位レイヤーは実際にはローカルディスクまたはローカルメモリをエンジンとして使用します。これは当然のことながらレイヤー構造であり、アプリケーションはそれがクラウドディスクであるかローカルディスクであるかを認識しません。優れたローカルキャッシュでは、以下のクラウドストレージの存在を認識できません。
これら3つのシステムを見てみましたが、いくつかの特徴があると思います。1つはすべて自然に分散されていること、2つ目は標準のクラウドサービス、特にS3とEBSに基づいて構築されていること、3つ目は従量課金制で十分に活用されていることです。アーキテクチャにおけるクラウドの弾力性。これら3つのポイントの中で最も重要なのはストレージだと思います。ストレージシステムは、クラウド上のデータベースの設計方向を決定します。
S3が重要なのはなぜですか？
ストレージでは、S3の方が重要かもしれないと思います。実際、EBSについても研究しました。TiDBの最初の段階は実際にはEBSブロックストレージとの統合ですが、長期的な観点からは、S3側の方が興味深い方向だと思います。
まず、最初のポイントS3は非常に費用対効果が高く、価格はEBSよりもはるかに低くなっています。2番目のS3は99を高い信頼性で提供します。3番目はスループットの線形拡張です。4番目は自然なクロスクラウドです。 S3APIを使用したクラウドオブジェクトストレージサービス。ただし、S3の問題は、ランダム書き込みレイテンシーが非常に高いことですが、スループットパフォーマンスは良好であるため、スループットパフォーマンスが高いというこの機能を利用して、レイテンシーが高くなるリスクを回避する必要があります。これはS3ベンチマークのテストです。モデルの改善に伴い、スループット容量も継続的に改善されていることがわかります。
レイテンシーの問題を解決する方法は？
S3のレイテンシーの問題を解決したい場合は、SSDまたはローカルディスクをRockSetのようなキャッシュとして使用したり、kinesisを介してログを書き込んだりして、全体的な書き込みレイテンシーを減らすなどのアイデアがあります。データのコピーもあるか、並行処理などを行う必要があります。実際、ゼロコピーのデータの複製を行うことができます。これは、待ち時間を短縮する方法でもあります。
上記の例には、データウェアハウスに共通する点がいくつかありますが、なぜそれらがすべてデータウェアハウスであるのかをご存知でしょうか。データウェアハウスのスループットに対する要件は実際には高くなっています。待ち時間についてはそれほど心配していません。クエリを5秒間実行して結果を生成する場合があります。特に、一部のポイントルックアップシナリオでは、5ミリ秒以内に結果を提供する必要はありません。データベースはクライアントから1つのrpcしか必要としない場合がありますが、コンピューティングとストレージが分離されているアーキテクチャの場合、ネットワークは途中で2回実行する必要があります。これはコアの問題です。
とにかく、コンピューティングとストレージは分離されていると言うかもしれません。奇跡を達成するために一生懸命努力するなら、コンピューティングノードを追加することができます。しかし、新しいアイデアはそれほど極端である必要はないと思います。Auroraは独立したコンピューティングおよびストレージアーキテクチャですが、スタンドアロンデータベースです。Spannerは純粋に分散されたデータベースです。純粋なSharedNothingアーキテクチャは利用していません。クラウドインフラストラクチャによって提供されるいくつかの利点。
たとえば、将来的には、データベースを次のように設計できます。実際、各EC2がローカルディスクをもたらすため、コンピューティングレイヤーには少し状態があります。現在、主流のEC2はSSDであり、ホットデータを実行できます。このレイヤーで共有なし、このレイヤーで高可用性が実行され、このレイヤーでランダムな読み取りと書き込みが実行されます。ホットデータがキャッシュミスされると、S3に分類されます。データはS3の次の数レイヤーにのみ保存できます。このアプローチでは問題が発生する可能性があります。ローカルキャッシュに侵入すると、レイテンシに多少のジッターが発生します。
このアーキテクチャ設計の利点：第1に、リアルタイムのビジネスデータコンピューティングとの親和性があり、ローカルディスクに大量のデータが存在します。この時点で、多くの従来のデータベースパフォーマンス最適化手法を使用できます。第2に、データの移行は実際には非常に簡単になります。実際、基盤となるストレージはすべてS3で共有されます。たとえば、マシンAからマシンBへのデータ移行は、データが読み取られる限り、実際に移行する必要はありません。マシンB。
このアーキテクチャの欠点は次のとおりです。まず、キャッシュが浸透した後、レイテンシが高くなります。次に、コンピューティングノードの状態が発生します。コンピューティングノードがダウンした場合、フェイルオーバーはログ再生の問題に対処する必要があります。実装の複雑さを少し増やします。
まだ研究に値するトピックがたくさんあります。
上記のアーキテクチャは単なる仮説です。TiDBはまだそのようなアーキテクチャではありませんが、将来この方向でいくつかの試みや研究が行われる可能性があります。この分野には実際に多くの未解決の質問があります。まだ答えはありません。、私たちを含むクラウドベンダーを含め、学界には答えがありません。
ここで、いくつかの研究トピックがあります。まず、ローカルディスクを使用する場合、キャッシュするデータの量、LRU戦略はどのように見えるか、パフォーマンスとは何の関係があるのか、ワークロードとは何の関係があるのか。第2に、ネットワークの場合、S3のネットワークスループットが非常に良好であることがわかりました。特に、より複雑なクエリの場合、どのようなパフォーマンスをどのスループットと一致させる必要があるか、コンピューティングノードの数を増やす必要があります。計算の複雑さと計算ノードおよびモデルの関係はありますか？これらの問題は実際にはもっと複雑な問題であり、特に数学を使って表現する方法は、これらのことを自動的に行う必要があるためです。
これらの問題が解決されたとしても、それはクラウドデータベースの時代の始まりに過ぎないと思います。将来的には、AI駆動型を含むサーバーレスで、より優れたデータベースを設計する方法について、これが私たちの取り組みの方向性です。結局、屈原の見積もりはまだまだ先のことです。まだやることがたくさんあります。ありがとうございます。
