NoSQLとは何ですか?クラウド規模の未来のためのデータベース

アプリケーションを開発するときに行う最も基本的な選択の1つは、SQLデータベースとNoSQLデータベースのどちらを使用してデータを格納するかです。従来のSQL(つまりリレーショナル)データベースは、何十年にもわたるテクノロジーの進化、グッドプラクティス、および実際のストレステストの成果です。これらは、基幹業務アプリケーションの主要部分である、信頼性の高いトランザクションとアドホッククエリ用に設計されています。ただし、厳密なスキーマなど、他の種類のアプリには適さないという制限もあります。

これらの制限に対応して、NoSQLデータベースが生まれました。NoSQLシステムは、開発者の側で高い運用速度と優れた柔軟性を可能にする方法でデータを保存および管理します。多くは、Google、Amazon、Yahoo、Facebookなど、大規模なWebサイトのコンテンツを保存したりデータを処理したりするためのより良い方法を模索している企業によって開発されました。SQLデータベースとは異なり、多くのNoSQLデータベースは、数百または数千のサーバーにわたって水平方向に拡張できます。

ただし、NoSQLの利点はコストなしでは得られません。NoSQLシステムは通常、SQLデータベースと同じレベルのデータ整合性を提供しません。実際、SQLデータベースは従来、信頼性の高いトランザクションの背後にあるACIDプロパティのパフォーマンスとスケーラビリティを犠牲にしてきましたが、NoSQLデータベースは、速度とスケーラビリティに関するACIDの保証を大幅に廃止しました。

つまり、SQLデータベースとNoSQLデータベースには異なるトレードオフがあります。これらは、特定のプロジェクトのコンテキストで競合する可能性がありますが(たとえば、このアプリケーションまたはそのアプリケーションのどちらを選択するか)、全体像を補完します。それぞれがさまざまなユースケースに適しています。どちらのツールがその仕事に適しているかという問題であるため、決定はどちらかまたは両方の場合ではありません。

NoSQLとSQL

SQLとNoSQLの根本的な違いは、それほど複雑ではありません。それぞれが、データの保存方法と取得方法について異なる哲学を持っています。

SQLデータベースでは、すべてのデータに固有の構造があります。Microsoft SQL Server、MySQL、Oracle Databaseなどの従来のデータベースは、スキーマを使用します。これは、データベースに挿入されるデータがどのように構成されるかを正式に定義したものです。たとえば、テーブル内の特定の列は整数のみに制限される場合があります。その結果、列に記録されたデータは高度に正規化されます。SQLデータベースの厳密なスキーマにより、たとえばJOINを使用してデータの集計を比較的簡単に実行することもできます。

NoSQLを使用すると、データをスキーマなしまたは自由形式で保存できます。任意のデータを任意のレコードに保存できます。NoSQLデータベースの中には、データを格納するための4つの一般的なモデルがあり、4つの一般的なタイプのNoSQLシステムにつながります。

  1. ドキュメントデータベース(CouchDB、MongoDBなど)。挿入されたデータは、自由形式のJSON構造または「ドキュメント」の形式で保存されます。データは、整数から文字列、自由形式のテキストまで、何でもかまいません。ドキュメントに含まれるフィールドがある場合は、それを指定する必要はありません。
  2. Key-Valueストア(Redis、Riakなど)。単純な整数や文字列から複雑なJSONドキュメントまで、自由形式の値は、キーを介してデータベースにアクセスされます。
  3. 幅の広い列ストア(HBase、Cassandraなど)。データは、従来のSQLシステムのように行ではなく列に格納されます。クエリまたはデータビューの必要に応じて、任意の数の列(したがって多くの異なるタイプのデータ)をグループ化または集約できます。
  4. グラフデータベース(例:Neo4j)。データは、エンティティとその関係のネットワークまたはグラフとして表され、グラフ内の各ノードは自由形式のデータのチャンクです。

スキーマレスデータストレージは、次のシナリオで役立ちます。

  1. データへの高速アクセスが必要であり、信頼できるトランザクションや一貫性よりも、アクセスの速度と単純さに関心があります。
  2. 大量のデータを保存していて、後でスキーマを変更するのは遅くて苦痛になる可能性があるため、スキーマに自分自身を固定したくありません。
  3. 非構造化データを生成する1つ以上のソースから取り込んでおり、最大限の柔軟性を得るためにデータを元の形式に保ちたいと考えています。
  4. データを階層構造で格納したいが、それらの階層を外部スキーマではなくデータ自体で記述したい。NoSQLを使用すると、SQLデータベースがエミュレートするのがより複雑な方法で、データを何気なく自己参照することができます。

NoSQLデータベースのクエリ

従来のデータベースで使用されている構造化照会言語は、データを格納および取得するときにサーバーと通信するための統一された方法を提供します。SQL構文は高度に標準化されているため、個々のデータベースは特定の操作(ウィンドウ関数など)を異なる方法で処理できますが、基本は同じです。

対照的に、各NoSQLデータベースには、データのクエリと管理のための独自の構文がある傾向があります。たとえば、CouchDBは、HTTP経由で送信されるJSON形式のリクエストを使用して、データベースからドキュメントを作成または取得します。MongoDBは、コマンドラインインターフェイスまたは言語ライブラリを介して、バイナリプロトコルを介してJSONオブジェクトを送信します。

一部のNoSQL製品、SQLに似た構文を使用してデータを処理できますが、その範囲は限られています。たとえば、列ストアデータベースであるApache Cassandraには、独自のSQLに似た言語であるCassandraクエリ言語(CQL)があります。SELECTやINSERTキーワードのように、CQL構文の一部はSQLプレイブックから直接引用されています。ただし、CassandraでJOINまたはサブクエリを実行する方法がないため、関連するキーワードはCQLに存在しません。

シェアードナッシングアーキテクチャ

NoSQLシステムに共通する設計上の選択は、「シェアードナッシング」アーキテクチャです。シェアードナッシングデザインでは、クラスター内の各サーバーノードは他のすべてのノードから独立して動作します。システムは、データの一部をクライアントに返すために、すべての単一ノードからコンセンサスを得る必要はありません。クエリは、最も近いノードまたは最も便利なノードから返されるため、高速です。

シェアードナッシングのもう1つの利点は、復元力とスケールアウトです。クラスターのスケールアウトは、クラスター内の新しいノードを起動し、それらが他のノードと同期するのを待つのと同じくらい簡単です。NoSQLノードがダウンした場合、クラスター内の他のサーバーは引き続き動作します。リクエストを処理するために使用できるノードが少なくても、すべてのデータは引き続き使用できます。

シェアードナッシングデザインはNoSQLデータベース専用ではないことに注意してください。多くの従来のSQLシステムは、シェアードナッシング方式でセットアップできますが、通常、パフォーマンスのためにクラスター全体の一貫性を犠牲にする必要があります。

NoSQLの制限

NoSQLが非常に多くの自由と柔軟性を提供するのであれば、SQLを完全に放棄してみませんか?簡単な答え:多くのアプリケーションは、SQLデータベースが提供する種類の制約、一貫性、および保護手段を依然として求めています。そのような場合、NoSQLのいくつかの「利点」が欠点になる可能性があります。その他の制限は、NoSQLシステムが比較的新しいという事実から生じています。 

スキーマなし

自由形式のデータを取り込んでいる場合でも、それを有用にするために、ほとんどの場合、データに制約を課す必要があります。NoSQLでは、制約を課すには、データベースからアプリケーション開発者に責任を移す必要があります。たとえば、開発者はオブジェクトリレーショナルマッピングシステム(ORM)を介して構造を課すことができます。ただし、スキーマをデータ自体と共存させたい場合、NoSQLは通常それを行いません。

一部のNoSQLソリューションは、オプションのデータ入力およびデータ検証メカニズムを提供します。たとえば、Apache Cassandraには、従来のSQLに見られるものを彷彿とさせる多数のネイティブデータ型があります。

結果整合性

NoSQLシステムは、可用性とパフォーマンスを向上させるために、強力または即時の一貫性をトレードします。従来のデータベースは、操作がアトミック(トランザクションのすべての部分が成功するか、成功しない)、一貫性(すべてのユーザーがデータの同じビューを持つ)、分離(トランザクションが競合しない)、および耐久性(完了すると存続する)であることを保証しますサーバー障害)。

これらの4つのプロパティは、まとめてACIDと呼ばれ、ほとんどのNoSQLシステムでは異なる方法で処理されます。クラスター内の他のノードに更新をコピーするために必要な時間のため、クラスター全体での即時の一貫性の代わりに、結果整合性があります。クラスターに挿入されたデータは、最終的にはどこでも利用できるようになりますが、いつ保証することはできません。

トランザクションセマンティクスは、SQLシステムでは、トランザクションのすべてのステップ(たとえば、販売の実行在庫の削減)が完了するか、ロールバックされることを保証しますが、通常、NoSQLでは使用できません。銀行など、「信頼できる唯一の情報源」が必要なシステムでは、NoSQLアプローチはうまく機能しません。どのATMに行くかによって、銀行の残高が異なることは望ましくありません。あなたはそれがどこでも同じものとして報告されることを望みます。

一部のNoSQLデータベースには、これを回避するための部分的なメカニズムがあります。たとえば、MongoDBには個々の操作の一貫性が保証されていますが、データベース全体の一貫性は保証されていません。Microsoft Azure CosmosDBでは、リクエストごとに一貫性のレベルを選択できるため、ユースケースに適した動作を選択できます。ただし、NoSQLでは、デフォルトの動作として結果整合性が期待されます。

NoSQLロックイン

ほとんどのNoSQLシステムは概念的には似ていますが、実装方法が大きく異なります。それぞれが、データのクエリと管理の方法について独自のメタファーとメカニズムを持っている傾向があります。

その副作用の1つは、アプリケーションロジックとデータベース間の潜在的に高度な結合です。これは、NoSQLシステムを選択してそれを使い続ける場合はそれほど悪くはありませんが、将来的にシステムを変更すると、障害になる可能性があります。

たとえば、MongoDBからCouchDBに(またはその逆に)移行する場合は、データを移行するだけでは不十分です。また、データアクセスとプログラムによるメタファーの違いをナビゲートする必要があります。つまり、データベースにアクセスするアプリケーションの部分を書き直す必要があります。

NoSQLスキル

NoSQLのもう1つの欠点は、専門知識が比較的不足していることです。従来のSQL人材の​​市場がまだかなり大きい場合、NoSQLスキルの市場はまだ始まったばかりです。

参考までに、Indeed.comは、2017年末の時点で、従来のSQLデータベース(MySQL、Microsoft SQL Server、Oracleデータベースなど)のジョブリストの量は、過去3年間、ジョブの量よりも多いままであると報告しています。 MongoDB、Couchbase、およびCassandraの場合。NoSQLの専門知識に対する需要は高まっていますが、それでも従来のSQLの市場のほんの一部です。

SQLとNoSQLのマージ

SQLシステムとNoSQLシステムの違いのいくつかは時間の経過とともに消えると予想できます。すでに多くのSQLデータベースがJSONドキュメントをネイティブデータ型として受け入れ、そのデータに対してクエリを実行できるようになりました。JSONデータに制約を課すネイティブな方法を備えているものもあるため、従来の行と列のデータと同じ厳密さで処理されます。

反対に、NoSQLデータベースは、SQLに似たクエリ言語だけでなく、従来のSQLデータベースの他の機能も追加しています。たとえば、少なくとも2つのドキュメントデータベース(MarkLogicとRavenDB)は、ACIDに準拠することを約束します。

将来の世代のデータベースがパラダイムにまたがり、NoSQLとSQLの両方の機能を提供する兆候があります。たとえば、MicrosoftのAzure Cosmos DBは、内部で一連のプリミティブを使用して、両方の種類のシステムの動作を交換可能に再現します。Google Cloud Spannerは、強力な一貫性とNoSQLシステムの水平方向のスケーラビリティを組み合わせたSQLデータベースです。

それでも、純粋なSQLシステムと純粋なNoSQLシステムは、今後何年にもわたってその地位を確立するでしょう。自由形式のデータへの高速で拡張性の高いアクセスについては、NoSQLを参照してください。これには、読み取りの一貫性やSQLデータベースに共通するその他の保護手段など、いくつかのコストが伴います。しかし、多くのアプリケーションにとって、これらのセーフガードは、NoSQLが提供するものと交換する価値があるかもしれません。