Postgres NoSQLはMongoDBよりも優れていますか？

一般に、リレーショナルデータベース管理システムは、何十年もの間、「データを保存および受信するための万能ソリューション」として考えられてきました。 しかし、スケーラビリティと新しいアプリケーション要件に対するニーズの高まりにより、多くのスケーラブルなアプリケーションにおける万能型アプローチへの不満など、従来のRDBMS管理システムに新たな課題が生じています。



これに対する答えは、リレーショナルデータベースの優位性に挑戦するために設計された、軽量で高性能なデータベースの新世代でした。



NoSQLの動きの大きな理由は、Web、エンタープライズ、クラウドアプリケーションの実装が異なるとデータベースの要件も異なるという事実でした。



例：eBay、Amazon、Twitter、Facebookなどの大型サイトの場合、スケーラビリティと高可用性は妥協できない重要な要件です。 これらのアプリケーションでは、わずかな切断でも経済的に大きな影響があり、顧客の信頼に影響を与える可能性があります。



したがって、既製のデータベースソリューションでは、トランザクションの整合性の問題だけでなく、データ量の増加、データの速度とパフォーマンスの向上、さまざまな形式の増加を解決する必要があります。 上記の1つまたは2つの側面の最適化に特化し、他の側面を犠牲にする新しい技術が登場しました。 JSONを使用したPostgresは、ユーザーのニーズに対してより包括的なアプローチを取り、ほとんどのNoSQLワークロードを正常に解決します。

ドキュメント指向/リレーショナルデータベースの比較

新しいテクノロジーのスマートなアプローチは、ニーズを綿密に評価し、それらのニーズを満たすために利用できるツールに依存しています。 以下の表は、非リレーショナルドキュメント指向データベース（MongoDBなど）の特性とPostgresリレーショナル/ドキュメント指向データベースの特性を比較して、ニーズに合った適切なソリューションを見つけるのに役立ちます。

特徴	モンゴッド	PostgreSQL
オープンソース開発の開始	2009	1995
スキーム	ダイナミック	静的および動的
階層データのサポート	はい	はい（2012年以降）
キーイベントデータのサポート	はい	はい（2006年以降）
リレーショナルデータ/正規化されたフォームストレージのサポート	いや	はい
データの制限	いや	はい
データフェデレーションと外部キー	いや	はい
強力なクエリ言語	いや	はい
複数バージョンのトランザクションサポートと競合アクセス管理	いや	はい
アトミックトランザクション	ドキュメント内	ベース全体
サポートされているWeb開発言語	JavaScript、Python、Rubyなど	JavaScript、Python、Rubyなど
一般的なデータ形式のサポート	JSON（ドキュメント）、Key-Value、XML	JSON（ドキュメント）、Key-Value、XML
空間データのサポート	はい	はい
スケーリングする最も簡単な方法	水平スケーリング	垂直スケーリング
シャーディング	シンプル	難しい
サーバー側のプログラミング	いや	Python、JavaScript、C、C ++、Tcl、Perlなどの多くの手続き型言語、その他多数
他のデータソースと簡単に統合	いや	Oracle、MySQL、MongoDB、CouchDB、Redis、Neo4j、Twitter、LDAP、File、Hadoopなどの外部データコレクター...
ビジネスロジック	クライアントアプリケーションによって配布	トリガーとストアドプロシージャで一元化、またはクライアントアプリケーション全体に分散
学習リソースの可用性	見つけにくい	見つけやすい
主な用途	データの整合性と一貫性が要求されない、大量の同時更新を伴うビッグデータ（数十億レコード）。	トランザクションおよび運用アプリケーション。その利点は、正規化された形式、関連付け、データ制限、およびトランザクションサポートです。

出典：EnterpriseDB Webサイト。



MongoDBのドキュメントには、 _idフィールドが存在しない場合、自動的に提供されます。 このドキュメントを取得する場合は、 _idを使用できます。これは、リレーショナルデータベースの主キーとまったく同じように動作します。 PostgreSQLはデータをテーブルフィールドに格納し、MongoDBはデータをJSONドキュメントの形式で格納します。 一方では、MongoDBは優れたソリューションのように見えます。なぜなら、1つのJSONドキュメントでPostgreSQLの複数のテーブルからすべての異なるデータを取得できるからです。 この柔軟性は、データ構造に制限がないことによって実現されます。これは、最初は非常に魅力的であり、一部のレコードに誤った値または空のフィールドがある大きなデータベースでは本当に恐ろしい場合があります。



PostgreSQL 9.3には、完全なトランザクションサポートとデータフィールドに制限のあるJSONドキュメントのストレージを備えた、NoSQLデータベースに変換できる優れた機能が備わっています。

簡単な例

Employeesテーブルの非常に単純な例を使用して、これを行う方法を示します。 各従業員には、名前、説明、特定のID番号、および給与があります。



PostgreSQLバージョン



PostgreSQLの単純なテーブルは次のようになります。

CREATE TABLE emp ( id SERIAL PRIMARY KEY, name TEXT, description TEXT, salary DECIMAL(10,2) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテーブルにより、次のような従業員を追加できます。

 INSERT INTO emp (name, description, salary) VALUES ('raju', ' HR', 25000.00);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、上記の表では、いくつかの重要な値なしで空の行を追加できます。

 INSERT INTO emp (name, description, salary) VALUES (null, -34, 'sdad');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、データベースに制限を追加することで回避できます。 負の給与ではなく、常に空ではない一意の名前、空ではない説明が必要だとします。 このような制約のあるテーブルは次のようになります。

 CREATE TABLE emp ( id SERIAL PRIMARY KEY, name TEXT UNIQUE NOT NULL, description TEXT NOT NULL, salary DECIMAL(10,2) NOT NULL, CHECK (length(name) > 0), CHECK (description IS NOT NULL AND length(description) > 0), CHECK (salary >= 0.0) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、これらの制限のいずれかに矛盾するレコードの追加や更新などのすべての操作がエラーで失敗します。 確認しましょう：

 INSERT INTO emp (name, description, salary) VALUES ('raju', 'HR', 25000.00); --INSERT 0 1 INSERT INTO emp (name, description, salary) VALUES ('raju', 'HR', -1); --ERROR: new row for relation "emp" violates check constraint "emp_salary_check" --DETAIL: Failing row contains (2, raju, HR, -1).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NoSQLバージョン



MongoDBでは、上の表のエントリは次のJSONドキュメントのようになります。

 { "id": 1, "name": "raju", "description": "HR, "salary": 25000.00 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様に、PostgreSQLでは、このレコードをempテーブルの行として保存できます。

 CREATE TABLE emp ( data TEXT );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ほとんどの非リレーショナルデータベースと同じように機能し、チェックも不良フィールドのエラーもありません。 その結果、必要に応じてデータを変換できます。給与が数字であるとアプリケーションが予期しているときに問題が始まりますが、実際には、それは行であるか、完全に欠落しています。



JSONを確認する



PostgreSQL 9.2には、これらの目的に適したデータ型があり、JSONと呼ばれます。 このタイプは正しいJSONのみを保存でき、このタイプに変換する前に検証チェックが実行されます。



テーブルの説明を次のように変更しましょう。

 CREATE TABLE emp ( data JSON );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテーブルにいくつかの有効なJSONを追加できます。

 INSERT INTO emp(data) VALUES('{ "id": 1, "name": "raju", "description": "HR", "salary": 25000.00 }'); --INSERT 0 1 SELECT * FROM emp; { + "id": 1, + "name": "raju", + "description": "HR",+ "salary": 25000.00 + } --(1 row)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは機能しますが、無効なJSONaの追加は失敗します。

 INSERT INTO emp(data) VALUES('{ "id": 1, "name": "raju", "description": "HR", "price": 25000.00, }'); --ERROR: invalid input syntax for type json
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

書式設定の問題は気づきにくい場合があります（最後の行にコンマを追加しましたが、JSONはそれを気に入らない）。



フィールドを確認する



したがって、最初の純粋なPostgreSQLソリューションのように見えるソリューションがあります。チェックされるデータがあります。 これは、データが意味をなすという意味ではありません。 データを検証するチェックを追加しましょう。 PostgreSQL 9.3には、JSONオブジェクトを管理するための新しい強力な機能があります。 JSONタイプには、フィールドと値に簡単にアクセスできる特定の演算子があります。 「 ->> 」演算子のみを使用しますが、詳細についてはPostgresのドキュメントを参照してください。



さらに、idフィールドを含むフィールドのタイプを確認する必要があります。 これは、データ型の定義により、Postgresが単純にチェックするものです。 チェックに別の構文を使用します。名前を付けたいからです。 巨大なJSONドキュメント全体ではなく、特定のフィールドで問題を検索する方がはるかに簡単です。



制限付きのテーブルは次のようになります。

 CREATE TABLE emp ( data JSON, CONSTRAINT validate_id CHECK ((data->>'id')::integer >= 1 AND (data->>'id') IS NOT NULL ), CONSTRAINT validate_name CHECK (length(data->>'name') > 0 AND (data->>'name') IS NOT NULL ) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

演算子「 ->> 」を使用すると、目的のJSONフィールドから値を取得して、存在するかどうかとその有効性を確認できます。



説明なしでJSONを追加しましょう。

 INSERT INTO emp(data) VALUES('{ "id": 1, "name": "", "salary": 1.0 }'); --ERROR: new row for relation "emp" violates check constraint "validate_name"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう1つ問題があります。 名前とIDフィールドは一意である必要があります。 これは次のように簡単に実現できます。

 CREATE UNIQUE INDEX ui_emp_id ON emp((data->>'id')); CREATE UNIQUE INDEX ui_emp_name ON emp((data->>'name'));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、IDがすでにデータベースにあるデータベースにJSONドキュメントを追加しようとすると、次のエラーが表示されます。

 --ERROR: duplicate key value violates unique constraint "ui_emp_id" --DETAIL: Key ((data ->> 'id'::text))=(1) already exists. --ERROR: current transaction is aborted, commands ignored until end of transaction block
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

性能



PostgreSQLは、今日の世界最大の保険会社、銀行、ブローカー、政府機関、および防衛請負業者の最も厳しい要求を処理し、長年にわたって管理しています。 PostgreSQLのパフォーマンスの改善は、バージョンの年次リリースでも継続的であり、非構造化データ型の改善も含まれています。











ソース：EnterpriseDBホワイトペーパー：Postgres NoSQL機能の使用



PostgreSQLでNoSQLのパフォーマンスを個人的にテストするには、GitHubからpg_nosql_benchmarkをダウンロードします。