開発者のための NoSQL ガイド

バックエンド開発とビッグデータのトレンドを追っている人なら、ここ数年のNoSQLデータベースに関する話題にすでに気づいているでしょう。データベースへのこのアプローチにインスピレーションを受ける人もいれば、そこには何らかのトリックが隠されていると考える人もいます。つまり、データベースのデータ モデルは通常のリレーショナル データベースと同じではなく、アプリケーション プログラミング インターフェイスは独特で、アプリケーションは理解できないことがよくあります。 この記事では、そもそもなぜこれらの NoSQL データベースが作成されたのか、それらがどのような問題を解決するのか、そしてなぜこれほど多くの異なるデータベースが突然必要になったのかについて説明します。NoSQL を初めて使用する場合は、この記事の最後の部分に特に興味があるかもしれません。この部分には、この分野を完全に理解するために最初に検討する価値があると思われる NoSQL データベース タイプがリストされています。

なぜ突然新しいデータベースが必要になるのでしょうか?

「リレーショナル データベースの何が問題なのか?」と疑問に思うかもしれません。重要なのは、彼らは長年にわたって非常にうまく機能していましたが、今ではもう対処できない問題が発生しているということです。いくつかの予測によると、2018 年に人類は毎秒 50,000 ギガバイトのデータを生成するでしょう。これは膨大な量のデータです！その保管と取り扱いには、エンジニアリング上の重大な課題が生じます。さらに悪いことに、この量は増え続けているということです。結局のところ、リレーショナル データベースは、大量のデータを扱うのにはあまり適していません。これらは 1 台のマシンで実行するように設計されており、より多くのリクエストを処理したい場合は、より多くの RAM とより強力なプロセッサを搭載したコンピュータを購入するしか選択肢はありません。残念ながら、1 台のマシンで処理できるクエリの数は限られており、複数のマシンに分散して作業するには、別のデータベース テクノロジが必要です。もちろん、読者の中には、この時点で笑い、リレーショナル データベースの場合に複数のマシンを使用する方法として、レプリケーションとシャーディングの 2 つが広く使用されていると言う人もいるでしょう。それは事実ですが、これらの方法では私たちのタスクに対処するには十分ではありません。 読み取りレプリケーションは、各データベースの更新を読み取り要求のみを処理できる他のマシンに伝播する手法です。この場合、すべての変更はマスター ノードと呼ばれる 1 台のサーバーによって実行され、リード レプリカと呼ばれる他のサーバーはデータのコピーのみを維持します。ユーザーはどのマシンからでも読み取ることができますが、データの変更はマスター ノードを介してのみ行うことができます。これは便利で非常に人気のある方法ですが、より多くの読み取りリクエストを処理できるだけであり、必要な量のデータを処理するという問題はまったく解決されません。 シャーディングは、リレーショナル データベースの複数のインスタンスを使用するもう 1 つの一般的なアプローチです。それぞれがデータの一部に対する書き込みおよび読み取り操作を処理します。たとえば、シャーディングを使用してデータベースに顧客に関する情報が保存されている場合、あるマシンは名前が A で始まる顧客のすべてのリクエストを処理でき、別のマシンは名前が B で始まる顧客のすべてのデータを保存できます。 シャーディングを使用するとより多くのデータを記録できますが、そのようなデータベースの管理は本当に悪夢です。必要に応じてマシン間でデータを調整し、クラスターを両方向に拡張する必要があります。理論的には簡単そうに見えますが、正しく理解するのは非常に困難です。

リレーショナル データベースは改善できるでしょうか?

リレーショナル データベースは、現代社会で生成されるデータ量に最適ではない、ということはすでにおわかりかと思います。ただし、複数のマシン間で効率的に実行できる「より優れた」リレーショナル データベースをなぜ誰もまだ作成していないのか、疑問に思われるかもしれません。このテクノロジーはまだ開発されていないだけのように思われるかもしれませんが、分散リレーショナル データベースはすぐに登場するでしょう。 ああ、そんなことは起こらないだろう。これは数学的に不可能であり、それについては何もできません。 この理由を理解するには、いわゆる CAP 定理 (別名ブリューワーの定理) を調べる必要があります。これは 1999 年に証明されており、複数のマシンで実行されている分散データベースには次の 3 つの特性があることが記載されています。 一貫性-あらゆる読み取り操作は、最後に対応する書き込み操作の結果を返します。システムに一貫性がある場合、新しいデータを書き込んだ後、すでに上書きされた古いデータを読み取ることはできません。 可用性(可用性) - 分散システムは、いつでも受信リクエストを処理し、エラーのない応答を返すことができます。 パーティション耐性-一部のサーバーが一時的に相互に通信できなくなった場合でも、データベースは読み取りおよび書き込みリクエストに応答し続けます。この一時的な障害はネットワーク接続障害と呼ばれ、サーバーの速度が遅いことによる物理的なネットワークの問題からネットワーク機器の物理的な損傷まで、さまざまな要因によって引き起こされる可能性があります。これらのプロパティはすべて確かに便利であり、これらすべてを組み合わせたデータベースが本当に必要です。まともな開発者であれば、たとえば、何も見返りを得ずにアクセシビリティを放棄したいとは思わないでしょう。残念ながら、CAP 定理は、3 つの特性すべてが同時に成立することは不可能であるとも述べています。 これを実現するのは簡単ではないかもしれませんが、可能です。まず、分散データベースが必要な場合は、「切断耐性」がなければなりません。これについては議論すらされていない。切断は常に発生するため、データベースはそれにもかかわらず機能する必要があります。ここで、一貫性と可用性の両方を達成できない理由を理解しましょう。2 台のマシン A と B で実行されている単純なデータベースがあると想像してください。どのユーザーもどちらのマシンにも書き込むことができ、その後データはもう一方のマシンにコピーされます。 ここで、これらのマシンが一時的に相互に通信できなくなり、マシン B がマシン A との間でデータの送受信ができなくなったと想像してください。この期間中にマシン B がクライアントから読み取りリクエストを受信した場合、マシン B には 2 つのオプションがあります。

1. 最新ではない場合でも、ローカル データを元に戻します。この場合、可用性が優先されます (古いデータであっても、少なくとも一部のデータを返すため)。
2. エラーを返します。この場合、一貫性が優先されます。クライアントは古いデータを受信しませんが、データをまったく受信しません。

リレーショナル データベースは、「一貫性」と「可用性」の特性を同時に実現しようとするため、分散環境では動作できません。リレーショナル データベースのすべての機能を分散システムに実装しようとすることは、非現実的であるか、まったく不可能です。一方、NoSQL データベースはスケーラビリティとパフォーマンスを重視します。通常、それらには接続やトランザクションなどの「基本的な」機能が欠けており、データ モデルは完全に異なることが判明し、おそらく何らかの制限さえあります。これらすべてにより、これまでよりも大量のデータを保存し、より多くのクエリを処理できるようになります。

NoSQL データベースは一貫性と可用性のバランスをどのようにとっているのでしょうか?

NoSQL データベースを選択すると、常に古いデータが受信されるか、障害が発生した場合にエラーが表示されるように思われるかもしれません。実際には、可用性と一貫性だけが利用可能な唯一のオプションではありません。幅広いオプションからお選びいただけます。リレーショナル データベースにはこれらのオプションがありませんが、NoSQL では同様の方法でクエリの実行を制御できます。いずれにせよ、NoSQL データベースで書き込みまたは読み取り操作を実行するときに、次の 2 つのパラメーターを設定できます。 W -書き込み操作を実行するときに、クラスター内の何台のマシンがデータの保存を確認する必要があるか。データを書き込むマシンの数が多いほど、次回の読み取り操作で最新のデータを読み取るのは簡単になりますが、時間がかかります。 R –データを読み取るマシンの数。分散システムでは、クラスター内のすべてのマシンにデータを配布するのに時間がかかる場合があるため、一部のサーバーには最新のデータがあり、他のサーバーには遅れが生じます。データを読み取るマシンの数が多いほど、現在のデータを読み取る可能性が高くなります。実際の例を見てみましょう。クラスター内に 5 台のコンピューターがあり、1 台だけにデータを書き込み、ランダムに選択した 1 台のコンピューターからデータを読み取る場合、80% の確率で古いデータが読み取られます。一方、これにより使用されるリソースは最小限になります。したがって、レガシーデータで問題ないのであれば、それほど悪い選択肢ではありません。この場合、パラメータ W と R は 1 に等しくなります。 一方、NoSQL データベース内の 5 台のマシンすべてにデータを書き込む場合は、どのマシンからでもデータを読み取ることができ、常に最新のデータを取得できることが保証されます。多数のマシンで同じ操作を実行すると時間がかかりますが、最新のデータが重要な場合は、このオプションを選択できます。この場合、W = R = 5 です。データベースの一貫性を保つために必要な読み取りと書き込みの最小回数はどれくらいですか? 簡単な式は次のとおりです: R + W ≥ N + 1 (N はクラスター内のマシンの数)。これは、サーバーが 5 台ある場合、R = 2 および W = 4、または R = 3 および W = 3、または R = 4 および W = 2 のいずれかを選択できることを意味します。この場合、データがどのマシンに保存されるかは問題ではありません。が書き込まれると、常に最新のデータを持つ少なくとも 1 台のマシンから読み取りが行われます。 DynamoDB などの他のデータベースには異なる制限があり、一貫した書き込みのみが許可されます。各データは 3 台のサーバーに保存され、データが書き込まれると、3 台のマシンのうち 2 台に書き込まれます。ただし、データを読み取るときは、次の 2 つのオプションのいずれかを選択できます。

1. 厳密に一貫した読み取り。3 台のマシンのうち 2 台からデータが読み取られ、常に最後に書き込まれたデータが返されます。
2. 結果整合性読み取り。データを読み取るマシンが 1 台ランダムに選択されます。ただし、これにより一時的に古いデータが返される可能性があります。

NoSQL データベースがこれほど多く存在するのはなぜですか?

ソフトウェア開発分野の最新ニュースをフォローしている場合は、MongoDB、DynamoDB、Cassandra、Redis など、さまざまな NoSQL データベースについて聞いたことがあるでしょう。「なぜこれほど多くの異なる NoSQL データベースが必要なのでしょうか?」と疑問に思われるかもしれません。理由は簡単です。異なる NoSQL データベースは異なる問題を解決するように設計されているからです。競合するデータベースの数が非常に多いのはこのためです。NoSQL データベースは、次の 4 つの主要なカテゴリに分類されます。

ドキュメント指向データベース

これらのデータベースは、複雑なネストされたドキュメントを保存する機能を提供しますが、ほとんどのリレーショナル データベースは 1 次元の行のみをサポートします。この機能は、システム内に複数のアドレスを持つユーザーに関する情報を保存する必要がある場合など、多くの場合に役立ちます。ドキュメント指向データベースを使用する場合、この場合は住所の配列を含む複雑なオブジェクトを単に格納できますが、リレーショナル データベースでは、ユーザー情報用と住所用の 2 つのテーブルを作成する必要があります。ドキュメント指向データベースは、オブジェクト モデルとデータ モデルの間のギャップを埋めます。PostgreSQL などの一部のリレーショナル データベースでは、ドキュメント指向のストレージもサポートされるようになりましたが、ほとんどのリレーショナル データベースにはまだこの機能がありません。

キー/値データベース

通常、キー/値データベースは最も単純な NoSQL モデルを実装します。基本的に、分散ハッシュ テーブルが提供され、特定のキーにデータを書き込み、それを使用してデータを読み取ることができます。キー/値データベースは拡張性が高く、他のデータベースに比べて待ち時間が大幅に短くなります。

グラフデータベース

ソーシャル ネットワークや映画や俳優に関する情報など、多くの主題領域はグラフとして表すことができます。グラフはリレーショナルデータベースを使用して表現できますが、難しくて不便です。グラフ データが必要な場合は、分散クラスターにグラフに関する情報を保存でき、グラフにアルゴリズムを効率的に実装できる特殊なグラフ データベースを使用することをお勧めします。

列指向データベース

列指向データベースと他のタイプのデータベースの主な違いは、データがディスクに保存される方法です。リレーショナル データベースはテーブルごとにファイルを作成し、すべての行の値を順番に保存します。列指向データベースでは、テーブル内の列ごとにファイルが作成されます。この構造により、データを集約し、特定のクエリをより効率的に実行できますが、データがそのようなデータベースの制限に適合していることを確認する必要があります。

どのデータベースを選択すればよいでしょうか?

データベースの選択は通常、悩ましい問題であり、利用可能なオプションが非常に多いため、途方もない作業のように思えるかもしれません。幸いなことに、1 つだけを選択する必要はないということです。すべての機能を実装し、すべてのシステム データにアクセスできる単一のモノリシック アプリケーションを作成する代わりに、マイクロサービスと呼ばれる別の最新のパターンを使用できます。つまり、アプリケーションを一連の独立したサービスに分割します。各サービスは独自の狭い問題を解決し、この問題の解決に最適な独自のデータベースのみを使用します。

これをどうやって学べばいいのでしょうか？

データベースが非常に多いため、すべてを学習するのは不可能な作業のように思えるかもしれません。良いニュースです。これを行う必要はありません。NoSQL データベースの基本的なタイプはほんの数種類しかありません。それらがどのように機能するかを理解していれば、他のタイプもはるかに理解しやすくなります。また、一部の NoSQL データベースは他のデータベースよりもはるかに頻繁に使用されるため、最も人気のあるソリューションに重点を置くことが最善です。以下に、最も一般的に使用されている NoSQL データベースのリストを示します。参考にしてください。

1. モンゴDB。おそらく市場で最も人気のある NoSQL データベースです。企業がプライマリ データ ストアとしてリレーショナル データベースを使用していない場合は、おそらく MongoDB を使用します。これは、優れたツールセットを備えた柔軟なドキュメントストレージです。MongoDB はキャリアの初期には、場合によってはデータが失われるという悪い評判がありましたが、それ以来、その安定性と信頼性は大幅に向上しました。さらに詳しく知りたい場合は、このMongoDB コースをご覧ください


2. DynamoDB。アマゾン ウェブ サービス (AWS) を使用している場合は、DynamoDB について詳しく学習することをお勧めします。これは、豊富な機能セットと他の多くの AWS サービスとの統合を備えた、非常に信頼性が高く、スケーラブルで低レイテンシのデータベースです。最も良い点は、自分でデプロイする必要がないことです。わずか数クリックで、数千のクエリを処理できるスケーラブルな DynamoDB クラスターをセットアップできます。ご興味がございましたら、このコースをご覧ください。


3. Neo4j。最も一般的なグラフ データベース。これは、グラフ データ モデルを使用したい人に適した、スケーラブルで安定したソリューションです。さらに詳しく知りたい場合は、このコースから始めてください。


4. レディス。ここで説明する他のデータベースはコア アプリケーション データの保存に使用されますが、Redis は主にキャッシュの実装と補助データの保存に使用されます。多くの場合、上記のデータベースのいずれかが Redis と連携して使用されます。さらに詳しく知りたい場合は、このコースをご覧ください。

2018 年に NoSQL を導入

NoSQL データベースは広大かつ急速に成長している分野です。これにより、以前は想像もできなかった量のデータを保存および処理できるようになりますが、それにはコストがかかります。これらのデータベースには、リレーショナル データベースでよく知られている機能があまりなく、それらを使用するためのセットアップを行うのが難しい場合があります。ただし、コツを掴めば、驚くべき量の読み取りおよび書き込みリクエストを処理できるスケーラブルな分散データベースを作成できます。これは、生成されるデータの量がますます増加するにつれて非常に重要になります。 オリジナル: https://simpleprogrammer.com/guide-nosql-software-developers/