NoSQLデータベース：本質を理解する

最近、「NoSQL」という用語は非常に流行し人気があり、あらゆる種類のソフトウェアソリューションがこの看板の下で積極的に開発および宣伝されています。 NoSQLは、大量のデータ、線形スケーラビリティ、クラスター、フォールトトレランス、非リレーショナルと同義語になりました。 ただし、NoSQLリポジトリとは何か、用語がどのように表示されるか、どのような共通の特徴があるのか​​を明確に理解している人はほとんどいません。 このギャップを解消してみましょう。

物語。

この用語で最も興味深いのは、90年代後半に最初に使用されたという事実にもかかわらず、2009年の半ばにしか使用されなかったという意味では、本当の意味が得られなかったということです。すべてのデータをASCIIファイルとして使用し、SQLの代わりにシェルスクリプトを使用してデータにアクセスしました。 現在の形式の「NoSQL」では、何の関係もありませんでした。



2009年6月、Johann Oscarssonはサンフランシスコで会議を開催し、ITストレージおよび処理市場の新しいトレンドについて議論しました。 会議の主な刺激は、BigTableやDynamoなどの新しいオープンソース製品でした。 会議の明るい兆候を得るには、Twitterハッシュタグに完全に適合する容量のある簡潔な用語を見つける必要がありました。 そのような用語の1つが、RackSpaceのEric Evansによって提案されました-「NoSQL」。 この用語は1回の会議でのみ計画されており、意味的な負荷はあまりありませんでしたが、たまたまバイラル広告のようにグローバルネットワーク全体に広がり、IT業界全体の事実上の名前になりました。 ちなみに会議では、Voldemort（Amazon Dynamoのクローン）、Cassandra、Hbase（Google BigTableのアナログ）、Hypertable、CouchDB、MongoDBが話しました。



「NoSQL」という用語は完全に自発的な起源を持ち、その背後に普遍的に認識されている定義や科学機関がないことを再度強調する価値があります。 この名前は、リレーショナルデータベースとは別にIT開発のベクトルを特徴付けるものです。 SQLだけではありませんが、No SQLの直接定義の支持者はいますが、これはSQLだけではありません。 Pramod SadalajとMartin Fowlerは、最近の本「NoSQL Distilled」で、NoSQLの世界に関する知識をグループ化し体系化しようとしました。

NoSQLデータベース機能

多くの異なるシステムがNoSQLラベルの下に隠れているため、すべてのNoSQLに共通する特性はほとんどありません（最も完全なリストは、おそらくhttp://nosql-database.org/で見つけることができます）。 多くの特性は、特定のNoSQLデータベースにのみ固有のものです。これについては、リストの際に必ず言及します。



1. SQLは使用されません



これはANSI SQL DMLを指します。これは、多くのデータベースがよく知られているお気に入りの構文に類似したクエリ言語を使用しようとしますが、完全に実装することができず、成功する可能性が低いためです。 SQLを実装しようとしているスタートアップがあるという噂もありますが、たとえば、ブートアップ（ http://www.drawntoscalehq.com/およびhttp://www.hadapt.com/ ）



2.非構造化（スキーマレス）



つまり、NoSQLデータベースでは、リレーショナルデータベースとは異なり、データ構造は規制されていません（または、プログラミング言語との類似性を引き出す場合、型指定が不十分です）-テーブル全体の構造を宣言的に変更することなく、別の行またはドキュメントに任意のフィールドを追加できます。 したがって、データモデルを変更する必要が生じた場合、唯一の十分なアクションは、アプリケーションコードの変更を反映することです。



たとえば、MongoDBのフィールドの名前を変更する場合：

BasicDBObject order = new BasicDBObject(); order.put(“date”, orderDate); //     order.put(“totalSum”, total); //     “sum”
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションロジックを変更すると、読み取り時にも新しいフィールドが必要になります。 しかし、データスキームがないため、totalSumフィールドは他の既存のOrderオブジェクトにはありません。 この状況では、さらにアクションを実行するための2つのオプションがあります。 1つ目は、すべてのドキュメントをバイパスし、既存のすべてのドキュメントでこのフィールドを更新することです。 データ量が多いため、このプロセスはロックなしで発生し（alter table rename columnコマンドに相当）、したがって、更新中に既存のデータを他のプロセスで読み取ることができます。 したがって、2番目のオプション（アプリケーションコードでの検証）は避けられません。

 BasicDBObject order = new BasicDBObject(); Double totalSum = order.getDouble(“sum”); //    if (totalSum == null) totalSum = order.getDouble(“totalSum”); //   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、再記録するとき、このフィールドを新しいフォーマットでデータベースに書き込みます。



スキーマがないことの良い結果は、スパースデータの効率です。 1つのドキュメントにdate_publishedフィールドがあり、2番目のドキュメントにない場合、空のdate_publishedフィールドは2番目に作成されません。 これは、原則として、論理的ですが、あまり明白ではない例です。つまり、テーブル/列というおなじみの概念を使用する列ファミリNoSQLデータベースです。 ただし、スキームがないため、列は宣言的に宣言されておらず、データベースとのユーザーセッション中に変更/追加できます。 これにより、特に動的列を使用してリストを実装できます。



非構造化スキームには欠点があります-データモデルを変更する際のアプリケーションコードの上記のオーバーヘッドに加えて、ベースからのあらゆる種類の制限（非ヌル、一意、チェック制約など）がなく、さらに構造の理解と制御にさらに困難があります異なるプロジェクトのデータベースとの並列作業中のデータ（データベース側に辞書はありません）。 ただし、急速に変化する現代の世界では、このような柔軟性は依然として利点です。 例としては、Twitterが5年前にツイートとともに追加情報（時間、Twitterハンドル、および数バイトのメタ情報）のみを保持していましたが、現在では、メッセージ自体に加えて、数キロバイトのメタデータがデータベースに保存されています。



（以下、主にキー値データベース、ドキュメントデータベース、列ファミリデータベースに関するものです。グラフデータベースにはこれらのプロパティがない場合があります）。



3.集計形式でのデータの表示。



正規化のためにアプリケーションの論理ビジネスエンティティをさまざまな物理テーブルに格納するリレーショナルモデルとは異なり、NoSQLストアは、統合オブジェクトと同様にこれらのエンティティで動作します。







この例では、eコマースの「概念-注文-注文-支払い-製品」の概念的なリレーショナルモデルの集計を示します。 どちらの場合も、注文は1つの論理オブジェクトの位置と組み合わされ、各位置には製品へのリンクとその属性の一部、たとえば名前が含まれます（注文の取得時に製品オブジェクトを要求しないように非正規化が必要です-分散システムの主なルールは最小ですオブジェクト間の「結合」。 1つのユニットでは、支払いは注文と結合され、オブジェクトの不可欠な部分です。別のユニットでは、支払いは別のオブジェクトに取り出されます。 これは、NoSQLデータベースのデータ構造を設計する主なルールを示しています。アプリケーションの要件に従って、最も一般的なクエリに対して可能な限り最適化する必要があります。 支払いが注文とともに定期的に取得される場合、それらを共通のオブジェクトに含めることは理にかなっています。多くのリクエストが支払いのみで機能する場合は、それらを別のエンティティに配置することをお勧めします。



クエリが集計の構造に収まらない場合、データに対して任意のクエリを試行すると、多くの場合、非正規化された大規模なオブジェクトでの作業には多くの問題が伴うことに注意してください。 注文と広告申込情報を一緒に使用して（これがアプリケーションの仕組みです）、ビジネスから先月販売された特定の製品のユニット数を計算するように求められたらどうなりますか？ この場合、OrderItemテーブルをスキャンする代わりに（リレーショナルモデルの場合）、NoSQLストレージで注文全体を取得する必要がありますが、この情報のほとんどは必要ありません。 残念ながら、これは分散システムで行う必要のある妥協です。従来の単一サーバーシステムのようにデータを正規化することはできません。異なるノードからのデータを結合する必要が生じ、データベースの速度が大幅に低下する可能性があるためです

私はタブレットで両方のアプローチの長所と短所をグループ化しようとしました：







4.弱いACIDプロパティ。



長い間、データの一貫性は建築家と開発者にとって「神聖な牛」でした。 すべてのリレーショナルデータベースは、このレベルまたはそのレベルの分離を提供しました-変更時のロックと読み取りのブロック、または取り消しログが原因です。 膨大な量の情報と分散システムの出現により、一方でトランザクションの操作セットを提供し、高可用性と高速応答時間を得ることは不可能であることが明らかになりました。 さらに、1つのレコードを更新しても、たとえばマスターノードで変更が発生する可能性があり、レプリカは他のユーザーが作業しているスレーブノードに非同期的にコピーされるため、他のユーザーがシステムの変更をすぐに見ることを保証しません。 この場合、一定期間後に結果が表示されます。 これは結果整合性と呼ばれ、FacebookやAmazonを含む世界中の主要なインターネット企業が現在行っていることです。 後者は、ユーザーが一貫性のないデータを見ることができる最大間隔が1秒以下であることを誇らしげに宣言しています。 このような状況の例を図に示します。







このような状況で生じる論理的な質問は、操作の原子性一貫性に高い要求を古典的に課し、同時に高速分散クラスター（金融、オンラインストアなど）を必要とするシステムに対して何をすべきかということです。 実践は、これらの要件が長い間無関係であることを示しています：これは、金融銀行システムの開発者の1人が言ったことです： あなたとあなたのパートナーが同時にお金を引き出し、限度を超えた場合はどうなりますか？ 「両方ともお金を受け取ります。後で修正します。」別の例は、写真に示されているホテルの予約です。 データの操作ポリシーに結果整合性が含まれるオンラインストアは、そのような状況（競合の自動解決、ロールバック操作、他のデータの更新）の場合に対策を講じる義務があります。 実際には、ホテルは不測の事態に備えて常に無料の部屋の「プール」を維持しようとしますが、これは物議を醸す状況の解決策になります。



実際、弱いACIDプロパティは、それらがまったく存在しないという意味ではありません。 ほとんどの場合、リレーショナルデータベースで動作するアプリケーションはトランザクションを使用して、論理的に関連するオブジェクト（オーダー-オーダーアイテム）を変更します。これらは異なるテーブルであるため必要です。 NoSQLデータベースのデータモデルを正しく設計すると（単位は注文項目のリストを伴う注文です）、1つのレコードを変更するときにリレーショナルデータベースと同じレベルの分離を達成できます。



5.共有リソースのない分散システム（何も共有しない）。



繰り返しますが、これはデータベースグラフには当てはまりません。データベースグラフの構造は、定義上、リモートノード間で十分に分散されていません。



これはおそらく、NoSQLデータベース開発の主要な主要なモチーフです。 雪崩のような世界の情報の増加と合理的な時間内に情報を処理する必要性により、垂直スケーラビリティの問題が生じました-プロセッサ速度の成長は3.5 GHzで止まり、ディスクからの読み取り速度も静かなペースで成長し、さらに強力なサーバーの価格は常にいくつかのシンプルなサーバーの合計価格よりも高くなっています。 この状況では、従来のリレーショナルデータベースは、ディスクのアレイ上にクラスター化されていても、速度、スケーラビリティ、帯域幅の問題を解決できません。 状況から抜け出す唯一の方法は、複数の独立したサーバーが高速ネットワークで接続され、それぞれがデータの一部のみおよび/または更新更新要求の一部のみを所有/処理する水平スケーリングです。 このようなアーキテクチャでは、ストレージの容量（容量、応答時間、帯域幅）を増やすために、クラスターに新しいサーバーを追加するだけで済みます-それだけです。 シャーディング、レプリケーション、フォールトトレランスの手順（1つまたは複数のサーバーが応答しなくなっても結果が得られます）、NoSQLデータベースはノードを追加する場合にデータの再配布を行います。 分散NoSQLデータベースの主なプロパティを簡単に紹介します。



レプリケーション -アップグレード中に他のノードにデータをコピーします。 これにより、拡張性が向上し、データの可用性とセキュリティが向上します。 次の2つのタイプに細分することもできます。

マスタースレーブ ：







およびピアツーピア ：







最初のタイプは、読み取り（ノードから発生する可能性があります）に対して優れたスケーラビリティを想定していますが、スケーラブルでない書き込み（マスターノードに対してのみ）を想定しています。 また、一定の可用性を確保することには微妙な点があります（手動または自動でウィザードが失敗した場合、残りのノードの1つがその場所に割り当てられます）。 2番目のタイプのレプリケーションでは、すべてのノードが等しく、読み取り要求と書き込み要求の両方を処理できると想定されています。



シャーディング -ノードによるデータ分離：







シャーディングは、多くの場合、速度とスループットを向上させるためにリレーショナルデータベースの「松葉杖」として使用されました。ユーザーアプリケーションは複数の独立したデータベースでデータを分割し、対応するデータを要求すると、ユーザーは特定のデータベースを使用しました。 NoSQLデータベースでは、レプリケーションなどのシャーディングはデータベース自体によって自動的に行われ、ユーザーアプリケーションはこれらの複雑なメカニズムから分離されています。



6. NoSQLデータベースはほとんどがオープンソースであり、21世紀に作成されました。



サダラジとファウラーがオブジェクトデータベースをNoSQLとして分類しなかったのは2番目です（ http://nosql-database.org/は一般的なリストに含まれていますが）。90年代に作成され、あまり人気がなかったためです。 。



さらに、NoSQLデータベースの分類について詳しく説明したかったのですが、もし読者が興味を持つのであれば、おそらく次の記事でこれを行います。

まとめ

NoSQLの動きは急速に人気を集めています。 ただし、これはリレーショナルデータベースが初歩的なものや古風なものになっているという意味ではありません。 ほとんどの場合、それらは以前と同じように使用および使用されますが、NoSQLデータベースはそれらと共生してますます機能します。 さまざまなニーズに応じてさまざまなデータウェアハウスが使用される時代である、ポリグロットの永続化の時代を迎えています。 現在、非代替データソースとしてのリレーショナルデータベースの独占はありません。 建築家は、データ自体の性質と、データの操作方法、予想される情報量に基づいてリポジトリを選択することが増えています。 したがって、すべてがより面白くなります。