AzureのDocumentDBを利用したときに色々と痛い目にあったので、メモしておきます。
アップデートも早いのでそのうち解消されてることや変わってることも多いと思いますが...
> Environment
今回の開発環境はこんな感じです。
- Visual Studio 2015 (Enterprise)
- DocumentDB SDK1.4
> 1. いきなりまとめ
ものをちゃんと理解したほうがよいので、Azure DocumentDBのサイトで基本をしっかり確認すべしです。
https://azure.microsoft.com/ja-jp/documentation/services/documentdb/
そして、ここは必読と思っています。
azure.microsoft.com
読んでおいた方があとで後悔しません。
この後は、そこら辺を読まずに開発して痛かった経験をもとに書いていきます。
> ２. 処理？接続？おそーーーーい！
遅いといっても、様々な要因がありますので、そこに対する対応はケースバイケースです。
しかし、これは最も注意しなければならないのは、
別リージョンからのアクセスは、痛いことになる可能性大です。
単発のアクセスであればさほど問題ないですが、連続で大量のアクセス・処理をすると絶望的です。
2015/9月時点では、東日本・西日本にはDocumentDBがありません。
ということで、アジア圏にDocumentDBをおいて、日本からアクセスしたら絶望的に遅くて困りました、絶望的に。
私の経験だと、処理するアプリを同一リージョンに置くことで10倍くらいの速度が出てすっきりしましたので、ここは最も注意すべき点だと思います。
同一リージョンにDocumentDBと処理するアプリを置けない事情がある場合は、要注意です。
これは、ツールを使ってデータのマイグレーションをする時にも有効です。
DocumentDBと同一リージョンにAzureの仮想マシンを立てて作業すると時間効率がよいです。
（後述しますが、インスタンスも最大（S3)にしてするとなお良しです：その分お金はかかりますが！）
> ３. Exception「Request rate is too large」が突如として頻発
開発途中まで全然出ていなかったのに、とある時から「Request rate is too large」というExceptionが発生しました。ほげー！
DocumentDBのインスタンスサイズごとに「要求単位」（REQUEST UNITS)があり、それ以上をリクエストしたらException出ます（と理解してます）。
ようは「処理のキャパがオーバーしたよーだからむりー！」っていって拗ねたのでExceptionはいた状態（あくまで私の主観）です。
私の場合、バッチ的な処理するアプリのインスタンスを単一で動かしていたのですが、複数インスタンスで同時処理したら発生しました。
S1の安いインスタンスに甘んじていた結果ですね。これは、DocumentDBのサイズを拡張したら改善しました。
ただ、Exception出て死んでしまうのと色々と面倒なので、プログラムでも対策をしてます。
それは、ここら辺を参考にしてますので、今回は書きません。
stackoverflow.com
プログラムで多少改善ができますが、気休め程度でしょうか。S1だとやはり色々つらいので、プロダクトには最低でもS2にすべきと痛感した2015夏でした。
> ４. DocumentDB データ移行ツール、これ便利です。
本家で出てるツールの紹介なだけですが、これは便利です。
azure.microsoft.com
前述しましたが、これでDocumentDBからごそっとデータを引っこ抜くときは、経験上ではS3にするとかなり早いです。もちろん同一リージョンの仮想マシンで。
（料金体系は、事前にご確認を！）
GitHubにソースがあるので、実装の参考にも。
github.com
◆追記
こちらのブログでもうちょっとスマートな対応してみました。
beachside.hatenablog.com
> ５. クエリ間違ってないのにエラー？！
便利なことに、SQL文的なものでデータを取得することができます。
とりあえず初めてであれば、ここら辺を参考にサクッとアプリを作れます。
azure.microsoft.com
https://azure.microsoft.com/ja-jp/documentation/articles/documentdb-sql-query/azure.microsoft.com
しかし、クエリに制約があって、エラーになることがあるので、制約には注意しましょう。その制約はここで確認できます。
azure.microsoft.com
私の経験では、「クエリあたりの AND 句の最大数」で、サクッとやられました。
DocumentDB用のサンドボックス的なものがあるので、ここで色々試すのもいいし、Azureのポータルからクエリをたたいてエラーにならないことを確認してもよいと思います。
Azure Cosmos DB Query Playground
> ６. 最後に
課金が、コレクション単位なんです。リソース面を考えるとそっかーとならないこともないですが、RDB育ちの私はなかなか驚きました（笑）要注意です。
インデックスは、まだ全然使ってないのでやらないとなー（処理速度を懸念してるくせにやってないのはどうかと思ってます）
冒頭のまとめに書いた必読のサイトは、すべて非常に大切なポイントなので、必ず読みましょう。Part2もあるのでそれも。
そんなこんなで色々と2015年の夏の思い出はDocumentDBと戯れた日々しかないですが、今後も使っていきたいので色々勉強できたらなーと妄想してます。
