DocumentDB：新しいアジアと米国の領域、SQLパラメータ化、アカウント制限の増加
今月初旬、Azure DocumentDBサービスで、以下の新機能をリリースしました。これは、完全管理のNoSQL JSONデータベースサービスを提供します。
- 新しい領域の可用性
- 大規模アカウントとドキュメント：アカウントあたりの容量ユニット数増加と2倍の文書サイズをサポート
- SQLのパラメータ化：データの偶発的な露出防止のためユーザー入力の処理とエスケープをサポート
新しい領域
東アジア、東南アジア、米国東部のAzure領域（既存の米国西部、東ヨーロッパ、西ヨーロッパ領域への追加）でのDocumentDBアカウント準備を新しくサポートすることになりました。DocumentDBデータを格納する場所を決定する時に柔軟性と選択肢が得られるよう、領域拡大への投資を今後も継続していきます。
大規模なアカウントとドキュメント
プレビュープロセスを通じて、ドキュメントおよびデータベースの最大サイズを着実に増加させてきました。今回のリリースで、個々の最大ドキュメントサイズを256KBから512KBに増加しました。DocumentDBアカウントあたりの容量単位（CU）制限も5から50に上昇させたため、1つのDocumentDBアカウントを、500GBのストレージおよび10万要求単位のプロビジョニングスループットまでスケール調整できます。いつものように、プレビュークォータはアカウントごとに調整できるので、容量を増加する必要があればご連絡ください。
SQLパラメータ化
新しいクエリ言語を発明する代わりに、DocumentDBは階層的JSONドキュメント上でSQL（構造化照会言語）を使用したドキュメント検索をサポートしています。Azure DocumentDBREST APIおよびSDKにパラメータ化されたSQLクエリのサポートを追加することで、SQLクエリ機能を拡張させて頂きました。この機能を使用すると、パラメータ化されたSQLクエリが書けます。パラメータ化されたSQLは、強固なユーザー入力の処理およびエスケープを提供して、“SQLインジェクション“を介した偶発的なデータの露出を防止します。
では、.NET SDKを使用してサンプルを見てみましょう。プレーンなSQL文字列とLINQ式の他、パラメータ化クエリの構築に使用できる新しいSqlQuerySpecクラスを追加しました。以下は、著者名に対して1つのユーザ指定パラメータで“Books”コレクションを検索するサンプルです。
IQueryable<Book> queryable = client.CreateDocumentQuery<Book>(
collectionSelfLink,
new SqlQuerySpec {
QueryText = "SELECT * FROM books b WHERE (b.Author.Name = @name)",
Parameters = new SqlParameterCollection() {
new SqlParameter("@name", "Herman Melville")
}
});
- DocumentDBのSQLパラメータはT-SQLから借りてきた馴染みのある@表記を使用します。
- パラメータ値は任意の有効なJSON（文字列、数値、ブール値、Null、配列、ネストされたJSON）になります。
- DocumentDBがスキーマレスなのでパラメータは任意の型に対して検証されません。
- SqlParameterCollectionにSqlParametersを追加することで簡単にパラメータが追加できます。
DocumentDB REST APIもネイティブにパラメータ化をサポートしています。上記で示した.NETサンプルは、以下のREST API呼び出しに変換されます。パラメータ化クエリを使用するには、以下のように、Content-Typeヘッダーをapplication/query+jsonとして、BodyにJSONとしてクエリを指定する必要があります。
POST https://contosomarketing.documents.azure.com/dbs/XP0mAA==/colls/XP0mAJ3H-AA=/docs
HTTP/1.1 x-ms-documentdb-isquery: True
x-ms-date: Mon, 18 Aug 2014 13:05:49 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3dkOU%2bBn2vkvIlHypfE8AA5fulpn8zKjLwdrxBqyg0YGQ%3d
x-ms-version: 2014-08-21
Accept: application/json
Content-Type: application/query+json
Host: contosomarketing.documents.azure.com
Content-Length: 50
{
"query": "SELECT * FROM books b WHERE (b.Author.Name = @name)",
"parameters": [
{"name": "@name", "value": "Herman Melville"}
]
}
クエリは、上記に示されたアプローチを使用して、Databases、DocumentCollections、Attachmentsのようなドキュメントコレクションおよびメタデータコレクションに対して発行されます。これを試してみる場合、サポートされているプラットフォーム（.NET、Java、Node.js、JavaScript、Python）上に最新のDocumentDB SDKビルドをダウンロードしてください。
いつものように、最も価値があると思われたDocumentDB機能や体験についてお聞きしたいと思っています。Microsoft Azure DocumentDBフィードバックフォーラムからご提案ください。
Search：ポータルの機能強化、提案およびスコアリング、新たな領域
今月初旬、Azure Searchサービスに大きな機能強化を数多くリリースしました。Azure Searchは、大規模な検索サービスを管理、チューニング、スケーリングする際に付随する典型的な複雑さに対応することなく、Webやモバイルアプリケーションに検索機能を構築するのに必要なすべての機能を開発者に提供します。
Azureポータルの機能強化
先月、Azureプレビューポータルから検索インデックスを作成および管理する機能を追加しました。それ以来、大幅に必要なコード量が減少して開発スピードが大きく向上したが、必要なものはまだあるとお聞きしました。結果、スコアリングプロファイルの追加と、ポータルからクロスオリジンリソース共有の設定ができる機能を追加して、ポータルを拡張しました。
スコアリングプロファイルのポータルサポート
スコアリングプロファイルは、コントロールする他の要因に基づいた検索結果を上位に押し上げます。例えば以下では、ホテルインデックスがあり、それ以外はすべて等しくなってるのですが、検索結果にはユーザーの現在地に近く評価の高いホテルを上位に表示したいと思います。これを行うには、Azureプレビューポータルで、Add Scoring Profileを選択して、名前を入力してください。このケースでは"closeToUser"にします。異なるケースで異なる検索結果が提供できるように、スコアリングプロファイルは検索リクエストの必要に応じて複数作成してそれぞれに名前が付けられます。
closeToUserが作成できたら、重みと機能を追加して開始します。例えば、このスコアリングプロファイルでは、以下を追加します。
- 重み付け：加重フィールドとしてhotelNameを使用します。これにより検索語がhotelNameにあれば、それは上位へ重み付けされます。
- 距離：ユーザーの指定した場所に近い場合、Azure Searchの空間的機能を活用してそのホテルを上位に提供します。
- マグニチュード：高評価のホテルを上位に提供します。
これらの関数および加重はすべて、その後ドキュメントのランク付けで使用される最終スコアに結合されます。
スコアリングプロファイルはややこしく残りのクエリ部分と混合される傾向があります。Azure Searchだと、スコアリングプロファイル体験は単純化されていて、検索クエリからは分離されるので、スコアリングモデルがアプリケーションコード外に留まり、独立して更新できます。さらに、スコアの編集やメンテナンスをより簡単にするため、これらのスコアリングプロファイルは、高レベルのスコアリング機能と典型的なフィールド加重の方法を組み合わせたモデルになっています。
上記で示したように、このユーザ体験ではコーディングが不要で、重要なフィールドを選択して、最も適切な機能または加重を適用するだけです。これはドキュメントの関連性を高める方法で、ソートと混同しないようにしてください。利用可能な多くの機能がありますので、詳細はMSDNドキュメントを確認してください。
クロスオリジンリソースの共有（CORS）
Webブラウザは、通常セキュリティ上の理由から、別ドメインにクライアント側のWebアプリケーションが要求を発行しないように、ネットワーク要求に同一生成元制限ポリシーを適用します。例えば、「http://www.contoso.com」から来たJavaScriptコードは、「http://www.northwindtraders.com」などの別ドメインに要求を発行できませんでした。Azure Search開発者にとって、すべてのデータが公的に既にアクセス可能で、モバイルデバイスやブラウザから直接検索インデックスにいくことで遅延を防ぎたい場合、これが重要になります。
CORSは、セキュリティを脅すことがないように制御された方法でこの制限を緩和する方法です。Azure SearchはCORSを使用して、ブラウザ内のJavaScriptコードが直接Azure Searchサービスに検索要求を行い、元のサーバーにすべての要求がプロキシ接続されないようにできます。AzureプレビューポータルからCORSの設定機能を提供することになったので、簡単にクロスドメインアクセスを有効にし、特定の生成元に限定できます。以下に示すように、これはSearchサービスのインデックス管理部分から行えます。
タグブースト
スコアリングプロファイルで説明したように、特定の関連項目を上位にしたいケースは数多くあります。そのため、スコアリングプロファイル機能に、リクエストの高かったタグブーストという新機能を導入しました。この潜在的新機能をテストしてフィードバックして頂けるように、現在、実験的APIバージョンの一部で利用できるようにしています。
タグブーストにより、検索クエリと共通のタグを持つドキュメントを上位にできます。検索クエリのタグは、各検索要求でスコアリングパラメータとして提供され、それらの言葉が含まれたドキュメントはすべて上位になります。この機能は、検索結果のカスタマイズが可能になるだけでなく、上位にしたい特定の項目がある場合にも使用できます。例えば、スポーツイベントの間、小売業者がそのスポーツイベントに参加しているチームに関連した項目を上位にしたい場合などです。
改善された提案
提案（オートコンプリート）とは、ユーザーが入力しようとすると入力候補が表示される機能です。スコアリングプロファイルの様に、ユーザーが探しているコンテンツをすばやく見つけることができる素晴らしい方法です。Azure Searchで検索候補を初めて実装した時、要件により合致するように、この機能を拡張してほしいというご要望を数多く頂きました。結果、これらの項目に対応するため、全く新しい提案の実装を行いました。特に、提案には中置マッチングを行いますが、もしファジーマッチングを有効した場合は、スペルミスにもより柔軟に対応します。結果に対して100までの提案が可能で、フィールド制限以外、長さ制限や最低3文字制限もありません。
この機能拡張は、現在フィードバック収集を継続しているため、まだ実験的APIバージョン配下にあります。この詳細および提案例については、Azureブログの提案に関する投稿をご確認ください。
新しい領域
最後に指摘しておきたいのですが、Azure Searchのグローバル通信領域を継続して拡大してます。東アジアと西ヨーロッパを追加し、世界中の8領域でAzure Searchサービスを準備できるようになりました。
