SQLまたはNoSQL-それが問題です

データベーステクノロジの世界には、SQLとNoSQL、リレーショナルデータベースと非リレーショナルデータベースという2つの主要な領域があることは誰もが知っています。 それらの違いは、それらの設計方法、サポートするデータの種類、情報の保存方法です。



リレーショナルデータベースには、通常、実際のオブジェクトを表す構造化データが格納されます。 たとえば、これは、人に関する情報、またはストア内の商品のバスケットの内容に関する情報であり、表はグループ化されており、その形式は倉庫の設計段階で設定されています。



非リレーショナルデータベースの構造は異なります。 たとえば、ドキュメント指向のデータベースは、情報を階層データ構造の形式で保存します。 任意の属性セットを持つオブジェクトについて話すことができます。 リレーショナルデータベースがいくつかの相互に関連するテーブルに分割されるという事実は、非リレーショナルデータベースに不可欠なエンティティとして格納できます。



さまざまなデータベース管理システムの内部構造は、それらを操作する機能に影響します。 たとえば、非リレーショナルデータベースの方がスケーラブルです。







選択するテクノロジー この質問に対する答えは、問題のプロジェクトの機能によって異なります。

SQLデータベースの選択について

すべての人に適したデータベースはありません。 そのため、多くの企業がリレーショナルデータベースと非リレーショナルデータベースの両方を使用してさまざまな問題を解決しています。 NoSQLデータベースは速度とスケーラビリティのために人気がありますが、状況によっては構造化されたSQLリポジトリが望ましい場合があります。 SQLデータベースを選択する理由として役立つ2つの理由を次に示します。

1. ACID要件（原子性、一貫性、分離、耐久性-原子性、一貫性、分離、耐久性）を満たすデータベースの必要性。 これにより、予期しないシステム動作の可能性が減り、データベースの整合性が確保されます。 これは、トランザクションがデータベースとどのようにやり取りするかを厳密に決定することにより実現されます。 これは、100％のデータ整合性ではなく、柔軟性と速度に重点を置いたNoSQLデータベースで使用されるアプローチとは異なります。
   
   
   
   
2. 使用するデータは構造化されており、構造は頻繁に変更されることはありません。 組織が指数関数的な成長段階にない場合、データベースを使用してデータ型を自由に操作でき、膨大な量の情報の処理を目的とする説得力のある理由はおそらくないでしょう。
   
   

NoSQLデータベースの選択について

データベースが大量の情報の処理に基づいてプロジェクトのボトルネックになる可能性があるという疑いがある場合は、リレーショナルデータベースが方法を知らないことを可能にするNoSQLデータベースの方向を調べる価値があります。



MongoDB、CouchDB、Cassandra、HBaseなどのNoSQLデータベースの人気の理由となった機能は次のとおりです。

1. 大量の非構造化情報のストレージ。 NoSQLデータベースは、保存されたデータのタイプに制限を課しません。 さらに、必要に応じて、プロセスで新しいデータ型を追加できます。
   
   
   
   
2. クラウドコンピューティングとストレージを使用します。 クラウドストレージは優れたソリューションですが、スケーラビリティのためにデータを複数のサーバーに簡単に分散する必要があります。 テストと開発のためにローカル機器を使用し、システムをクラウドに移動して動作させることは、まさにNoSQLデータベースの作成目的です。
   
   
   
   
3. 迅速な開発。 アジャイルメソッドを使用してシステムを開発している場合、リレーショナルデータベースを使用すると作業が遅くなる可能性があります。 NoSQLデータベースは、リレーショナルデータベースに通常必要な量の準備アクションを必要としません。
   
   

次のセクションでは、SQLとNoSQLの違いのいくつかを見ていきます。 つまり、最初にデータベースを編成する2つのアプローチの基本的な違いを示す簡単な例を見てから、データのスケーラビリティとインデックス作成について説明します。 最後に、高性能のデータウェアハウスを必要とする大規模なCRMシステムの例を詳しく見てみましょう。

SQLおよびNoSQL

リレーショナルデータベースと非リレーショナルデータベースの重要な概念から始めましょう。 以下は、人々の関係のデータベースです。 バリアントaは、NoSQLソリューションに特有のグラフの形式で構築された、ダイアグラムのない構造です。 オプションbは、SQLに典型的な構造化形式で同じデータをどのように表現できるかを示しています。



データを提示するための2つのオプション



スキームレスとは、NoSQLデータ構造内の2つのドキュメントが同じフィールドを持つ必要がなく、異なるタイプのデータを格納できることを意味します。 これは、たとえば、フィールドのセットが一致しないオブジェクトの配列です。

var cars = [ { Model: "BMW", Color: "Red", Manufactured: 2016 }, { Model: "Mercedes", Type: "Coupe", Color: "Black", Manufactured: "1-1-2017" } ];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リレーショナルアプローチでは、データを事前に設計された構造に格納し、そこからこのデータを取得する必要があります。 たとえば、2つのテーブルからフェッチするときにJOIN



演算子を使用します。

 SELECT Orders.OrderID, Customers.Name, Orders.Date FROM Orders INNER JOIN Customers ON Orders.CustID = Customers.CustID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より高度な例として、SQLがNoSQLよりも望ましい場合を示すために、NoSQLデータベースに圧縮アルゴリズムを適用する機能を検討します。 問題は、一部のNoSQLデータベース（CouchDBやHBaseなど）では、いわゆるsstables



キーでソートされたキー値形式の文字列テーブルを常に作成する必要があることです。 ディスクに保存されるそのようなテーブルでは、データがいっぱいになったときや他の状況でメモリに格納されたテーブルからデータが落ちます。 データベースとの集中的な作業により、時間の経過とともにテーブルを作成すると、データストレージデバイスの入力/出力サブシステムがデータ読み取り操作のボトルネックになるという事実につながります。 その結果、NoSQLデータベースの読み取りは書き込みよりも遅くなり、非リレーショナルデータベースの主な利点の1つが無効になります。 NoSQLシステムがバックグラウンドでデータ圧縮アルゴリズムを使用し、多くのテーブルを1つに結合しようとするのは、この影響を軽減するためです。 しかし、この操作自体は非常に多くのリソースを消費し、システムは増加した負荷の下で動作します。

拡張性

検討中のテクノロジー間の主な違いの1つは、NoSQLデータベースのスケーラビリティが向上していることです。 たとえば、MongoDBには、スケーラビリティのためのレプリケーションとシャーディング（水平データ共有）の組み込みサポートがあります。 SQLデータベースではスケーリングがサポートされていますが、より多くの人的リソースとハードウェアリソースが必要です。

データウェアハウスタイプ	ユースケース	例	推奨事項
キーバリューストレージ	オブジェクトの検索が1つの属性のみで実行される状況で、1つのタイプのオブジェクトを使用する単純なアプリケーションに適しています。	Facebookでユーザーのホームページを対話的に更新します。	memcachedテクノロジーに精通していることをお勧めします。 複数の属性でオブジェクトを検索する必要がある場合は、ドキュメント指向のリポジトリへの移行を検討してください。
ドキュメント指向ストレージ	さまざまなタイプのオブジェクトの保存に適しています。	運転者と車に関するデータを操作するトランスポートアプリケーション。これと連携して、運転者の名前や生年月日、免許番号、所有する車両など、さまざまなフィールドのオブジェクトを検索する必要があります。	限られた原子性と分離性を備えた「最終分析の一貫性」の原則の実装が許可される作業中のアプリケーションに適しています。 タイムリーなアトミック一貫性を確保するために、クォーラム読み取りメカニズムをお勧めします。
拡張可能なレコードストレージ	ドキュメント中心のストレージよりも若干複雑ですが、スループットが高く、並列処理が向上します。	eBayに類似したアプリケーション。 顧客情報を保存するためのデータの垂直および水平の分離。	データの分離を簡素化するために、HBaseまたはHypertableが使用されます。
スケーラブルなRDBMS	ACIDセマンティクスを使用すると、プログラマはかなり低いレベルで作業する必要がなくなります。つまり、データのロックと一貫性を管理し、古いデータや衝突を処理する必要がなくなります。	複数のサイトにまたがる更新またはデータマージを必要としないアプリケーション。	MySQL Cluster、VoltDB、Clustrixなど、スケーリングの改善に焦点を当てたシステムに注意を払う価値があります。

この記事では、SQLとNoSQLのより詳細な比較を見つけることができます。 主なポイントは次のとおりです。 つまり、システムの3つの主要な特性がテストされました：並列データ処理、情報ストレージの操作、データ複製。 並列処理機能は、ロックメカニズム、マルチバージョン管理に基づく同時アクセス制御、およびACIDを分析することにより評価されました。 ストレージテストは、物理メディアとRAMを使用したスト​​レージの両方を対象としました。 レプリケーションは、同期モードと非同期モードでテストされました。



著者は、テスト中に取得したデータを使用して、クラスタリングの可能性があるSQLデータベースがノードごとに有望なパフォーマンス結果を示し、さらに、スケーラビリティを備えているため、RDBMSシステムは完全なNoSQLに比べて有利です。 ACID原則への準拠。

索引付け

RDBMSシステムは、インデックス作成を使用して、データベースからのデータ取得を高速化します。 インデックスが存在しないということは、読み取り要求を満たすためにテーブル全体をスキャンする必要があることを意味します。



SQLデータベースとNoSQLデータベースの両方で、インデックスは同じ目的、つまりデータ抽出の高速化と最適化を果たします。 ただし、データベースアーキテクチャやデータベースに情報を保存する特性により、動作方法は異なります。 SQLインデックスは、リレーショナルデータの階層構造を反映するBツリーとして表されますが、NoSQLデータベースでは、基本的に関係のないドキュメントまたはドキュメントの一部を指します。 このトピックに関する詳細な資料を以下に示します。

CRMシステム

CRMアプリケーションは、毎日処理される膨大な量のデータと非常に多くのトランザクションを特徴とするシステムの最良の例の1つです。 このようなアプリケーションの開発者はすべて、SQLデータベースとNoSQLデータベースの両方を使用します。 また、トランザクションデータの大部分は依然としてSQLデータベースに格納されていますが、AWS DynamoDBやAzure DocumentDBなどの公的に利用可能なDBaaSクラスのシステム（サービスとしてのデータベース、サービスとしてのデータベース）が使用されているため、深刻な負荷がかかっていますデータ処理はクラウドNoSQLデータベースに転送できます。



このようなサービスを使用すると、開発者はストレージメンテナンスタスクを解決できなくなりますが、これは、たとえばデータマイニングなどのために主に作成されたものにNoSQLデータベースが使用される領域でもあります。 金融会社や通信会社の巨大なCRMシステムに保存されている情報量は、SASやRなどのツールを使用して分析することは事実上不可能です。これには膨大なハードウェアリソースが必要になります。



このようなシステムの主な利点は、ドキュメントと同様の非構造化データの使用です。 このようなデータは、企業がさまざまなタイプの分析を実行できるようにする統計モデルの入力に入力できます。 さらに、CRMアプリケーションは、2つのデータベースシステムが競合他社ではなく、調和して存在し、大規模なデータ管理アーキテクチャでそれぞれの役割を果たしている非常に良い例です。

まとめ

データベース管理システムを検索する場合、1つのテクノロジーを選択し、後で要件を指定して別のテクノロジーに切り替えることができます。 ただし、スマートな計画を立てると、時間と費用を大幅に節約できます。



SQLデータベースが理想的なプロジェクトの兆候は次のとおりです。

• 事前定義可能な論理データ要件があります。
• データの整合性は非常に重要です。
• 実績のある標準に基づいた技術が必要であり、それを使用して開発者の豊富な経験と技術サポートに頼ることができます。

そして、NoSQLのスコープからの何かが適しているプロジェクトのプロパティは次のとおりです。

• データ要件はあいまいであるか、曖昧であるか、プロジェクトの開発とともに開発されています。
• プロジェクトの目的は時間とともに調整できますが、開発をすぐに開始できることが重要です。
• データベースの基本的な要件の1つは、データ処理速度とスケーラビリティです。

最後に、現代の世界では、リレーショナルデータベースと非リレーショナルデータベースの間に対立はありません。 代わりに、特定のテクノロジーが最高のパフォーマンスを発揮する問題を解決するための共同使用について話す価値があります。 さらに、これらのテクノロジーの相互への統合がますます観察されています。 たとえば、Microsoft、Oracle、およびTeradataは、SQLベースの分析ツールを非構造化ビッグデータの世界に接続するための何らかの形式のHadoop統合を提供しています。



親愛なる読者、あなたはあなた自身のプロジェクトのためにデータベース管理システムを選ばなければなりませんでしたか？ もしそうなら、あなたの経験を共有し、あなたが最終的に選択したものと理由を教えてください。