benchANT compares MongoDB and ScyllaDB architectures, with a focus on what the differences mean for performance and scalability NoSQL データベースを選択する場合、選択肢は圧倒的です。最も人気のある選択肢の 1 つは、その使いやすさで知られている MongoDB です。しかし、高パフォーマンス志向の ScyllaDB は、挑戦者の一つです。 この報告書は、両データベースの技術的な視点をより詳しく見ており、独立した技術的な角度からそれらのアーキテクチャを比較しています。 ベンチャント MongoDB と ScyllaDB は両方とも、高可用性、パフォーマンス、スケーラブルなアーキテクチャを約束しますが、これらの目標を達成する方法は、あなたが最初に考えるよりもはるかに異なります。例えば、経験報告書は、分散アーキテクチャのおかげで ScyllaDB が AWS EC2 スポットインスタンスでどのように簡単に操作できるかを示していますが、MongoDB の分散アーキテクチャはこれを非常に困難な作業にします。 これらの違いを強調するために、内部ストレージアーキテクチャと高可用性と水平スケーラビリティを可能にする分散アーキテクチャの詳細な議論を提供します。 私たちはまた、これらの違いの影響を定量化するベンチマークをリリースしました。 Note: DynamoDB vs MongoDB Benchmark 概要 比較レポートをダウンロード Read the DynamoDB vs MongoDB Benchmark Summary DynamoDB vs MongoDB Benchmark 概要 Download this Comparison Report 比較レポートをダウンロード MongoDB vs ScyllaDBのストレージアーキテクチャに関するパフォーマンスの視点 両方のデータベースは C++ で実装され、XFS ファイルシステムの使用を推奨しています。 , Commit Log in ScyllaDB terminology and Oplog in MongoDB terminology. With write-ahead-logging, all operations are written to a log table before the operation is executed. The write-ahead-log serves as a source to replicate the data to other nodes, and it is used to restore data in case of failures because it is possible to 'replay' the operations to restore the data. ScyllaDB terminology and Oplog in MongoDB terminology. With write-ahead-logging, all operations are written to a log table before the operation is executed. The write-ahead-log serves as a source to replicate the data to other nodes, and it is used to restore data in case of failures because it is possible to 'replay' the operations to restore the data. 原題: write-ahead-logging MongoDB はデフォルトのストレージ エンジンとして、データのストレージと取得のために B+-Tree インデックス (Wired Tiger) を使用します。 B+-Tree インデックスはバランスのとれたツリーデータ構造で、データを分類した順序でストレージし、範囲ベースのクエリを実行しやすくします。 MongoDB は、複合インデックス、テキストインデックス、および地理空間インデックスを含むコレクション上の複数のインデックスをサポートしています。 ScyllaDB は、関連するメモリ(RAM)および永続的なストレージ(NVMe SSD など)とともに、特定の CPU にノード内の合計データの一部を割り当てることによってデータをシェアに分割します。 ScyllaDB の内部ストレージエンジンは、ディスクの永続的なコミットログと、時間の経過とともにディスクにスプレッシュされるメモリベースのメモリログを適用することによって、 write-ahead-logging コンセプトに従います。 ScyllaDB は、ノードごとにローカルおよびグローバルごとにクラスターごとに、次元、次元および複合的なインデックスをサポートします。 主なインデックスはハッシュリングで構成され、ハッシュキーと これらの異なるストレージアーキテクチャは、ワークロードを処理するために利用可能なハードウェアの異なる使用につながります。MongoDBは、利用可能なCPUコアに内部トレードを接続しないが、コアに分散トレードを接続しないアプローチを適用します。 CPUアーキテクチャでは、これはパフォーマンスの低下を引き起こす可能性があります、特に大規模なサーバーでは、スチールDBは異なるメモリノードを持つ異なるソケット上のコアにダイナミックに割り当てられます。 これにより、責任あるトレードを特定のコアにペンすることができ、異なるコアとメモリスペース間の切り替えを避けることができます。したがって、シェードキーは、シェード全体にデータの均等な分布を確保し、ホットシェードを防ぐために慎重に選択する必要があります。 それは、遅延に敏感で非敏感なクエリのための組み込まれた優先クラス、および、1つのノードの断片間で調整されたI/Oスケジュールを提供し、ディスクパフォーマンスを最大化します。最後に、ScyllaDBのインストールスクリプトには、利用可能なリソースに基づいて最適なデータベース構成を適用することによってパフォーマンスの自動調整ステップが付属します。 NUMAベース Shard Per Core アプローチ I/O スケジュール ScyllaDB により、ユーザーはデータが DB キャッシュに留まるべきか、またはめったにアクセスできないパーティションでそれを回避するかを制御できます ScyllaDB により、クライアントは、データを所有するノードおよび CPU コア (shard) にアクセスできます。これにより、遅延が低くなり、パフォーマンスが一貫し、負荷バランスが完璧になります。 ScyllaDB はまた、特定の重要なワークロードの遅延を保証するために、ユーザーに異なる SLA を提供する「ワークロード優先化」も提供します。 MongoDB 分散アーキテクチャ - 高可用性とスケーラビリティのための2つのオペレーティングモード MongoDB データベースアーキテクチャは、次のセクションで説明される 2 つのクラスターモードを提供します: レプリカセットクラスターは高可用性をターゲットにし、分割クラスターは水平スケーラビリティと高可用性をターゲットにします。 Replica Set Cluster: High Availability with Limited Scalability(レプリカセットクラスタ) MongoDB アーキテクチャは、レプリカセットのコンセプトによって高可用性を可能にします。 MongoDB レプリカセットは、Primary-Secondary ノードのコンセプトに従い、Primary のみが WRITE 操作を処理します。Secondaries はデータのコピーを保持し、READ 操作のみを処理することを可能にします。共通のレプリカセットの展開は2つのSecondariesで構成されますが、追加のSecondaries は可用性を増やすか、読み重いワークロードをスケールするために追加できます。MongoDB は、1 つのレプリカセット内の最大 50 のSecondaries をサポートします。Secondaries は、元の Primary で失敗した場合、primary として選択されます。 地理的配布に関しては、MongoDB は、データセンターエラーの場合に高可用性を確保するために、レプリカセットの地理的配布をサポートします。この文脈では、次元インスタンスは、次の図に示すように、複数のデータセンターに分散することができます。 Sharded Cluster: Horizontal Scalability and High-Availability with Operational Complexity シェアードクラスター MongoDB は、複数のメインインインスタンスでデータをシェアディングすることで、水平スケーリングをサポートし、書き込みの激しいワークロードと増加するデータサイズに対処します。 シェアディングクラスターでは、1 つのメインおよび複数のサバイバルからなるそれぞれのレプリカセットがシェアディングを表します。 MongoDB 4.4 サバイバルは、ヘッジディングリリースオプションを使用してリクエストの処理にも使用できます。 Sharding を有効にするには、追加の MongoDB ノードタイプが必要です。 mongos インスタンスはクエリ ルーターとして機能し、クライアント アプリケーションとシェアド クラスターの間のインターフェイスを提供する。その結果、クライアントはクエリ ルーターを介して常にクエリ ルーターを介して、クライアントと直接通信することはありません。クエリ ルーターは、専用リソースまたはクライアント アプリケーションと共に操作できる状態のない軽量なコンポーネントです。 クエリー ルーター (Mongos) クエリ ルーターはクライアント ドライバーの直接のインターフェイスであるため、クラスターのアクセシビリティを確保するために複数のクエリ ルーターを展開することをお勧めします。クエリ ルーターの数に制限はありませんが、彼らがコンフィギング サーバーと頻繁に通信しているため、複数のクエリ ルーターがコンフィギング サーバーを過剰に負荷させることができることに留意する必要があります。 コンフィギング サーバーは、すべてのデータとコンポーネントの状態と組織を含むシェアド クラスターのメタデータを格納します。 メタデータには、各シェアードのブロックのリストと、ブロックを定義する範囲が含まれています。 MongoDB でのデータシェアリングは、コレクションレベルで行われ、シェアリングはシェアリングキーに基づいて行うことができます。MongoDB では、シェアリングキーを使用して、どのドキュメントがどのシェアリングに属するかを決定します。 一般的なシェアリングキーの選択は、 _id フィールドと、タイムスタンプやユーザ ID などの高いカーディナリティを持つフィールドを含みます。 シェードキー値に応じて、シェード間のドキュメントを分割します。これにより、シェードキー値を持つドキュメントは互いに近づいており、範囲ベースのクエリでは、例えばタイムシリーズデータでうまく機能します。 シェードシェードは、シェード間の文字の均一な分布を保証し、書き込みワークロードを好みます。 ゾーンシェードは、開発者がアプリケーションサーバーに地理的に最も近いシェードに最も関連するデータを確保するために、カスタムシェードのルールを定義することができます。 また、分断されたクラスターは、次の図に示すように、データセンターの故障を克服するために、地理的に分散された設定で展開することができます。 The ScyllaDB Architecture - Multi-Primary for High-Availability and Horizontal Scalability (ScyllaDBアーキテクチャー - 高可用性と水平スケーラビリティのためのマルチプレミアリー) MongoDBとは異なり、ScyllaDBは1つの主要ノードと複数の次元ノードを持つ古典的なRDBMSアーキテクチャに従わないが、すべてのデータが複数のノードに分散して複製され、クラスターを形成する分散された構造を使用する。 クラスターは、データが配布される仮想リングアーキテクチャに組織された相互接続されたノードの集合です。 リングは、物理的なノードに割り当てられたトークンの範囲を表すvNodesに分割され、キースペースの複製因子に基づいて物理的なノードに複製されます。 すべてのノードは、複数の原理的な意味で平等とみなされます。 定義されたリーダーがなければ、クラスターには単一の失敗点がありません。 ノードは、個々のオンプレミスサーバー、または、より大きな物理的なサーバー上のハードウェアのサブセットで構成された仮想サーバー(公共のクラウドインスタンス)かもしれません。 各ノードでは、データはさらにシェアードに分割されます。 シェ すべてのノードが相互にコミュニケーションをとるのは、 このプロトコルは、どのパーティションでどのデータが書かれているかを決定し、インデックスを使用して右パーティションのデータレコードを検索します。 ゴシッププロトコル ScyllaDB のアーキテクチャは、スケーリングに関しては、複数のサーバーおよび地域を介して簡単に横断的にシェーディングを行うように設計されています。 ScyllaDB のシェーディングはテーブルレベルで行われ、テーブルはパーティションキーに基づいてシェーディングすることができます。 パーティションキーは単一の列または複数の列の複合体です。 ScyllaDB はまた、リージョンベースのシェーディングをサポートし、リージョンがパーティションキーの値範囲に基づいてシェーディングに分布され、データを均等に配布し、ホットスポットを回避するためのハッシュベースのシェーディングもサポートしています。 さらに、ScyllaDB により、複数のデータセンター間でデータを複製し、より高い可用性と低い遅延を可能にします。 クライアント側では、アプリケーションは複数のデータセンターの展開を認識しているか、または認識していない可能性があり、アプリケーション開発者がデータセンター(s)のバラバック認識を決定する場合があります。これは、クエリが単一のデータセンターまたはすべてのデータセンターに対して実行されるかどうかを定義する読み書きの一致性オプションを介して構成することができます。 A Comparative Scalability Viewpoint on the Distributed Architectures of MongoDB and ScyllaDB(MongoDBとScyllaDBの分散アーキテクチャ) スケーラビリティに関しては、ScyllaDBとMongoDBの両方の大幅に異なる配布アプローチを考慮する必要があり、特にオンプレミスまたはIaaSで実行されている自己管理クラスターの場合です。 しかしながら、著しい書き比率を持つワークロードをスケーリングするには、レプリカセットをシェアレプリカセットに変換する必要があり、これにはいくつかの課題が伴います。第一に、追加の2つのMongoDBサービスが必要です: n クエリ ルーター (mongos) と、高可用性を確保するためのレプリカセットのコンフィギング サーバー。したがって、シェアリングを可能にするには、より多くのリソースが必要です。さらに、操作の複雑性は明らかに増加します。例えば、3 シェアドのシェアドクラスターには、3 つのモンゴスインスタンスのレプリカセット、3 つのコンフィギング サーバーと 3 つのシェアドのレプリカセットが必要です。 二つ目の課題は、分割クラスター内のデータの分割である。ここでは、MongoDBは、分割クラスターに新しい分割を加えるときにではなく、一定の内部限界を達成したときに、データの再分配を自動的に引き起こす継続的に実行される背景タスクを実施します。したがって、分割の数を増やすことでクラスターはすぐに拡大するが、拡大効果が遅れる可能性があります。MongoDBバージョン 5.0まで、MongoDBエンジニア自身は、分割をしないことをお勧めしますが、可能であればより大きなマシンで垂直に拡大することをお勧めします。 ScyllaDB クラスターのスケーリングは、ScyllaDB の複数の主なアーキテクチャのおかげでユーザーにとって比較的簡単で透明です。ここでは、各ノードは平等で、クラスターを数百のノードにスケーリングするために追加サービスは必要ありません。また、データ分割は、クラスターに新しいノードを追加するとすぐに起動します。この文脈では、ScyllaDB は MongoDB に比べて明確な利点を提供します。第一に、一貫したハッシュアップアプローチのおかげで、データはクラスター全体に分割される必要はありません、ノードのサブセットにのみ。第二に、分割は新しいノードを追加することから始まります。これは、分割がクラスターにいくつかの追加負荷を与え、ピークワーク 主要なスケーラビリティの違いは、次の表でまとめられています。 結論と展望 二つの分布を比較すると、 データベースでは、常にいくつかの並列を発見するが、また数多くの大きな違いを発見する。 . 両方のデータベースは、類似の使用例に対応し、類似の製品およびコミュニティ戦略を持っていますが、技術面では、異なるアプローチと焦点を見ることができます。両方のデータベースは、分散型アーキテクチャを通じて高可用性を可能にするために構築されています。しかし、ターゲットワークロードに関しては、MongoDBは、小規模および中規模のワークロードに適した単一ノードまたは複製セットの展開を容易に開始することができます。 ノスカル ScyllaDB vs MongoDB ScyllaDB は、容易かつ高スケーラビリティ、高スケーラビリティ、低かつ安定した遅延、および複数のデータセンターデプロイのすべてを必要とするパフォーマンスに重要なワークロードに対応しています。 また、それぞれのパフォーマンス能力の詳細な洞察を提供するため、MongoDB Atlas および ScyllaDB Cloud のパフォーマンス、スケーラビリティ、およびコストを調査する別々のベンチマークレポートで、透明で再現可能なパフォーマンス比較を提供します。 ScyllaDB vs. MongoDB 比較の詳細 見る Complete 以下を比較する詳細を含む本技術比較の拡張版について: BenchANT MongoDB vs ScyllaDB 比較 データモデル 言語 Query 使用事例と顧客事例 Data Consistency オプション 第一手作業経験
