パスタをスプーンで食べようとしたことはありますか?うまくいかないでしょう。フェットチーネやペンネをつかむところがなければ、至るところに滑り落ちてしまします。もう片方の手にフォークを持つ方が100万倍もましです。パスタを突き刺して、好きなだけ速く食べることができるでしょう。

ただし、ボールの底で最後のソースをすくう場合は、フォークは使えません。再びスプーンが必要になります。つまり、簡単な作業であるべきことに2つの道具が必要となるのです。

しかし、これは、一部の知識人気取りの人がスポークを発明されるまでのことです。突然、スプーンとフォークの役割をこなすものが現れたのです。それでは、なぜ私達は、すべての食事にスポークを使わないのでしょうか?なぜまだフォークとスプーンの両方が存在するのでしょうか?

つまり、これはまさに PostgreSQL 対 MongoDB の話や、JSON データに適したストレージの話になった時に、データ科学者の間でかわされる議論なのです。

かつて、 PostgreSQL 対 MongoDB についてはこのような議論がなされていました:「PostgreSQL を使えば SQL(後の NoSQL)を処理できるが、JSON は処理できない。しかし、元々 JSON データベースとして設計された、MongoDBなどの専用のデータベース管理システム(DBMS)もある。」

しかし現在、こうした厳密な区分けは、言うなれば、データスポークといった中間の選択肢の出現によってごちゃまぜになってきています。

SQL に根差したデータベースアーキテクチャであるPostgreSQLには、改善された JSON ストレージ機能が備わっています。それでは、両方のツールを維持することを選択してみてはどうでしょうか?

Sisense の専用ガイド分析のためのデータの準備の重要な6つの手順で、データ準備を行いましょう。

JSON と JSONB の台頭

その前に、この記事では何の話題を取り扱っているかを思い出しましょう。私達がそこまで一生懸命対応しようとしているこの JSON データフォマットとは何なのでしょうか?

JavaScript Object Notation(JSON)は、非構造化されており、柔軟で、私達人間にとって読みやすいものです。基本的にどんな方法でも、専用のデータベース言語(SQLなど)に適合させる必要なく、データベースにデータをダンプできます。データレコードでフィールドをネストさせたり、必要な時に個々のデータレコードに様々なフィールドを追加できます。

これらすべてが、JSON をユーザーフレンドリーなコンピューティングの重要な手段にしています。今日では、XML より JSON を好む人が多く、JSON データフォーマットは、多くの NoSQL データストアに使用されています。

しかし、JSON にはインデックス作成がないため、この問題を解決するために JSONB が作成されました。JSONB は、データをシンプルな JSON Blob ではなく、バイナリーフォーマットで保存します。データ入力は若干遅いですが、データを再パースする必要がないため、処理が格段に速くなります。

MongoDB とは?PostgreSQL とは?

何の話題を取り扱っているかはっきりしたので、次はこれら2つのよく使われているデータベースの違いを見てみましょう。

MongoDB は、オープンソースのデータベースです。迅速で、拡張できるよう設計されており、最初に構造を定義することなくレコードを作成できるよう、ダイナミックスキーマを使用しています。また、データの階層的文書にも対応しています。

PostgreSQLもオープンソースですが、データを自由に格納できることよりも、標準的な適合性や拡張性に着目したリレーショナルデータベースです。ダイナミックスキーマとスタティックスキーマの両方を使用しており、リレーショナルデータや正規形のストレージに使用できます。非構造化手法を採用している MongoDB ではできないことです。

それでは…JSON や JSONB データを格納するのにどちらを使用すべきでしょうか?

意図的な制約と付随的な制限

まずはっきりさせるべきは、PostgreSQL と MongoDB には、両方共JSON と JSONB データストレージの機能があるということです(MongoDB では JSONB を「BSON」と呼んでいます)。

しかし、次のような違いがあります:

  • MongoDB では、整数や浮動小数点数を表示するために、BSON フォーマットは最大64ビットに制限されています。PostgreSQL の JSONB フォーマットに制限はありません。
  • PostgreSQL では、データ制約や検証機能を提供しており、これは、JSON の文書をより有意義にするためのものです。例えば、数字のみが意味のある場合、英字の格納を停止します。
  • MongoDB では自動データベース共有が可能で、JSON データストレージの水平スケーリングを簡単になります。PostgreSQL のインストールスケーリングは通常垂直です。PostgreSQL を水平にスケーリングすることは可能ですが、これは手間がかかり、第三者の助けが必要になることが多くあります。
  • MongoDB でも、ディスクへの書き込みを遅らせることで、書き込みの処理能力を上げることができます。この方法では、一部のデータが失われてしまう可能性がありますが、自分のデータに固執することをあまり気にしていないユーザーにとってはよいかもしれません。

当然、大切なことは、PostgreSQL により、選択肢をオープンにできることです。JSON 列にデータをルーティングすることを選択でき、それによって、あとでモデル化するか、もしくは、すべてが同じ PostgreSQL データベース内にある、SQL スキーマテーブルに入れることができます。

つまり、スポークオプションとなるのでしょうか?実はあまり速くはありません。なぜなら…

必ずしも最高のパフォーマンスを
果たすわけではない JSON データストア

NoSQL データベース管理システムの最も優れた点の1つは、そのパフォーマンスです。

SQL データベースよりも簡単なデータ構造で機能するため、ストレージや収集は NoSQ Lデータベースシステムではより速くなる傾向にあります。

金融取引などに必要な ACID(原子性、一貫性、独立性、永続性)特性がない場合がありますが、大量の非構造化データを高速で処理するには適しています。

とは言え、PostgresSQL は、2014年に EnterpriseDB.com でのパフォーマンス格付けで、MongoDB より上回っていたことで衝撃を与えました。

まさにその通りです。信じられないことですが、5000万レコードまでの複雑な文書データの選択、読み込み、挿入に基づいたテストで、PostreSQL は、データ選択速度が約2倍、データ選択速度が2.5倍、データ挿入速度が3倍速く、使用ディスクスペースが25%減という結果でした。

公正な立場で言うならば、それ以降、MongoDB 3.0 は、困難にうまく対処し、データの圧縮により、ディスクスペースを50%削減しつつ、書き込み速度を7~10倍向上させる WiredTiger データベースエンジンを導入しました。

そのため、MongoDB は勢いを失うことなく、パフォーマンスに関する議論は以前のような単純なものではなくなりました。

動作中の Sisense:

Quality Assurance Project Status - Software Dashboard

ユースケースと PostgreSQL または MongoDB の選択に影響する要因

今度は何だ?とお考えかもしれません。最高の JSON データベースとして、PostgreSQL とMongoDB のどちらを選ぶなのでしょう?

答えは、何を達成したいか、そして現在何を実施しているかによります。正しい選択をするために、次の7つの質問を考えてみましょう:

  1. どんなアプリケーションを使用しているか?

    MongoDB は、アプリケーションを開発するのに必要なデータベース管理コマンドの数を制限しています。これは、アプリケーションによってビルドされたオンデマンドのクエリやコマンドの他、迅速なプロトタイピングには適している点があります。

    とは言え、アプリケーション自体が重要なデータを挿入する必要があり、ソフトウェアを維持するために多くの労力が必要になる場合もあります。

  2. 後々にどのくらいの構造が必要になるか?

    MongoDB は非構造化データにとっては理想的ですが、構造化および非構造化データの混合に今後移行する予定がある場合、もしくは ACID コンプライアンスが将来重要になると考えている場合は、PostgreSQL がベストかも知れません。

  3. スタティック JSON データを使用しているか?

    スタティック JSON データと SQL ストレージに対して構造化されているアクティブなデータを使用している場合、PostgreSQL の JSONB 表示は効率的で、インデックス作成ができるため、PostgreSQL が賢い選択だと言えます。しかし、MongoDB レポーティングで SQL クエリを実行するのに、ODBC や BI 統合を使用することもできます。

  4. JSON データを修正するのにいくら必要になるか?

    データストア内で JSON データを修正したい場合には、個々のフィールドを更新するツールが用意されている MongoDB の方が望ましいでしょう。

    一方で、PostgreSQL で JSON フィールドを修正するには、文書全体を正確に抽出し、変更を行う際に再度書き直す必要があります。

  5. ダイナミッククエリを行う必要があるか?

    MongoDB は、頻繁に読み書きされるデータのダイナミッククエリには最適です。これは、MongDB がオブジェクト間での複雑なトランザクションを必要とせずに、常に変化していくすべてのタイプのデータを処理するよう設計されているからです。様々なフィールドと共に文書に含まれている、ごく一部のフィールドでアドホッククエリを実行している場合でも、優れたパフォーマンスを得られるでしょう。

  6. 自動共有が必要か?

    MongoDB の自動共有機能は、標準化されたコモディティハードウェア(集中型アーキテクチャ)の複数のインスタンスを使用する IT 環境には適しています。

  7. 適切な人材を得ることができるか?

    PostgreSQL か MongoDB のいずれかに対して膨らんでいくコストは、(ホスティングプラットフォームの可用性と価格だけではなく)それを実行するための適切なスキルを持った開発者を容易に見つけることができるかに大きく関係しています!

    PostgreSQL は昔からあり、多くの Linux オペレーティングシステムに無料で提供されており、うまく確立されています。MongoDB のエキスパートを探すために努力することになるということではありません。MongoDB は、5番目に人気のあるデータベース技術です。

    社内にどのような人材がいるか、選択する際に他の誰が必要かを心に留めておいてください。

結論

わかっています。どちらを選ぶかを説明することで多くの時間や労力を提供してくれると期待していましたね?困ったことに、この記事で明らかになったように、実際、より複雑な話なのです。

決定を下すためには、データベースから必要とするものが何か、そして、重要なことですが、数年後に何が必要になるかをじっくり考えてください。ストレージの観点からだけでなく、データを使って何をしたいかの観点も必要です。

そう、もしすでに MongoDB または PostgreSQL のいずれかを使用している場合、軌道を変えることは、大きな頭痛のように感じるかもしれませんが、Sisense を信じてください。すぐに正しく活用したくなるでしょう。データが大きくなり、より複雑になるにつれ、方向転換もさらに困難になってしまうからです!

6 crucial steps of preparing data for analysis