Contenu connexe
Similaire à NoSQL Bigtable and Azure Table (20)
Plus de Takekazu Omi (20)
NoSQL Bigtable and Azure Table
- 4. ここ20年ほどの間の流れ
1. ここ20年の間で、データの永続化手段は、
RDBMSとファイルシステムの2つに集約
2. 扱うデータ量が急激に増えた。100万超のサービ
スの通常化、20年前ならYahoo Japanクラスがゴ
ロゴロしている
3. コモディティ化されたハードウェアによって急
激な単価低下(CPU、Memory、HDD)が起きた
4. クラウドの台頭(安価なハードウェアを大量に
用意するタイプのパブリッククラウド)
2012/5/10 (C) ReedRex Co,. LTD. 4
- 5. 永続化ストレージの2極化
コスト 構造化データ(関係モデル)
ファイルシステム
大容量 トランザクション
柔軟な問い合わせ
SQL
単純さ データの一貫性
扱い易さ セキュリティ
スループット
スケーラビリティ 可用性
2012/5/10 (C) ReedRex Co,. LTD. 5
- 7. ハードウェアのコモディティ化
• 1992年
Windows 3.1, OS/2 2.0, 486 DX2 66MHz, HDD
100MB
• 2012年
Windows 7, Mac OSX, Linux, 2GHz Multi Core, HDD
数100MB~
• パブリッククラウド -- Amazon, Google, Azure
コモディティ化された低価格なハードウェアを大量
に用意してサービスを提供
2012/5/10 (C) ReedRex Co,. LTD. 7
- 11. Gapを埋めるNoSQL
NoSQL A
コスト 構造化データ(関係モデル)
ファイルシステム
トランザクション
NoSQL C
大容量
柔軟な問い合わせ
SQL
単純さ
データの一貫性
扱い易さ セキュリティ
スケーラビリティ 可用性 B
NoSQL
2012/5/10 (C) ReedRex Co,. LTD. 11
- 12. SQL vs NoSQL ?
• 「SQL」→SQLを問い合わせに使うRDBMS
• 現在の関係データベース管理システムRDBMSは機能が豊富
• 関係モデル
• Codd's 12 Rules
• Transaction 処理
• ACID トランザクション、並行処理時での分離
• Query の最適化
• データの完全性
• 物理・論理データの独立性
• セキュリティ
• リカバリー
2012/5/10 (C) ReedRex Co,. LTD. 12
- 13. Alternative SQL としてのNoSQL
• 用途を限定すれば、SQLの全機能はいら
ないのでは?
• 使わない機能に払っている隠れたコスト
がある
NoSQLは、SQL以外の代替手段を考えよう
というムーブメント
2012/5/10 (C) ReedRex Co,. LTD. 13
- 14. NoSQLもいろいろある
• Write Opの同期性
• DISKやReplication先に同期で書くか、
• ジャーナルログを持つか
• 耐障害性
• トランザクションのレベル
• 複数同時アクセス時の一貫性があるか
• Queryの柔軟性がどこまであるのか
• 可用性、対障害性をどう考えるか
• スケーラビリティをどう担保するか
2012/5/10 (C) ReedRex Co,. LTD. 14
- 15. Gapを埋めるNoSQL
構造化データ(関係モデル)
コスト
柔軟な問い合わせ パフォーマンス
単純さ
MongoDB
セキュリティ
SQL
スケーラビリティ
大容量
Bigtable/Azure Table可用性
データの一貫性
扱い易さ
トランザクション
2012/5/10 (C) ReedRex Co,. LTD. 15
- 16. 典型的な例
• Bigtable-like
• 動機:Googleの検索、gmail など
• Pros:大量データの保持、トランザクション
• Cons:高レイテンシー、
• Casandra
• 動機:Facebook で検索のために開発
• Pros:大量データの保持、リアルタイムな更新、結果整合性
• Cons:一貫性、トランザクション
• MongoDB
• 動機:DoubleClick のメンバーが中心となって開発
• Pros:Read パフォーマンス、柔軟なIndex,Query柔軟性
• Cons:一貫性、トランザクション
2012/5/10 (C) ReedRex Co,. LTD. 16
- 19. 注目すべき特性
GAE Datastore/Azure Table
2012/5/10 (C) ReedRex Co,. LTD. 19
- 20. Bigtable-like / GAE Datastore, HBase, Azure
Table
とても似てる
• GAE Datastore
• Google App Engine Datastore, Bigtableがベース
• Windows Azure Table
• Microsoft の実装のBigtable
• HBase
• Bigtable clone、Apache HBase
2012/5/10 (C) ReedRex Co,. LTD. 20
- 21. GAE Datastore/Azure Table 共通の特徴(1)
1. 分散データストア
2. Key/Value Store
3. トランザクション(制限あり)
4. 追記型(LSM-tree)
5. 複数ストレージへの書き込みでバックアッ
プを作成している
6. データセンターを跨ったリプリケーション
をしている
2012/5/10 (C) ReedRex Co,. LTD. 21
- 22. GAE Datastore/Azure Table 共通の特徴(2)
1. 複数エンティティのトランザクション処理
2. 高いコンカレンシー
3. 書き込みはDISKと同期、replication 先も同
様
4. 高いスケーラビリティ
5. 高いレイテンシー
6. 制限されたQuery
2012/5/10 (C) ReedRex Co,. LTD. 22
- 23. Bigtable と Azure Table の基本の比較
基本構成
Azure Table は、 Bigtable とGFS の組み合わせに類似し
ている。
(1) GFS ではレプリカ間の緩やかな整合性が許可され、
すべてのレプリカのビット単位の同一性を保証して
いないが、Azure Table はこれを保証
(2) Bigtable はtabletの書き込みの コミット ログを2 つ
の GFS ファイルに並行して書き込むことで GFS の
障害を回避。Azure Tableでは Stream Layerの
Journaling で耐障害性を担保
2012/5/10 (C) ReedRex Co,. LTD. 23
- 25. ポイント
• 分散ストレージ vs.トランザクション
同一ロケーションのトランザクションが基
本
分散トランザクションはコストが高い
(☓Azure Table)
• 高コンカレンシー vs. 高レイテンシー
複数のリクエストを同時に発行して処理全
体の時間を短縮
2012/5/10 (C) ReedRex Co,. LTD. 25
- 26. トランザクション
どちらも、Entity Group Transaction と呼ばれ
るトランザクションをサポート
• GAE Datastore
同一 Entity Group に属する複数のEntity をト
ランザクション処理可能
• Azure Table
同一 Table, PartitionKeyのデータは、 トラン
ザクション処理可能
2012/5/10 (C) ReedRex Co,. LTD. 26
- 27. Data Location – 配置
データの配置のモデルが重要
分散ストレージにどのようにデータを配置するか。分散トランザク
ションにしないため、同じロケーションであることが必要
• Bigtable
エンティティ作成時に親となるエンティティを決めて、Entity Group
を作成。同一Entity Groupは、同じロケーションに配置される。
• Azure Table
エンティティ、作成時に、Table, PartitionKey で指定。両者が同じエ
ンティティは、同じロケーションに置かれる。
2012/5/10 (C) ReedRex Co,. LTD. 27
- 29. Google App Engine Datastoreと、Azure Tableの違い
相違点
2012/5/10 (C) ReedRex Co,. LTD. 29
- 30. 5つの違い
1. Secondary index
別記
2. Cross group transaction
GAE Datastoreだけにある。参加できるグループは5つまで
3. 3. Backup/restore
GAE Datastoreだけにある。
4. 4. Transactional Task Enqueuing
GAE Datastoreだけにある
https://developers.google.com/appengine/docs/go/datastore/transactions?
hl=ja#Transactional_Task_Enqueuing
5. 分離と整合性
別記
2012/5/10 (C) ReedRex Co,. LTD. 30
- 32. Entity Group 内の並列性
• GAE Datastore
同一Entity Group内では同時には1つのトラ
ンザクションしか実行されない。同一Group
内は分離レベルSERIALIZABLE
• Azure Table
同一 Table, Partition Key 内のトランザク
ションはスナップショットアイソレーショ
ンで実行。分離レベルREAD COMMITTED
2012/5/10 (C) ReedRex Co,. LTD. 32
- 35. Azure Table3つの魅力
1. PaaS(Platform as a Service)
使った分だけ従量制で課金、インストール、運用の手間が無い
必要に応じて任意のスケールテストが可能
常時3台のバックアップと自動フェイルオーバー
2. 一貫性保障の構造化データストア
トランザクション処理をサポート
高いスケーラビリティ
3. 低コスト
¥0.88/ストレージ トランザクション 10,000 回
¥10.93/GB/月
© Reed Rex Corp. 35
- 36. データモデル ー 方針
単一テーブルに複数クラスを入れる
Table Name 内容
MetaData オブジェクトのメタデータ(予約)
Data オブジェクトのデータ
Index インデックス
Log APIログなどのデータ
2012/5/10 (C) ReedRex Co,. LTD. 36
- 37. データモデル ー データの格納
• Person, Friends, Paymentsなどのアプリケーショ
ンのファーストクラスオブジェクトはDataに入る
• Data内には複数のClassのインスタンスが入るの
で、Typeで区別を付ける(Typeは、Rowkeyの
prefixに)
• Indexには、Entity Groupを跨ったsecondary
indexを入れる。
注:同一Entity Group 内に入るIndexはDataへ
• Logは、APIのログなどログデータを年月をキー
にして入れる。
2012/5/10 (C) ReedRex Co,. LTD. 37
- 38. Entity Group とは?
• 関連性の高いデータが同一Entity Group にな
るようにする。
• Entity Group=分散の単位
• Entity Groupが大きいと上手く分散されない
• Entity Groupが小さすぎると、分散トランザ
クションが頻発してパフォーマンスが出な
い
• Entity Groupの決め方が重要
2012/5/10 (C) ReedRex Co,. LTD. 38
- 39. Entity Group
• Entity Group=同一テーブル、Partitionkey
• ユーザー毎にPartitionkeyを決めて、
「Table」Dataに入れる
• ユーザー内の処理はトランザクションで処
理、ユーザー間の処理は分散トランザク
ションで処理
※コンシューマー向けのシステムでは最初に検
討すべきパターン
2012/5/10 (C) ReedRex Co,. LTD. 39
- 41. 疑問
• パーティションを分けることで分散スト
レージとして利用できる
?
• どれぐらいパーテーションを分割しても
大丈夫なのか
2012/5/10 (C) ReedRex Co,. LTD. 41
- 43. データ件数と処理時間遷移
100 2000
90 1800
80 1600
70 1400
Throughput [Entities/s]
60 1200
Avg [ms]
50 1000
40 800
Avg
30 600
Throughput
20 400
10 200
0 0
0 50 100 150 200 250 300 350 400
Data Count In Storage [x106]
© Reed Rex Corp. 43
- 44. 実装上の工夫
• パーティションを跨いだ処理
ユーザー毎にパーティションを分けると、月次の売上処理が遅く
なる。
• 多くのパーティションをまたぐので
• 別テーブルを作る
売上用の月次、日時で、パーティションを切ったテーブルを別途
用意して書き込む
• 別トランザクションにする
Azure Queueを使って別途行う。
• パーティションを跨いだトランザクションはサポートされていない
• 集計データなので同期で書きこむ必要はない(=レスポンスを早く返せ
る)
© Reed Rex Corp. 44
- 46. ポイント
• Azure Tableは大量のパーティションを扱う
ことができる
• パーテーションを分散することで、パ
フォーマンス劣化無しで、大量データが扱
える
• コストは、トランザクション単価+スト
レージ使用料の従量制
• パーティションを跨いだ処理は別途データ
を用意する
© Reed Rex Corp. 46
- 47. mixi xmas 2011
日本最大規模のソーシャルイベン
ト
11/30 ~ 12/25 の期間に利用可能
な、アプリ上でくつしたを飾っ
て、友人のベルを鳴らし合った
り、イベントに参加したりするこ
とでレベルアップ、プレゼントに
応募できる仕組み
また、mixi の決済機能を用いて、
友人へギフトを送ったりすること
ができる機能もある
2009/2010は、GAE
2011は、Windows Azure でサービ
ス提供
2012/5/10 (C) ReedRex Co,. LTD. 47
- 49. 課題
1. ストレージへのピーク時のアクセスの軽減
• ピーク時の想定アクセス数からストレージへのア
クセス頻度を計算するとAzure Storageのパ
フォーマンス目標値を超える
2. レスポンスの改善
• 必要な、mixi api のアクセス、ストレージのアク
エス数からレスポンスタイムを計算すると規定の
時間を超える
2012/5/10 (C) ReedRex Co,. LTD. 49
- 50. 対策(1) memcachedの利用
• memcachedと、K/V Sは相性が良い
• Readは、どちらもKeyでValueを持ってくるだけ
• Writeは、Keyを使って、Valueを更新するので書
き込みをフックしてmemcached側をメンテする
ことが可能
• SQLだとselectや、updateが柔軟すぎてエンティ
ティのキャッシュは難しく、Query(SQL文)を
キーにして結果をcacheすることになる。更新側
をフックしてcacheをメンテするのも難しいの
で、cacheの有効性が低くなりがち。
2012/5/10 (C) ReedRex Co,. LTD. 50
- 53. ポイント
• Windows Azure Storage にはパフォーマン
ス上限がある
• memcached を使うことでストレージへのア
クセスが減らせる
• K/V Sは、memcached と相性が良く、同期
が取りやすい
• Storageのチューニングはrequestを見てやる
のが基本
2012/5/10 (C) ReedRex Co,. LTD. 53
- 54. sociobridge
Facebookページ統合運用管理ツール
投稿管理
「内容作成」「公開承認」など運用管理
フロー内での作業範囲に合わせて、各担
当者別に権限を設定可能
投稿監視
管理画面上でタスクの依頼も設定でき、
担当者間の連携が可能
オリジナルページ
ユーザーとのコミュニケーションを活性
化させるオリジナルページの生成が可能
Windows Azure Platformを利用
2012/5/10 (C) ReedRex Co,. LTD. 54
- 56. Windows Azure Table/Blobを利用
• パーテーション
• サブスクリプション毎に分割
• Entity Group Transactionが必要なデータは、
同一Tableに保存
• Secondary Indexは自前で実装
2012/5/10 (C) ReedRex Co,. LTD. 56
- 59. モデル ー マルチテナント
• テナント毎にパーテーションを分割
Entity Group が Subscription になるよう
に
• 不特定多数のユーザーからのアクセス
は、Blobで担保
2012/5/10 (C) ReedRex Co,. LTD. 59
- 60. トランザクション
• 一括書き込みのパフォーマンス向上にBatch
Requestを多用
• Azure TableのEntity Group Transaction は、http
POSTの content-type multipart/mixed。
• 2つの特性がある
1. ACIDトランザクションで実行
2. ラウドトリップタイムの削減
• 複数のSaveChanges()を集約することで、リクエ
スト数を少なくしてパフォーマンスが向上
2012/5/10 (C) ReedRex Co,. LTD. 60
- 61. End
ご清聴ありがとうございました。
2012/5/10 (C) ReedRex Co,. LTD. 61