Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. NoSQL ドメイン内では、ScyllaDB と MongoDB は完全に異なる 2 つの動物です。MongoDB は導入を必要としません。そのシンプルな採用と広範なコミュニティ / エコシステムは、デフォルトの標準となっています。 ScyllaDBの近代的なアーキテクチャは、高いスピードで予測可能な低遅延を可能にします。 で、 スケールする人も多い。 既存のデータベースと壁を叩く。 ノスカル ディスコード トラクション データ密集型アプリケーション 代わりに、これらの2つの明らかに異なるデータベースが同じテクノロジースタック内でどのように共存するかを見てみましょう - 彼らがどのように根本的に異なっているか、そしてそれぞれのための最高の使用例です。 では、いつ ScyllaDB vs. MongoDB を使用するべきですか? なぜですか? ベンダーの視点を提供するのではなく、 ScyllaDB と MongoDB の両方を生産に使用するための幅広い経験を持つオープンソース愛好家の洞察を共有するつもりです: Alexys Jacob、NumberlyのCTO。 以下は彼の詳細なテクノロジーのスピーチからの3つの主要な取り組みです。 Scaling WritesはMongoDBでより複雑です。 MongoDBトポロジーのベースユニットはレプリカセットと呼ばれ、これは1つの主なノードで、通常は複数の次元ノードで構成されています(ホットレプリカを考えてください)。 データを書くことができるのは主なノードだけです。 MongoDBで垂直スケーリングを最大化した後、レプリカセットをスケーリングする唯一のオプションは、シェアードクラスターと呼ばれるものになります。 これには、複数のプレミアリーを1つのレプリカセットに含めることができないため、新しいレプリカセットを追加する必要があります。 MongoDBのレプリカセットのデータをシェアするには、それぞれのレプリカセットが何のデータに責任があるかを指定する特別なキーを使用する必要があり、また、それぞれのレプリカに何のデータが生きているかを追跡するメタデータレプリカセットを作成する必要がある(下の図の青い三角形)。また、MongoDBクラスターに接続するクライアントは、どのノードをアドレスするかを決定するのに役立つ必要があります。 MongoDBにおけるスケーリングの複雑さ これらのノードをすべて持つことは、複製ノードのIOをタップできないため、より高い運用およびメンテナンスコスト、およびリソースの浪費につながり、分断されたMongoDBクラスターを、Alexysが指摘したように、所有コスト全体の最悪の敵にします。 ScyllaDBの場合、スケーリングはよりシンプルであると彼は説明し、「ScyllaDB側では、より多くのスケーラプトを追加したい場合は、ノードを追加するだけです。 Alexys linked up this scaling thread: アレクシスはこのスケーリングトレードを結びつけた。 「MongoDBクラスターを作成するのを避けてください!私はこの話題について戦争ストーリーを書くことができた。その主な理由は、MongoDBがワークロードをCPUに結び付けないという事実です。そして、クラスター内のレプリカセット間のデータの分布は、バックグラウンドワーク(バランザー)によって行われます。このバランザーは常に実行されており、常にシェアリングがどのように行われるべきかを調べ、常にデータがクラスター全体に広がってバランスをとることを確実にします。それは一貫したハッシュリングに基づいていないため、自然ではありません。それは繰り返し計算されなければならないものです。それはデータをブロックに分割し、それを回転します。これはあなたのMongoDBクラスターのパフォーマンスに直接的な影響 MongoDB はパフォーマンスよりも柔軟性を好み、ScyllaDB は多様性よりも一貫したパフォーマンスを好みます ScyllaDB と MongoDB は、柔軟性とパフォーマンスに関して明らかに異なる優先順位を持っています。 データモデリングの前面では、MongoDB は地理空間のクエリ、テキスト検索、集計パイプライン、グラフクエリ、変更ストリームをネイティブにサポートしています。 ScyllaDB は広い列ストア(キーキー値)ですが、ユーザー定義のタイプ、カウンター、軽量なトランザクションをサポートしていますが、データモデリングのオプションは MongoDB より制限されています。 データ挿入前のスケジュール検証の実施、ScyllaDB このデータは、定義されたスケジュールに適合します。 オプション 必要 クエリは、JSONとフィルタリングし、相互作用するだけで簡単です。さらに柔軟で、より良いか悪いかを問うことができます。MongoDBは、生産ワークロードで不最適なパフォーマンスを引き起こすクエリを含め、あらゆる種類のクエリを発行することを可能にします。 Alexysは、開発の観点から主な違いをまとめました。 「MongoDBはパフォーマンスよりも柔軟性を好みます。インタラクションは簡単で、あなたの道に迷うことはありませんが、パフォーマンスに影響を与えます - いくつかのワークロードには良い影響がありますが、他の人々には受け入れられないです。他方で、ScyllaDBはパフォーマンスを多様性に比べて一貫することを好みます。外部では少し固定し、少し硬くなります。しかし、再び、それはあなた自身の利益のためですので、一貫したパフォーマンスを持って、うまく動作し、システムとよく相互作用することができます。 パフォーマンスベストプラクティスに従うクエリでさえ、ScyllaDB よりも MongoDB では異なります。 ScyllaDB と MongoDB は Great NoSQL Combo です。 「これは死の試合ではなく、私たちはMongoDBとScyllaDBの両方の幸せなユーザーです」とAlexysは続けた。 Numerly は、各ケースのテクニカル要件に最適なデータベースを選択します。 Numerly では、MongoDB は 2 種類の使用ケースに使用されます。 REST API と、おそらく柔軟なスケジュールを備えた Web バックエンド。 予測不能な行動データに対するリアルタイムのクエリ たとえば、Nummerlyのアプリケーションのいくつかは、クライアントが収集して送信するWebトラッキングデータ(各クライアントが独自の内部開発アプリケーションを持つ)に浸透しています。Nummerlyは、そのデータに厳格なスケジュールを課す方法を持っていませんが、クエリや処理を可能にする必要があります。 ScyllaDB は Numberly で 3 種類の使用ケースに使用されます。 リアルタイムの遅延に敏感なデータパイプライン. これは、データパイプライン上でリアルタイムで関連付けられる必要がある複数のデータソースが多く含まれている。Alexysによると、「それは難しい...そして、お客様の顧客がパイプラインに依存しているアプリケーションとデータプロセスのSLA(サービスレベルの合意)を破らないように、強力な遅延保証が必要です。 混合バッチとリアルタイムワークロード. Numberly は ScyllaDB で多くのバッチとリアルタイムワークロードを混合しているため、両方の世界のベストを提供します (Numly が以前共有したように)。 GraphQL を使用する Web バックエンドは、厳格なスケジュールを課す。Numberly の Web バックエンドのいくつかは GraphQL で実装されています。 アレクシス氏は「多くのバックエンドのエンジニアやフロントエンドのエンジニアがScyllaDBを採用しています。私たちはScyllaDBを採用する傾向があり、ますます多くのテクノロジーの人々が「私はこの使用ケースを持っていますか? ScyllaDBは適合しますか?」と尋ねています。ほとんどの場合、答えは「はい」です。 ボーナス: More Insights from Alexys Jacob Alexys は、コードと会議の両方に関して、オープンソースコミュニティに極めて寛大な貢献者です。 https://ultrabug.fr/ について シンシア・ダンロップ Cynthia は ScyllaDB のコンテンツ戦略のシニアディレクターであり、20年以上にわたりソフトウェア開発と品質エンジニアリングについて書いています。
