NoSQLデータベースの戦い-MongoDBとCassandraの比較

MongoDBの概要

MongoDBは、2009年に10genという名前の会社によって導入されました。 10genは後に、ソフトウェアの開発を担当し、このデータベースのエンタープライズバージョンを販売する会社であるMongoDBInc.に名前が変更されました。 MongoDB Inc.は、優れたエンタープライズグレードのサポートチームで24時間体制ですべてのサポートを処理します。彼らは生涯サポートを提供することを約束しています。つまり、顧客は任意のバージョンのMongoDBを使用することを選択し、アップグレードしたい場合はいつでもサポートされます。また、会社が24時間体制で提供しているすべてのセキュリティ修正と同期する機会も提供します。

MongoDBは、クラウドで実行されるWebおよびモバイルアプリケーションの爆発的な成長に後押しされて、過去10年ほどで急増した有名なNoSQLデータベースです。この新しい種類のインターネット接続アプリケーションには、NoSQLデータベースが提供できる、高速でフォールトトレラントでスケーラブルなスキーマレスデータストレージが必要です。 MongoDBは、JSONを使用して、構造の提供が異なる可能性のあるドキュメント、動的で柔軟なスキーマなどのデータを格納します。 MongoDBは、自動シャーディングによる高可用性とスケーラビリティを実現するように設計されています。 MongoDBは、大量のデータストレージに使用されるNoSQLデータベースの下で発生する人気のあるオープンソースデータベースの1つです。 MongoDBには、フィールドがオンザフライで作成されるため、スキーマを定義する必要のないドキュメントと呼ばれる行があります。 MongoDB内で利用可能なデータモデルにより、階層関係の表現、配列の格納、およびその他のより複雑な構造がより効率的になります。

カサンドラの紹介

Apache Cassandraは、無料のオープンソースの分散型ワイドカラムストアとしてよく知られています。 Cassandraは、2008年にFacebookの開発者数名によって紹介され、後にオープンソースプロジェクトとしてリリースされました。現在、Apache Software Foundationによってサポートされており、Apacheは現在、さらなる拡張のためにこのプロジェクトを維持しています。

CassandraはNoSQLデータベース管理システムであり、多くのコモディティサーバーで大量のデータを処理し、単一障害点のない高可用性を提供するように設計されています。 Cassandraは、複数のデータセンターにまたがるクラスターに対して非常に堅牢なサポートを提供し、非同期マスターレスレプリケーションにより、すべてのクライアントの低レイテンシー操作を可能にします。 Cassandraは、GoogleのBigtableのデータモデルを使用してAmazonDynamoのディストリビューションデザインをサポートしています。

MongoDBとCassandraの類似点

これら2つのNoSQLデータベースの簡単な紹介で、これら2つのデータベース間の類似点のいくつかを確認しましょう。

MongoDBとCassandraはどちらもNoSQLデータベースタイプであり、オープンソースのディストリビューションです。

これらのデータベースはいずれも、従来のRDBMSデータベースタイプに代わるものではありません。
これらのデータベースはどちらもACID（Atomicity、Consistency、Isolation、Durability）に準拠していません。これは、データベーストランザクションが確実に処理されることを保証するデータベーストランザクションのプロパティを指します。
これらのデータベースは両方とも、水平分割のシャーディングをサポートしています。
一貫性と正規化は、これら2つのデータベースタイプでは満たされない2つの概念です（これらはRDBMSデータベースタイプに傾いているため）

MongoDBとCassandra：機能

両方のテクノロジーがそれぞれの分野で重要な役割を果たしており、MongoDBとCassandraの類似点は共通の機能を示し、相違点はこれらのテクノロジーの独自性を示しています。

図1MongoDBとCassandra–違いの8つの主な要因表現力豊かなデータモデル

MongoDBは、「オブジェクト指向」または「データ指向」として知られる、リッチで表現力豊かなデータモデルを提供します。このデータモデルは、ユーザーのドメイン内の任意のデータ構造を簡単にサポートおよび表現できます。データにはプロパティを含めることができ、複数のレベルで相互にネストすることができます。 Cassandraは、テーブル構造、行、および特定のデータ型列を備えた従来のデータモデルです。このタイプは、テーブルの作成時に定義されます。とにかく、両方のモデルを比較すると、MongoDBは豊富なデータモデルを提供する傾向があります。次の図は、ストレージとレプリケーションのレベルの観点から、両方のデータベースの一般的な高レベルのアーキテクチャを示しています。

図2：アーキテクチャ図MongoDBとCassandra

高可用性マスターノード

MongoDBは、クラスター内の1つのマスターノードをサポートし、スレーブノードのセットを制御します。マスターノードがダウンした場合、スレーブがマスターとして選出され、同じために約20〜30秒かかります。この遅延時間の間、クラスターはダウンし、入力を受け入れることができなくなります。 Cassandraは、クラスター内の複数のマスターノードをサポートし、マスターノードの1つがオフラインになった場合、その場所は別のマスターノードに引き継がれます。比較すると、Cassandraは、クラスターに影響を与えず、常に利用可能であるため、MongoDBよりも高い可用性をサポートします。

セカンダリインデックス

アプリケーションがデータモデルの柔軟性とともにセカンダリインデックスを必要とする場合、MongoDBにはCassandraと比較してより多くの利点があります。このため、MongoDBは、データベースに格納されているデータのプロパティのインデックスを作成するのがはるかに簡単です。このプロパティを使用すると、クエリを簡単に実行できます。 Cassandraは、単一列と等価比較に制限されているセカンダリインデックスのカーソルサポートを備えています

書き込みスケーラビリティ

MongoDBは1つのマスターノードのみをサポートします。 MongoDBのこのマスターノードは入力のみを受け入れ、MongoDBの残りのノードは出力として使用されます。したがって、データをスレーブノードに書き込んで、マスターノードを通過させる必要がある場合。 Cassandraは、クラスター内の複数のマスターノードをサポートしているため、スケーラビリティの場合に適しています。

クエリ言語のサポート

現在、MongoDBはクエリ言語をサポートしていません。 MongoDBのクエリは、JSONフラグメントとして構造化されています。対照的に、Cassandraには、CQL（Cassandra Query Language）と呼ばれるユーザーフレンドリーなクエリのセットがあり、SQLの予備知識を持つ開発者が簡単に適応できます。彼らのクエリはどのように異なりますか？

顧客テーブルからのレコードの選択：

カサンドラ：

SELECT * FROM customer;

MongoDB：

db.customer.find()

顧客テーブルへのレコードの挿入：

カサンドラ：

INSERT INTO customer (custid, branch, status) VALUES('appl01', 'headquarters', 'A');

MongoDB：

db.customer.insert({ cust_id: 'appl01', branch: 'headquarters', status: 'A' })

顧客テーブルのレコードの更新：

カサンドラ：

UPDATE Customer SET branch = ‘headquarters' WHERE custage > 2;

MongoDB：

db.customer.update( { custage: { $gt: 2 } }, { $set: { branch: 'headquarters' } }, { multi: true } )

ネイティブアグリゲーション

MongoDBには、データベースに格納されているデータを変換するためにETLパイプラインを実行するために使用される組み込みの集約フレームワークがあり、中小規模のデータトラフィックもサポートします。複雑さが増すと、フレームワークのデバッグも難しくなりますが、Cassandraには統合された集約フレームワークがありません。 Cassandraは、Hadoop、Apache Sparkなどの外部ツールを利用しました。したがって、組み込みの集約フレームワークに関しては、MongoDBはCassandraよりも優れています。

スキーマレスモデル

MongoDBは、ユーザーがデータベース上の任意のスキーマの適用を変更できる機能を提供します。各データベースは異なる構造にすることができます。それはすべて、データを解釈するためのプログラムまたはアプリケーションに依存します。一方、Cassandraはスキームを変更する機能を提供していませんが、ユーザーが最初に列のタイプを定義する必要がある場合に静的型付けを提供します。

パフォーマンスベンチマーク

Cassandraは、クラスター内の複数のマスターノードをサポートできるため、大量のデータ負荷を必要とするアプリケーションでのパフォーマンスの向上を検討しています。一方、MongoDBはパフォーマンスに合わせて拡張できないため、データ負荷の高いアプリケーションには理想的ではありません。 Yahoo!が作成した業界標準のベンチマークに基づいています。 YCSBと呼ばれるMongoDBは、実行したすべてのテストでCassandraよりも優れたパフォーマンスを提供し、一部のユースケースでは25倍ものパフォーマンスを提供します。 CassandraとMongoDBの間のスループットと耐久性のバランスを最適化すると、MongoDBは、Cassandraと比較して、混合ワークロードで50％以上高いスループットを提供し、読み取り優位のワークロードで2.5倍高いスループットを提供します。

MongoDBは、特定の操作の耐久性を確保するための最も柔軟性を提供します。ユーザーは、重要と見なされるが追加のレイテンシーが許容される特定の操作に対して、耐久性が最適化された構成を選択できます。 Cassandraの場合、この変更にはサーバー構成ファイルの編集とデータベースの完全な再起動が必要です。

結論

MongoDBは、高度に非構造化されたデータが大量にあるワークロードで最もよく知られています。 MongoDBの柔軟なデータ構造で使用するデータの規模と種類は、Cassandraよりも適しています。 MongoDBを効果的に使用するには、マスターノードに障害が発生した場合にダウンタイムが発生する可能性があることと、書き込み速度が制限されていることを管理できる必要があります。また、新しいクエリ言語も学習する必要があることを忘れないでください。 MongoDBでは、JSON形式のサポート機能を使用して複雑なデータを簡単に管理できます。これは、Cassandraと比較した場合のMongoDBの重要な差別化要因です。状況によっては、Cassandraは、大量のデータ、速度の最適化、およびクエリの実行を伴う場合に実装するのに最適なデータベースと見なすことができます。 CassandraとMongoDBの比較結果から、実装要件と処理するデータの量に応じて、それぞれに利点があることがわかります。