RU/秒のパーテーション無しコレクションで行った。106%1万エンティティで1度だけしか測っていないので、数値の絶対値は参考程度にしかならない。それでも傾向ぐらいはわかる。ID検索の部分が、パーテーションキー、ローキーによる検索。Tableでは全てのプロパティに自動的にインデックスが作成されるので、この場合もインデックスが利用される。1.5から1.6倍程度Premiumが速い。プロパティ検索はセカンダリーインデックスの効果を見る項目で、Standardだとフルスキャン、Premiumだとインデックスが使われる。セカンダリーインデックスの効果は絶大で10倍以上Premiumが速くなる。データ件数が多くなればさらに差が出るだろう。99パーセンタイルでは、2つの差は広がり、2倍程度の差になる。今回は件数が少ないので、この程度の差になったが、件数を増やして調査時間を長くすれば差は大きくなると思われる。Tableが意外と奮戦している、前に調べて時より少し速くなっているようだ。Tableはまだプレビューという点を差し引いても、一貫してレイテンシーが低いというのは魅力的だ。セカンダリーインデックスを更新する分、更新系は不利なはずだが、それでもStandardより速いのも今後が期待できる。Premiumが速く、特にセカンダリーインデックスが効くと劇的に速くなる。全体的にPremiumのレイテンシーはバラツキが小さく一貫してレイテンシーが低いのは好印象だ。SDKサンプルコードを見ると、PremiumとStandardの切替は接続文字列[12]の設定だけだ。AppSettingsには下記の設定ができるようだ。基本的にはDocumentClient関連の設定だ。Tableに最適化されたコードを書きたい場合には、あまり適さない。コードで変更できるようにして欲しい。設定名TableConnectionModeTableConnectionProtocolTableConsistencyLevelTableDisableRUPerMinuteUsageTableIndexingPolicyTableIsRUPerMinuteEnabledTableMaxConnectionLimitTablePreferredLocationsTableQueryContinuationTokenLimitInKbTableQueryEnableScanTableQueryMaxDegreeOfParallelismTableQueryMaxItemCountTableThroughput現在のSDKだと、スロットリングがかかったときのリトライのハンドリングが怪しいようだ。それにサンプルコードではスロットリングエラーになった場合の処理が考慮されていない。そのため今回の測定ではスロットリングがかからないように2000RU/秒に設定した。Tableに最適化したコードが必要な場合は、そのためのコードが必要になるということだ。Tableでは互換性が無い。ある程度SDKで吸収できるだろうが、プロダクションコードでは、ある程度アプリケーション側で対応する必要があるだろう。しては全く互換性が無い別プロトコルだ。エンティティの作成も、今のStandardではレスポンスは空になるが、Premiumではしっかり中身が入っている。DocumentDBとウリ2つだ。参照していることからも、実際の通信はDocumentDBと同じプロトコルを使っていることが伺える。Storage向けのライブラリは作り直す必要がある。APIレベルで互換なのかと思ったので、ちょっと肩透かしだ。APIよりDocumentDB形式の方が将来性がある気もする。面白いアプローチではある。まとめつらつらと書いていたら随分長くなってしまった。APIの話とかTLA+の話も書きたかったが疲れたので、この辺で一旦終わる。Tableを聞いた時は、DocumentDB時代の価格体系だとちょと用途が限定される気がして、どうなのかとも思ったが、B8047[5]の話を聞いて、今はとても期待している。DBはいいぞ」と言う感じだ。APIではパーテーション無しコレクションしか作成できず、コレクションの容量は10GBだ。これはプレビューの制限だと思われる。10GB以上のデータで評価したい場合は要注意だ。RU/秒まで設定でき、Standardのストレージアカウント全体のパフォーマンスターゲット(1Kエンティティで毎秒20,000トランザクション)[14]を上回る。DBのコレクションになるので、Table単位で課金される。Standardだと割りと気軽にTableを作れたのでこれも設計変更の要因になるだろう。ランポート先生のインタビュー、お勧めです。RU/秒程度を消費していた。Tableのストレージアカウントの10倍、書込は同等のスループットということになる。ここでは、Read/Write混合を想定して「上回る」という表現にした。minutesTLA+TLA+については、こちら。入門的な解説の動画から用意されてる。TabExtentionを使ってタブ補完を実装していた。[1]仕組みはシンプルで便利な機能だったので、いつも使っているPsEnv[2]に実装してみた。[3]簡単なコードだが知らないテクニックが使われていて面白かったので軽く紹介。基本、これだけなので、非常にシンプルでわかり易い。[4]git-poshのコードを見ながら実装してみたら、こんな感じになった。コード解説L33で現在のTabExpansionの関数をリネームして保存しておく、補完処理が自分と関係無い場合は、このコードにフォールバックする。(関数名を変更できるのは知らなかった)コールバックチェーンの実装方法の一つらしい。Exportされておらず、名前が衝突する心配は無い。TabExpansion関数が呼ばれる。PsEnvTabExpansionは、コマンドラインのラストブロックを貰って、正規表現で引っ掛けて対象の補完文字列を返す。正規表現を使うとスッキリ書けて気持ちいい。PsEnvはCmdletなので、DynamicParamでも良かったかなという気もするが、実装を比べると.NETのクラス出まくりのDynamicParamに比べTabExtentionは綺麗に書ける。Globalなキー入力をフックするので下手に作るとキー入力のレスポンスが悪くなるという欠点がある。どっちも、デバックし辛いのは欠点。PsEvnの紹介あまり知られていない気がするので、PsEnvの紹介を簡単に書いておく。Windowsでは環境変数の取り合いになって、うまく共存できない環境がママある。linuxや、Macだと、rubyや、pythonの仮想的に切り替える仕組みだけで足りたりするのだが、Windowsだと駄目だったり。そのバージョン違いでコンパイルされていたりして混ざって動かなくなったりすることがある。そのため、標準の環境変数はなるべくクリーンにしておいて環境によって必要な環境変数を設定するようにしている。PsEnvは環境変数を設定するのに便利なCmdletだ。使い方は、PsEnvを見てもらうとして、使ってる設定ファイルpsenv.jsonを参考までに上げておく。ゴミが多くて少々長い申し訳無い。WMF5の標準機能として取り込まれている[5]のを知った。共存しても問題無いのだろうか。このあたり[6]には、PowerTab(?)対応のコードが入ってるので余計気になる。公式ドキュメントが見つけられないかった。まとめに書いてあるので、そっちをどうぞ。意識することなくブロックデバイス(仮想ディスク)をリソースとして使えるようになりましたという話。Disk(=良さ気に管理されたディスク)と呼ばれている。いつものように、名前がベタすぎてかえってわかりづらい。制限を意識する必要が無く。従来の仮想マシンのリソース定義では、下記のように書いてた。BlobのURLが定義される。引用するとこんな感じだ。置くストレージアカウントを定義して使っている。部分を省略でき下記のようになる。部分がざっくりと無くなった感じだ。リソースが作成され自動的に名前が付く。インスタンスがS付きの場合はPremium_LRS、それ以外はStandard_LRS、キャッシュはRead/WriteでDiskが作成される。DataDiskの場合はキャッシュのデフォルトはReadOnlyとなる。ストレージの定義も無くスッキリ書けるようになった。DiskはARMリソースになるので、Diskを定義して、仮想マシンにアタッチすることもできる。下記ではDataDiskをDiskリソースとして定義しVMへの接続している。スナップショットが簡単に取れるようになったので、スナップショットの取得、スナップショットからディスクの作成、仮想マシンの起動をテンプレートを使ってやってみた。リソースを作成している。部分にソースとなるDiskのリソースIDを指定してスナップショットを作成するという流れだ。今回何度か実行した感じだと30GBのOsDiskのスナップショットで30秒程度という感じだった。基本仮想マシンを停止して取ることになると思うが、起動中でもスナップショットを取ることはできる。Standard、Premiumを指定することができる。これも30秒程度だった。作成したOsDiskを使って、仮想マシンを起動する。これはちょっと長いので一部を引用する。