Downloaded 32 times
![仕様：Azure Table (2) - Property Types
WCF Data Services
type
Common Language Runtime
type
Details
Edm.Binary
byte[]
An array of bytes up to 64 KB in size.
Edm.Boolean
bool
A Boolean value.
Edm.DateTime
DateTim
A 64-bit value expressed as Coordinated Universal Time (UTC). The
supported DateTime range begins from 12:00 midnight, January 1, 1601 A.D. (C.E.),
UTC. The range ends at December 31, 9999.
Edm.Double
double
A 64-bit floating point value.
Edm.Guid
Guid
A 128-bit globally unique identifier.
Edm.Int32
Int32 or int
A 32-bit integer.
Edm.Int64
Int64 or long
A 64-bit integer.
Edm.String
String
A UTF-16-encoded value. String values may be up to 64 KB in size.
2013/11/4
kyrt @takekazuomi
32](https://image.slidesharecdn.com/2013110402introductiontowindowsazurestorage-131109012525-phpapp01/75/Windows-Azure-Storage-Best-Practices-and-Internals-32-2048.jpg)
More Related Content
Similar to Windows Azure Storage:Best Practices and Internals
Windows Azure Storage:Best Practices and Internals
- 1. Windows Azure Storage: BestPractices and Internals 2013/11/4 R.1.0 kyrt Takekazu Omi takekazu.omi@kyrt.in @takekazuomi
- 2. 自己紹介 近江 武一 • WindowsAzure （特にTable)の構築支援 • アーキテクチャ設計、検証 twitter: @takekazuomi github: https://github.com/takekazuomi http://kyrt.in 2013/11/4 kyrt @takekazuomi 2
- 3. Agenda • Introduction toStorage • Internals • Coding with Azure Table Storage • Azure Table and SQL Database • Appendix 2013/11/4 kyrt @takekazuomi 3
- 4. Introduction to Storage WindowsAzure Storageのご紹介 2013/11/4 kyrt @takekazuomi 4
- 5. Windows Azure Storage •Cloud Storage – Anywhere and anytime access • Blob, Tables and Queue • Highly Durable, Available and Massively Scalable • 容易にinternet scaleのアプリケーションが構築可能 • 8.5 trillion stored objects • 900K request/sec on average (2.3+ trillion per month) • 従量課金 • 簡単でOPENなREST APIで公開 • 複数のクライアントライブラリのサポート .NET, Java, Node.js, Python, PHP, Ruby 2013/11/4 kyrt @takekazuomi 5
- 6. Abstractions - Blob,Table, Queue Storageは３種類ある Table Blob REST file system • Block/Page • Data 共有- image, video … • Big Data - raw data/logs … • Backup – SQLDatabase, file backup • Disks – mount VHDs 2013/11/4 structure data • • • • key/value schema less scale partationed sorted set kyrt @takekazuomi Queue Reliable messaging system • component/role間結合 • 非同期タスクスケジュ ラーの実装 • process/work flowsの構 築 6
- 7. Azure Storage 基盤 •3つは、共通のAzure Storage基盤の上に構築 • Azure内でも諸々の用途に利用 Diagnostics Table CDN CloudDrive Blob OS/Data Disk Media Services Queue Azure Storage Clusters 2013/11/4 kyrt @takekazuomi 7
- 8.
- 9. Design Goals • 強い一貫性の元での高い可用性の実現(HighlyAvailable with Strong Consistency) • 障害や分断に直面してもデータアクセスを提供 • 永続性（Durability） • データの複数の複製の保持、（regions を跨いた） • スケーラビリティ（Scalability） • zettabytes へのスケール • 世界中からアクセスできるglobal namespaceの提供 • meet peak traffic での、automatically scale out と load balance Additional details can be found in the SOSP paper: • “Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency”, ACM Symposium on Operating System Principals (SOSP), Oct. 2011 2013/11/4 kyrt @takekazuomi 9
- 10. Windows Azure StorageConcepts Container Blobs https://<account>.blob.core.windows.net/<container> Account Table Entities https://<account>.table.core.windows.net/<table> Queue Messages https://<account>.queue.core.windows.net/<queue> 2013/11/4 kyrt @takekazuomi 10
- 11. Storage Account単位のパフォーマンスター ゲット • Blob,Table ,Queueのpartition • Blobは、URL毎、Tableは、 partition key、Queueはqueue毎で別のpartition • partitionのパフォーマンスターゲット • 2,000 tran/s(queue/table) • 480Mbps/s (blob) • アカウント全体 • 20,000 tran/s(table,queue)※ • 受信 – 10GBps • 送信 – 15GBps 参照： http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windowsazure-s-flat-network-storage-and-2012-scalability-targets.aspx 2013/11/4 kyrt @takekazuomi 11
- 12. partition ？ • • • • • Azure Storageは分散ストレージ データはPartitionに分割して処理される Partitionへの分割はコードでコントロールできる 実際にpartitionがどのように分散されるかは負荷で変わる Partition＝物理マシン1台ではない。パーテションの数を増やしても 性能务化しない（Consistenthashingのvirtual nodeの考えと似て る） • Partitionを跨いだ処理は一貫性が保証されない（分散トランザク ションはサポートしてない、読み取り一貫性も無い） • 内部的にIDC内で3重化、GEO-REPLICATIONで複製を選択すると6 重に保存される 2013/11/4 kyrt @takekazuomi 12
- 13. Windows Azure Storageの アーキテクチャーコンポーネント DNS参照 blob,table, queueへ のアクセス ロケーション サービス アカウント管理 VIP DN S front end VIP front end partition layer s partition layer s stamp間リプリケーション stream layer stream layer stamp内リプリケーション stamp内リプリケーション storage stamp 2013/11/4 storage stamp kyrt @takekazuomi 13
- 14. ３つのレイヤ - ArchitectureLayers inside Stamps • stream layer • このレイヤでデータをディスクに永続化。DFSのようなもの。stream と呼ば れるファイルを使い。保存方法とリプリケーションを実装する。streamは、 extentのordered list • このレイヤは、Blob, Tableなどの構造やセマンティックに依存しない。 • partition layer • 高レベルのデータ構造（blob, table, queue)を実装 • オブジェクトに対するトランザクションの順序付、一貫性の確保を実装 • オブジェクトデータのキャッシュ • front end • リクエストのpartition server へ転送 • serverと、 partitionの割り振りを管理するpartition mapを保持 2013/11/4 kyrt @takekazuomi 14
- 15. stream layer • streamへのWriteは、Appendのみ • Open/Close/Delete/Rename/Read/Apped/Concat stream //bar pointer of extent E1 B1 1 B1 2 ・ ・ ・ extent E1 - sealed 2013/11/4 B1 x pointer of extent E2 B2 1 B2 2 ・ ・ ・ extent E2 - sealed B2 x pointer of extent E3 B3 1 B3 2 ・ ・ ・ B3 x extent E1 - sealed kyrt @takekazuomi pointer of extent E4 B4 1 B4 2 B4 3 extent E1 - unsealed 15
- 16. sealed extentの最適化 • シールされたextentをreplication-> erasure codingで最適化 • リード・ソロモン符号を使って最適化 • 単純に3重にリプリケーションした場合3倍のコストだが1.3－1.5倍の コストに低減できる この辺りは日々改善 • Local Reconstruction Codes (LRCs) • LRCは３つの障害があっても１００％の復元でき、３つのレプリカや ６＋３リードソロモンより耐久性に優れている。 • LCRはリードソロモンより14％データオーバーヘッドが小さく、少な いデータフラグメントの読み込みで復旧することができる 2013/11/4 kyrt @takekazuomi 16
- 17. partition layer architecture watchlease read front end partition map table update partition manager update lease assign partition partition server 1 paxos lock service partition server 1 partition server 1 partition layer stream layer 2013/11/4 kyrt @takekazuomi 17
- 18. partition layer • ObjectTable • partition layerの主な仕事はOTの管理と運用 • OT内は、Range Partition（ low-keyからhigh-keyまで）に分かれてい て、 Range Partitionは スタンプ内のパーティション サーバー 分散し ます • Range Partitionの範囲は負荷によって変動 • Range Partitionとpartition serverの割り振りは、 Partition Manager （クラスタ）が行い。調停にはPaxosロック サービス が使われます 2013/11/4 kyrt @takekazuomi 18
- 19. range partition の処理 write read memorytable row page cache bloom filter partition layer commit log stream meta data stream row data stream blob data stream stream layer 2013/11/4 kyrt @takekazuomi 19
- 20. Dynamic Load Balancing– stream layer • 複数レプリカからのRead ロードバラン シング • レイテンシー/ロードをモニタリング してダイナミックにレプリカを選択 します。95% レイテンシーで追加の レプリカからのパラレル読み込みが 開始されます。 front end P • write load balancing • レイテンシー/ロードをモニタリング してレプリカセットをsealし、別の nodeの新しいextentを割り当てます • capacity load balancing • nodeが十分なDiskを持つように、レ プリカのデータの遅延移動が行われ ます。 partition layer M P P P stream layer P P
- 21. Architecture Summary • Durability:全てのデータは3つのレプリカに保存される • Consistency: 全てのコミットは3つのレプリカにわたって成功 したときに完了する • Availability: 3つのレプリカのどからでも読むことができる。 もし、書込み時になにか問題があった場合も新しいextentに追 記することができる • Performance/Scale: Retryの原因となるレイテンシーの95%は、 Auto scale out とload balance によるもの。（based on load/capacity） 2013/11/4 kyrt @takekazuomi 21
- 22.
- 23. Best Practices- 共通（１） •1400byte未満の小さいメッセージでは Nagle Algorithm を無効 にする • ServicePointManager.UseNagleAlgorithm = false; • Expect 100-Continueを無効にする • ServicePointManager.Expect100Continue = false; • default connection limitを増やす • ServicePointManager.DefaultConnectionLimit = 100; (Or More) • Storage accountと、computing instance/userを近くに置く • computing instanceとstorage accountは同一データセンター内 2013/11/4 kyrt @takekazuomi 23
- 24. Best Practices- 共通（２） •Accountのスケーラビリティターゲットを理解する • 必要なら複数のstorage accountを使う • partition分割を意識する • Cacheを上手く使う • Cacheミスのときだけstorageにfall backする • account/ partitionの限界を越えられる • 複数partitionに負荷を分散することでスパイクを排除する • HTTPSを使う 2013/11/4 kyrt @takekazuomi 24
- 25. Best Practices- 共通（３） •送受信を最適化する • Blob：range read, metadata, head request • Table：Upsert、Merge、Projection、Top • Queues：Update Message、Batch Size • アプリケーションレイヤーではparallelを使う • 無制限なparallelはレイテンシーの务化、スロットリングを引き起こす • storage serviceのLoggingと、Metricsを有効にする • API経由あるいは、Portalで有効にできます • clientのdebugやperformance問題の解決に役立ちます • 指定したretention intervalで自動的に削除されます 2013/11/4 kyrt @takekazuomi 25
- 26. Blob Best Practice •read sizeと、write sizeを合わせる • 大きなblockのblobの小さなレンジを読むのは避ける • CloudBlockBlob.StreamMinimumReadSizeInBytes/ StreamWriteSizeInBytes • block blobは、blockのリストとして管理されるので • 複数のファイルをアップロードする良い方法は？ • 同時に複数のファイルをアップしましょう • blobをアップロードするもっと速い方法は？ • parallel block upload を使って下さい。 • single blob = one partition • 単一blobへのアクセスはpartition targetに制限される • 複数のblobへのアクセスはスケールする 2013/11/4 kyrt @takekazuomi 26
- 27. Table Best Practice •hotspotを避けるようにPartitionKey, RowKey を選択する • Table Scanはコストが高い – レイテンシーが重要なシナリオでは避け る • Batchを使う：同一PartitionKeyでは複数のEntityを同時に更新 できる • Schema-less: 複数のTypeを同一のTableに入れる • Indexは１つだけ（ PartitionKey, RowKey ）：複数のIndexが必 要な場合は複合キーを検討する • Entity Locality：ソート順の近い場所に必要なものを置く • 関連するEntityを近い場所に置くことでIOが軽減されてPerformanceが 向上する 2013/11/4 kyrt @takekazuomi 27
- 28. Queue Best Practice •messageの処理はidempotentに • もしwokerがmessageを削除出来ずに落ちた場合、messageは再度visibleに なる • Update Messageの利点 • visibility timeを延長やステートを保存できる • Message Count • queueの溜り具合を現す、 worker の scale の目処になる • Dequeue Count • poison messages の発見、invisibility time の妥当性確認に使える • 大きなメッセージはBlobs に • 大きなバッチ処理時等に throughput が向上する（大きなものはQueueに積ま ない） • 複数 Queuesの利用 • single queue = partition 、partition targetに制限される 2013/11/4 kyrt @takekazuomi 28
- 29. Designing Azure Table Storage 2013/11/4 kyrt@takekazuomi 29
- 30. Characteristics of AzureTable Storage 大きな特徴 1. 2. 3. 4. 5. 6. Schema less Partition Range Query Strong Consistency Hi Scalability Low cost RDB(SQL)に比べて5,6は優位、他のK/VSに比べると、3,4は特徴 的。 2013/11/4 kyrt @takekazuomi 30
- 31. 仕様：Azure Table (1) •Table Names • 名前は3－63文字まで、case-insensitive • Property • Property 名は、case-sensitive で、最大 255 文字まで. Property 名は、 C# identifiers と XML specification 準拠（注：dashは使えない） • Propertyの数は、最大255個（system property 3個を含む） • データサイズは全 property の合計が最大で１MBまで • PartitionKey と RowKeyの Propertyで使えない文字、’/’, ’’, ’#’, ’? ’, U+0000 to U+001F, U+007F to U+009F • PartitionKeyとRowKeyは、最大１KBまで http://msdn.microsoft.com/en-us/library/windowsazure/dd179338.aspx 2013/11/4 kyrt @takekazuomi 31
- 32. 仕様：Azure Table (2)- Property Types WCF Data Services type Common Language Runtime type Details Edm.Binary byte[] An array of bytes up to 64 KB in size. Edm.Boolean bool A Boolean value. Edm.DateTime DateTim A 64-bit value expressed as Coordinated Universal Time (UTC). The supported DateTime range begins from 12:00 midnight, January 1, 1601 A.D. (C.E.), UTC. The range ends at December 31, 9999. Edm.Double double A 64-bit floating point value. Edm.Guid Guid A 128-bit globally unique identifier. Edm.Int32 Int32 or int A 32-bit integer. Edm.Int64 Int64 or long A 64-bit integer. Edm.String String A UTF-16-encoded value. String values may be up to 64 KB in size. 2013/11/4 kyrt @takekazuomi 32
- 33. Data Modeling Considerationsfor Azure Table Application • flexible schema • key 設計 • partition 設計 • Data Modeling Decisions • Embedding • Referencing • Atomicity • Operational Considerations • Data Lifecycle Management • Large Number of Collections 2013/11/4 kyrt @takekazuomi 33
- 34. Entityの設計 • データ・モデルを考える際に • Partitionにどのようにデータを配置するかでトランザクションが使え るかが決まる •EntityのKeyを何にするかでQueryの可否（パフォーマンス）が決まる • Entityを分割する価値 • 正規化のメリットは限られている、同一Entityに入れられる物は入れてしまう • 集計等でPartitionを跨いた処理が必要 • システムの主たる目的が、OLTPかOLAPかの性格付けは初期段階でする。OLTP なら、Azure Tableは向いているがOLAP的に使うのはAzure Tableだけでは無理 でHadoop等の併用を検討する • アドホックな集計でなくある程度安定したものなら専用のINDEXデータをトラン ザクション時に生成する まずは、Partitionを考えてみよう 2013/11/4 kyrt @takekazuomi 34
- 35. pattern of Tableand Partition usage • Table分割の２つのPattern • Table : Class = 1:1 • Table : Class = 1:N • Partition は、Table+ PartitionKeyで決まる • Table : Class = 1:1では、 同一 Classしか同じPartitionに入れられない。 • Table : Class = 1:N では、複数のClassを同一 Partition に入れられる • その他（Table分けると便利なこと） • Table単位で削除できる（現在一括削除は、Storage Account単位と、 これだけ） 2013/11/4 kyrt @takekazuomi 35
- 36. Table : Class= 1:1 • Single Class, Single Table mapping • 別Classのデータは同一 Partitionに入らない 2013/11/4 Person Inbox Outbox Friend kyrt @takekazuomi 36
- 37. Table:Class = 1:N •データの粒度 を考えて Partition を分割 • 読込アクセス（Read）とトラ ンザクション（Write）に注目 Table Data インデックス Log kyrt @takekazuomi オブジェクトのデータ Index 2013/11/4 内容 ストレージの変更履歴ログ 37
- 38. keyの設計 • Azure TableではKeyの設計が非常に重要 •PartitionKeyの選択 • 同一Partition内のものはEGTでAtomicに処理出来る • 複数PartitionのデータをAtomicに処理するような分散トランザクショ ンの仕組みは無い • Partitionには同時アクセス数の上限がある • 複数のEntiryの場合 • 基本的な考えは、Single RootのTreeになるようにする • 単一Entity依存関係無しの場合 2013/11/4 kyrt @takekazuomi 38
- 39. Keyの採番 • 採番（＝連番と考えない） • Uniq性 •Uniqであれば良いなら、GUIDなどを利用。クライアントの演算だけで採番できるの で非常に高速に採番可能です • Uniq性 + 時系列での増加（減少） • 時間を元にした値＋乱数（あるいはGUID）を利用します。時間はTickを元にすると Longで表現することができます。またTickのリバースキー(例：Int64.MaxValue-Tick 等）を使うと逆順にもできます。乱数が必要なのは時間だけだと衝突する可能性が低 くないからです。採番速度は衝突の頻度次第です。乱数の代わりにGUIDを使えば上 記と同等の速度で採番可能です • Uniq性 + 連続の番号 • 連番を生成するのはAzure Tableだけだと楽観的ロックを使わざるえません。読んで 書かないといけないので、成功した場合でも100ms以上の時間が必要です。非常に遅 いので、使える場面が限定されます。 どの方法も重複した場合のリトライロジックを入れた方が無難 2013/11/4 kyrt @takekazuomi 39
- 40. その他 • Embedded • oneto one, one to manyのパターンはシリアライズしてプロパティに 埋め込む策がある • 正規化を崩すが読み込みPerformanceは良い。更新時を検討する 2013/11/4 kyrt @takekazuomi 40
- 41. Windows Azure StorageClient Library 2.1 まず最初に • Introducing Storage Client Library 2.1 RC for .NET and Windows Phone 8 • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/07/12 /introducing-storage-client-library-2-1-rc-for-net-and-windowsphone-8.aspx • Announcing Storage Client Library 2.1 RTM & CTP for Windows Phone • http://blogs.msdn.com/b/windowsazurestorage/archive/2013/09/07 /announcing-storage-client-library-2-1-rtm.aspx 2013/11/4 kyrt @takekazuomi 41
- 42. LastLogonDate TableEntity • Entityは、TableEntity から派生 して作成 •TableEntity Class は、3つのシ ステムプロパティ、ETag、シリ アライザ、デシリアライザが実 装 • https://github.com/WindowsAzure/azure-sdk-fornet/blob/master/microsoft-azureapi/Services/Storage/Lib/Common/Table/TableEntity.cs#L3 1 • ReadEntity/WriteEntityの overrideでプロパティへの保存 形式を変更可能 • ITableEntity を実装することで 自前実装可 2013/11/4 public class Person : TableEntity { public Person() { PartitionKey = "Customer"; RowKey = Guid.NewGuid().ToString(); } public string FirstName { get; set; } public string LastName { get; set; } public DateTime? LastLoginDate { get; set; } } kyrt @takekazuomi 42
- 43. Write Operation • Entityを用意して varperson = new Person() TableIOperation Class の { static method を呼んで操作の FirstName = "Harp", オブジェクトを作成して、 LastName = "Walter", LastLoginDate = DateTime.UtcNow.Date.AddDays(-10) Table Client の Executeを呼ぶ }; のが基本 • Batchの場合は、 var insertOperation = TableOperation.Insert(person); TableBatchOperation に table.Execute(insertOperation); TableIOperation を入れて Executeで実行 • TableIOperationでは、Entity として、ITableEntity を受け 入れる 2013/11/4 kyrt @takekazuomi 43
- 44. Write Option Entityの更新系の操作は6種類 • Insert • • POST http://msdn.microsoft.com/en-us/library/windowsazure/dd179433.aspx •Update • • PUT If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179427.aspx • Delete • • DELETE http://msdn.microsoft.com/en-us/library/windowsazure/dd135727.aspx • Merge • • MERGE If-Match有り http://msdn.microsoft.com/en-us/library/windowsazure/dd179392.aspx • Insert or Merge • • MERGE If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452241.aspx • Insert or Replace • • 2013/11/4 PUT If-Match無し http://msdn.microsoft.com/en-us/library/windowsazure/hh452242.aspx kyrt @takekazuomi 44
- 45. Read Operation var query= from ent in currentTable.CreateQuery<CustomerEntity>() where ent.PartitionKey == “users” && ent.RowKey = “joe” select ent; • LINQ式で書ける • 実は、1.xでは出来たけど、2.0で無くなって、2.1でLINQ復活 2013/11/4 kyrt @takekazuomi 45
- 46. Query のコスト Queryのパターン 効率 1 PartitionKey ==“SciFi” and RowKey == “Star Wars” Single entity lookup 、これは最も効率が良い 2 PartitionKey == “SciFi” and “Sphere” ≤ RowKey ≤ “Star Wars” single partition 内のエンティティScan レンジ内のエンティティ数に依存 3 “Action” ≤ PartitionKey ≤ “Thriller” 複数パーテション内のエンティティScan それぞれのパーテション内のエンティティ数に依存 4 PartitionKey == “Action” || PartitionKey == “Thriller” 2つのパーテションの中だけをScanするように最適化されて いない。Tableの全てをScanする。 この場合は、2つのQueryに分けて実行することを推薦する 5 “Cars” ≤ RowKey ≤ “Star Wars” PartitionKey が指定されていないので、Table内の全てのエン ティティをScanする 6 (PartitionKey == "..." && RowKey == "...") || (PartitionKey == "..." && RowKey == "...") この場合、１のようにならずに全てのpartition がScanされる。 つまり４と同じ 2013/11/4 kyrt @takekazuomi 46
- 47. Query Options 3つしか無い • $top •取得件数、1000件以下に制限 • $filter • 演算子で使えるのは、eq, gt, ge, lt, le, ne と and, not, or • $select • 取得するプロパティを指定 2013/11/4 kyrt @takekazuomi 47
- 48. Retry Azure Storageではホットスポットが発生して動的負荷分散が動くと操作がエラー になる場合がある（これは規定の動作） そのような場合に備えて、アプリケーション側ではリトライロジックを用意が必 要。 デフォルトは、ExponentialRetry、3つのリトライ実装が用意。 • Linear •固定の backoff periodの待ち時間で最大リトライ数までリトライする • Exponential • backoff period を、Math.Pow(2, retryCount) * backoff period +/- 20% の待ち時間で最大リ トライ数までリトライする • No Retry • リトライしない 参考：Windows Azure ストレージ サービスの構造とリトライ ポリシーの関係に ついて • http://msdn.microsoft.com/ja-jp/windowsazure/jj647756 2013/11/4 kyrt @takekazuomi 48
- 49. HTTP Result Codeと Retry の関係 • IRetryPolicyを実装してカスタムリトライを実装できる • retryable/Non-retryable なエラーという考えがある • 400番台と501, 505がNon-retryableなエラーコード • それ以外と、client side timeouts(408)は、retryable • http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overviewof-retry-policies-in-the-windows-azure-storage-client-library.aspx • Azure Storage のエラーコード • http://msdn.microsoft.com/ja-jp/library/dd179357.aspx • 実際のコード • https://github.com/WindowsAzure/azure-sdk-for-net/blob/master/microsoftazureapi/Services/Storage/Lib/Common/RetryPolicies/ExponentialRetry.cs#L71 • Blob側とコードを共有しているので上記説明と少し違う 2013/11/4 kyrt @takekazuomi 49
- 50. Entity Group Transaction entitygroup transaction (EGT)の要件 • トランザクション内の全てのエンティティは同一PartitionKey で無ければな らない（Tableも同じ） • entity は、 transaction 内に一回だけ出現できます。そして、1つだけの操作 がそれに対して許されます。 • transaction には、最大 100 のエンティティ、最大４MBのPayloadが許されま す。 • 全てのエンティティは、 Table Service Data Model に沿っていなければいけ ません。 • 上記の条件をクリアすれば、BatchOperationでまとめて処理できま す。 • EGTは、MultiPart MimeのRequestで一括で送られ、良いパフォーマ ンスが出ます（条件が良いと10倍以上早くなります） 2013/11/4 kyrt @takekazuomi 50
- 51.
- 52. Azure Storage Client •.NET Framework • https://github.com/WindowsAzure/azure-sdk-for-net nuget • node.js • https://github.com/WindowsAzure/azure-sdk-for-node npm • java • https://github.com/WindowsAzure/azure-sdk-for-java maven • python • https://github.com/WindowsAzure/azure-sdk-for-python PyPI • ruby • https://github.com/WindowsAzure/azure-sdk-for-ruby gem • php • https://github.com/WindowsAzure/azure-sdk-for-php 2013/11/4 kyrt @takekazuomi PEAR 52
- 53. 最後に • Internalの部分は、Azure StorageTeamがSOSPで発表した内容に基づい ています。 • 23rd ACM Symposium on Operating Systems Principles (SOSP) "Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency“ 翻訳もあります • Windows Azure ストレージ: 高可用性と強い一貫を両立する クラウド ス トレージ サービス • http://msdn.microsoft.com/ja-jp/windowsazure/dd439432#leaning • Best Practiceと追加の情報はBUILD 2013のセッションから拾っています • BUILD 2013 Windows Azure Storage: What’s Coming, Best Practices, and Internals • http://channel9.msdn.com/Events/Build/2013/3-541 • 全ての情報は2013/11/04時点のものです。 2013/11/4 kyrt @takekazuomi 53