JSON は、多くのアプリケーションや技術スタックで広く使用されているデータ交換形式です。JSON のバイナリ表現である BSON は、効率的なストレージとデータ走査のために、主に MongoDB 内部で使用されます。
目次
- JavaScript Object Notation とは何ですか？
- MongoDB と JSON の接続
- Binary JSON ドキュメント
- MongoDB では BSON と JSON のどちらを使用しますか？
- JSON と BSON の比較
- スキーマの柔軟性とデータガバナンス
- よくある質問
JavaScript Object Notation とは何ですか？
JSON（JavaScript Object Notation）は、2000年代初頭に導入された、人間が読めるデータ交換用の形式です。JSON は JavaScript プログラミング言語標準のサブセットに基づいていますが、完全に言語に依存しません。
JSON オブジェクトは、文字列キーが値 （数値、文字列、ブール値、配列、空の値 — null、または別のオブジェクトを指定できます）にマップされる連想コンテナです。ほぼすべてのプログラミング言語でこの抽象データ構造がサポートされています。たとえば、JavaScript のオブジェクト、Python のディクショナリ、Java と C# のハッシュテーブル、C++ の連想配列などがあります。
JSON データはどのようなものですか？
JSON オブジェクトは人間が読める形式で構成されており、アプリケーションにとっても読みやすい形式です。
JSON ファイルは、カンマで区切られたキーと値のペアで構成され、キーと値のペアはコロン（:）で示されることに注意してください。JSON オブジェクト（ドキュメント）は中括弧で始まり、中括弧で終わります。サポートされている任意のデータ型を使用できます。上の例では、文字列（二重引用符で囲まれたもの）、数値、配列（角括弧内のもの）を示しています。
JavaScript が Web 開発の主要な言語になるにつれて、JSON はそれ自体の存在感を高め始めました。人間と機械の両方が読みやすく、他の言語でのサポートを実装するのが比較的簡単だったため、JSON は Web ページを超えてあらゆるソフトウェアへと急速に広がりました。
現在、JSONはさまざまなケースで使用されています：
- API
- 構成ファイル
- ログ メッセージ
- データベースストレージ
MongoDB と JSON の接続
MongoDB は当初から、優れた開発者エクスペリエンスを提供することに重点を置いたデータベースとして設計されていました。JSON の普及により、MongoDB のドキュメントデータモデルでデータ構造を表すための明白な選択肢となりました。
開発者はエンドツーエンドで単一のプログラミング言語（JavaScript）を使用できるため、MEAN や MERN のような技術スタックを使用すると、アプリケーションをより簡単にビルドできます。
ただし、JSON をデータベース内で使用する際に理想的とは言えない問題がいくつかあります。
- JSON では、基本的なデータ型のうち限られた数のみがサポートされています。特に、JSON では日時とバイナリデータがサポートされていません。
- JSON オブジェクトとプロパティには固定の長さがないため、トラバースが遅くなります。
- JSON はメタデータと型の情報を提供しないため、ドキュメントの抽出に時間がかかります。
MongoDB を JSON ファーストにしながらも、高性能で汎用的に保つために、BSON が発明されてギャップを埋めることになりました。これは、速度、領域、効率に合わせて最適化された、データを JSON ドキュメントとして保存するためのバイナリ表現です。これは、アプローチの観点から、Protocol Buffers や Thrift などの他のバイナリ交換形式とそれほど変わりません。
Binary JSON ドキュメント
BSON は「Binary JSON」の略であり、まさにそれが発明された目的です。BSON ファイルは、対応する JSON ファイルのバイナリ表現です。BSON のバイナリエンコードされた直列化形式は、型と長さの情報もエンコードするため、JSON と比較してはるかに迅速にトラバースできます。
BSON には日付やバイナリデータなど、JSON ネイティブではない追加のデータ型が含まれており、これらがなければ MongoDB には貴重なサポートがいくつか欠けていたでしょう。
BSON ファイル
以下に、JSON オブジェクトの例とそれに対応する Binary JSON 表現をいくつか示します。
BSON 文法の詳細については、BSON の仕様を参照してください。
MongoDB では BSON と JSON のどちらを使用しますか？
MongoDB は、内部とネットワーク経由の両方で、BSON 形式でデータを保存します。JSON で表現できるものはすべて MongoDB にネイティブに保存でき、同じように簡単に JSON で抽出できます。
お気に入りのプログラミング言語で MongoDB ドライバーを使用する場合、その言語のネイティブデータ構造を操作します。アプリケーションは、ネイティブ データ構造（例: JavaScript オブジェクトまたは POJO）を JSON に変換する必要があります。MongoDB ドライバーは、データベースにクエリを実行する際に、データを JSON から BSON に、そしてその逆に変換する処理を担います。
JSON を文字列エンコードされた値やバイナリエンコードされた BLOB として保存するシステムとは異なり、MongoDB は BSON を使用して、Web で最も人気のあるデータ形式で強力なインデックス作成機能とクエリ機能を提供します。
たとえば、MongoDB では、開発者は、JSON/BSON ドキュメント内の特定のキーによってオブジェクトをクエリおよび操作できます。これには、レコード内の深いレイヤーにネストされたドキュメントも含まれ、同じキーと値に対して高性能のインデックスを作成できます。
まず、BSON ファイルには、純粋な JSON ではネイティブに表現できない日時オブジェクトまたはバイナリオブジェクトが含まれている場合があります。
次に、各プログラミング言語には独自のオブジェクトセマンティクスがあります。JSON オブジェクトには順序付けられたキーがありますが、Python 辞書（JavaScript オブジェクトに似た最も近いネイティブデータ構造）には順序がありません。また、数値や文字列のデータ型の違いも影響する可能性があります。第三に、BSON は JSON にネイティブでないさまざまな数値型をサポートしており、多くの言語でそれぞれ異なる表現方法があります。
EJSON
EJSON または 拡張 JSON は、MongoDB で BSON 値を表すための JSON 互換の方法です。JSON は BSON でサポートされている型のサブセットのみをサポートしているため、MongoDB は JSON 形式に、標準モードと緩和モードという特定の拡張機能を追加します。MongoDB は、EJSON の直列化、逆シリアル化、解析、および文字列化のようなメソッドを提供します。
JSON を解析する
アプリケーションがシェル、API、または MongoDB Atlas を使用して MongoDB にデータを書き込んだり、データを更新したりすると、MongoDB ドライバーによってデータが BSON 形式に解析されます。構文解析では、JavaScript オブジェクトまたは JSON 構造の特定と解釈、各フィールドの適切な BSON データ型へのマッピング、値の変換が行われます。アプリケーションが MongoDB にデータを要求すると、ドライバーはデータを JSON string に変換してからサーバー経由で送信します。
使用している言語で MongoDB の BSON ベースのデータに最適にアクセスする方法を理解するには、ドライバーのドキュメントを確認してください。
JSON と BSON の比較
JSON と BSON は、設計上、非常に近い親戚です。BSON は、より幅広いアプリケーション向けの特定の拡張機能を備えた JSON データのバイナリ表現として設計されており、データのストレージと走査に最適化されています。JSON と同様に、BSON はオブジェクトと配列の埋め込みをサポートしています。
BSON が JSON と異なる特定の点の 1 つは、より高度なデータ型をいくつかサポートしていることです。たとえば、JSON では、整数（四捨五入された数）と浮動小数点数（さまざまな程度の小数精度を持つ数）が区別されません。
ほとんどのサーバーサイドプログラミング言語には、より洗練された数値型が用意されています（標準的なものには、整数、単精度浮動小数点数（通称「float」）、倍精度浮動小数点数（通称「double」）、およびブール値などがあります）。それぞれに、効率的な演算を行うための最適な用途があります。
スキーマの柔軟性とデータガバナンス
開発者が JSON や BSON データモデルと共にデータベースを利用する大きな魅力の一つは、リレーショナルデータベースが使う硬直的で表形式のデータモデルと比べて、動的で柔軟なスキーマを提供することです。
まず、MongoDB ドキュメントはポリモーフィックです。フィールドは、単一のコレクション内でドキュメントごとに異なる場合があります（リレーショナルデータベースのテーブルに類似）。この柔軟性により、あらゆる構造のデータを容易にモデル化でき、要件の変化に応じてモデルを適応させることが可能になります。
次に、ドキュメントは自己記述型であるため、ドキュメントの構造をデータベースに宣言する必要はありません。開発者はコードの記述を開始し、オブジェクトが生成された時点で永続化できます。
第三に、新しいフィールドをドキュメントに追加する必要がある場合、コレクション内の他のすべてのドキュメントに影響を与えず、中央システムカタログを更新せず、データベースをオフラインにすることなく作成できます。データモデルを変更する必要がある場合、ドキュメントデータベースでは、コストのかかる ALTER TABLE 操作を実行したり、さらに悪いことにスキーマを一から再設計したりする必要なく、アップデートされたオブジェクトを保存し続けます。
これらの利点により、ドキュメントデータモデルの柔軟性は、現代のアプリケーション開発の実践における要求に非常に適しています。
柔軟なスキーマは強力な機能ですが、ドキュメントのデータ構造と内容をより詳細に制御したい場合もあります。ほとんどのドキュメントデータベースでは、これらの制御の適用を、アプリケーションコードで実装する開発者に委ねています。ただし、より高度なドキュメントデータベースでは、MongoDB が採用している IETF JSON Schema 標準などのアプローチを使用して、スキーマバリデーションを提供しています。
詳細については関連リソースをご覧ください。