IBM Cloudant の使用

IBM Cloudant も NoSQL データベース自体も使用したことがない場合は、詳しい内容を読む前に、この概要説明とベスト・プラクティスに目を通してください。ここでは、IBM Cloudant について知っておく必要がある最も重要な点と、最大限利用する方法について説明します。資料の残りの部分では、この基本が分かっていることが前提となっています。

IBM Cloudant についての詳細は以下のセクションに記載されています。

IBM Cloudant への接続

IBM Cloudant にアクセスするには、IBM Cloud® アカウントが必要です。

HTTP API

IBM Cloudant に対する要求はすべて、Web を介して行われます。つまり、Web と通信できるシステムはすべて IBM Cloudant と通信できます。 IBM Cloudant の言語別のライブラリーはすべて、シンプルな API で簡単に作業を行えるように、便利な機能や言語別の細かい機能を提供するラッパーに過ぎません。 IBM Cloudant で作業するために未加工の HTTP ライブラリーを使用しているユーザーも多数います。

IBM Cloudant の HTTP の使用方法について詳しくは、API リファレンスの『HTTP』を参照してください。

IBM Cloudant では、以下の HTTP 要求メソッドがサポートされます。

GET: 指定された項目を要求します。通常の HTTP 要求と同様に、URL のフォーマットにより、返す内容を定義します。 IBM Cloudant では、この定義に、静的項目、データベース文書、および構成と統計の情報を含むことができます。ほとんどの場合、情報は、JSON 文書の形式で返されます。
HEAD: HEAD メソッドは、応答の本体を含まない GET 要求の HTTP ヘッダーを取得します。
POST: データをアップロードします。 IBM Cloudant の API では、POST メソッドは、値の設定、文書のアップロード、文書値の設定、および一部の管理コマンドの開始を実行します。
PUT: 特定のリソースを「保管」するために使用します。 IBM Cloudant の API では、PUT は、データベース、文書、ビュー、設計文書などの新規オブジェクトを作成します。
DELETE: 文書、ビュー、設計文書などの指定されたリソースを削除します。
COPY: 文書とオブジェクトをコピーする特殊なメソッド。

クライアント (Web ブラウザーなど) で HTTP メソッドの使用がサポートされない場合は、代わりに POST 要求ヘッダーに実際の HTTP メソッドを設定して、X-HTTP-Method-Override を使用できます。

メソッドが許可されないエラー

サポートされない HTTP 要求タイプを、指定されたタイプをサポートしない URL で使用すると、 405 エラーが返されます。このエラーでは、以下の例のように、サポートされる HTTP メソッドがリストされます。

サポートされない要求に対するエラー・メッセージの例

{
    "error":"method_not_allowed",
    "reason":"Only GET,HEAD allowed"
}

JSON

IBM Cloudant は、JSON (JavaScript Object Notation) エンコードを使用して文書を保管するので、JSON でエンコードされたものはすべて文書として保管できます。画像、動画、音声などのメディアが含まれたファイルを BLOB (バイナリー・ラージ・オブジェクト) と呼びます。 BLOB は、文書に関連付けられた添付ファイルとして保管できます。

JSON について詳しくは、JSON ガイドを参照してください。

分散システム

IBM Cloudant の API を使用して、多数のマシンから成るコラボレーション (クラスター) と対話できます。クラスター内のマシンは、同じデータ・センター内に存在している必要がありますが、そのデータ・センター内の異なる「ポッド」内に配置されていても構いません。複数のポッドを使用すると、IBM Cloudant の高可用性特性が向上します。

クラスター化する利点は、コンピューティング能力の追加が必要になったらマシンを追加できるという点にあります。多くの場合、この方法は、既存の単一マシンをスケールアップしたり強化したりするよりも、費用対効果および耐障害性が高くなります。

IBM Cloudant と分散システムの概念について詳しくは、CAP 定理のガイドを参照してください。

複製する

複製は、 IBM Cloudantが後に続く手順です。 CouchDB、 PouchDB、およびその他の分散データベース。複製では、2 つのデータベースの状態を同期して、両者の内容が同一になるようにします。

連続的に複製できます。連続的な複製は、ソース・データベースが変更されるたびに、ターゲット・データベースも更新されることを意味します。連続複製は、データのバックアップ、多数のデータベースのデータの集約、あるいはデータの共有に使用できます。

ただし、連続複製を行うということは、ソース・データベースの変更がないかを連続的に検査するということを意味します。この検査には、連続的な内部呼び出しが必要になるため、パフォーマンスやデータベース使用のコストに影響する可能性があります。

連続複製を行うと、多くの内部呼び出しが行われる可能性があります。これらの呼び出しは、IBM Cloudant システムのマルチテナント・ユーザーのコストに影響を与える場合があります。デフォルトでは、連続複製は無効になっています。

ジョブに適したツールの使用

IBM Cloudant は、スケーラビリティー、耐久性、高可用性、運用性を備え、HTTP API を持つ JSON 文書ストアです。これは、以下の目的に適しています。

常時利用可能な Web アプリケーションを駆動する。
モバイル・アプリケーション用のサーバー・サイド・データ・ストアにする。
期間を設定したデータベースに時系列データを保管し、その後、オブジェクト・ストレージにアーカイブして元のデータベースを削除する。
2 次索引から照会が届いたときに、アプリケーション・オブジェクトを JSON として保管する。
災害復旧や追加容量のために地域間でデータ・セットを複製する、またはユーザーの近くにデータを移動する。

以下の機能は、IBM Cloudant に含まれません。

低遅延のメモリー内データ・ストア。詳しくは、IBM Cloud® Databases for Redis を参照してください。
データをアーカイブするための無制限のオブジェクト・ストア。詳しくは、IBM Cloud Object Storage を参照してください。
SQL 照会、ストアード・プロシージャー、および制約とトリガーを備えたリレーショナル・データベース。詳しくは、IBM Cloud Databases for PostgreSQL を参照してください。
随時照会のためのデータウェアハウス。詳しくは、 IBM® Db2® Warehouse as a Serviceを参照してください。
キュー。詳しくは、IBM MQ を参照してください。

詳しくは、Best and worst practice のブログを参照してください。

文書およびデータベースの編成

IBM Cloudant データは、データベースと文書の階層に編成されます。文書は、固有 ID _id を持つ JSON オブジェクトです。データベースは、文書のコレクションと、_id で文書を検索するための 1 次索引で構成されます。オプションで、オブジェクトの他の属性で文書を照会するための 2 次索引も作成することができます。

開発者がプロジェクトを開始する際によく悩むのが以下の問題です。

単一のオブジェクトにどの程度のデータを入れることができるのか?
必ず、異なる文書タイプを同一コレクションに保管するのか、あるいは、文書タイプごとに 1 つのデータベースにするのか?

アプリケーションでモデル化したオブジェクトに関するすべてのデータ (例えば、ユーザー、オーダー、製品など) を文書に含めることが重要です。この方法により、1 回の API 呼び出しでデータベースからオブジェクト全体を取り出すことができます。 IBM Cloudant には、リレーショナル・データベースのような結合の概念がないため、データは 正規化ではありません。ただし、データはオブジェクト間で反復することができます。例えば、オーダー の文書に、購入された製品の文書のサブセットを含めることができます。

複数のオブジェクト・タイプを同一データベースに保管するのが一般的です。また慣例では、type 属性を使用して、オブジェクト・タイプを示します。このオプションは、複数のオブジェクト・タイプを返す照会を実行する必要がある場合や、データベースを別の場所にすべて複製する必要がある場合に便利です。それ以外では、2 次索引が各オブジェクト・タイプに固有になるように、別個のデータベース (例えば、users、orders、products など) にすると、よい場合があります。

文書内にオブジェクトの配列を保管する場合は、配列項目が本当にそれらで 1 つの文書である必要があるかどうかを検討してください。例えば、製品と各製品レビュー は別々の文書に保管する必要がありますが、ユーザー とそのユーザーの各オーダー は、それらで 1 つの文書にする必要があります。

増大し続けるデータ・セットがある場合は、増大し続ける単一のデータベースへのデータ保管をおそらく避けたいでしょう。データの保管は、古いデータをアーカイブしてきれいに削除できる、期間が設定されたデータベース に対して行うのが最適です。 IBM Cloudant 文書を削除しても、トゥームストーン 文書が残ります。したがって、文書の削除を利用してディスク・スペースの回復を行わないようにしてください。代わりに、データベース全体の削除を利用してください。

日付またはタイム・スタンプを保管するための固有の方法は、JSON に備わっていません。後で照会を行う場合は、日付形式を注意深く選択してください。

最大文書サイズは 1 MBですが、文書はそのサイズよりも大幅に小さくなければなりません (通常は、数 KB)。

詳しくは、以下のブログ投稿を参照してください。

1 次索引の活用

IBM Cloudant には、文書の _id 属性での 1 次索引があります。この索引を使用すると、 _id（GET /db/id）または _ids (GET /db/_all_docs?startkey="a"&endkey="z") の範囲によって文書を取得できます。 1 次キーにデータを保管し、各 _id が固有であることを確認することにより、1 次索引を使用して、副次索引を使用せずに文書および文書の範囲を取り出すことができます。以下のアイデア・リストを参照してください。

照会対象として役立つ固有の何かがオブジェクトにある場合は、それを _id フィールドとして使用します (例えば、bob.smith@gmail.com、isbn9780241265543、または oakland,ca など)。
オブジェクトに階層が含まれる場合は、_id で階層をモデル化します (usa:ca:oakland や books:fiction:9780241265543)。階層は大から小への順であるため、1 次索引を使用して、usa のすべての都市または usa:ca のすべての都市を 2 次索引なしで検索できます。
時系列データを保管する場合、_id の開始時点でのエンコード時刻は、1 次索引を時刻でソートします (例えば、001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ など)。
パーティション・データベースでは、パーティション・キーを共有する文書をグループ化します。パーティション・キーは多くの値を含む必要があり、アプリケーションのトラフィックの大部分を数パーティションに送信することを回避するために、ホット・スポットを含んではなりません。

詳しくは、以下のブログ投稿を参照してください。

照会および 2 次索引

IBM Cloudant では、一致する文書の配列と、検索結果の次のブロックへのアクセスを可能にするブックマークを返す、単一のデータベースに対して照会を実行することができます。照会のパフォーマンスを向上させるには、適切な 2 次索引で照会をサポートする必要があります。索引を使用すると、データベース内のすべての文書を探し回ることなく、データベースが照会に応答することが可能になり、パフォーマンスが大幅に向上します。

以下に、ヒントを示します。

遅い操作を顕在化させるのに十分な大きさにデータ・セットがなるまで、照会のパフォーマンス測定が難しい場合があります。実動の前に索引付けと照会のパフォーマンスをテストできるように、十分な現実的なデータを生成してください。
IBM Cloudant は、索引なしでデータをユーザーに返すことができますが、実動ワークロードではこのデータに依存してはなりません。結果セットに警告「No matching index found. Create an index to optimize query time,」が含まれている場合は、索引付けの方法を再検討する必要があります。各照会に選択されている索引を確認するには、explain 機能を使用します。
同じデータベース内に複数のオブジェクト・タイプがある場合、多くのユース・ケースは、固定属性に基づく数個の索引で処理できます。詳しくは、Optimal IBM Cloudant Indexing を参照してください。
索引に意味のある名前を付け、照会時に索引名を指定することにより、どの索引がアプリケーションのどの照会に対応するかが明確になります。

詳しくは、以下のブログ投稿を参照してください。