More Related Content
Similar to Data consistency 入門 data partitioning ガイダンス
Similar to Data consistency 入門 data partitioning ガイダンス (20)
More from Masayuki Ozawa (14)
Data consistency 入門 data partitioning ガイダンス
- 3. お話しさせていただく範囲
•DataConsistency 入門
–データの整合性
•Data Partitioning ガイダンス
–データの分割
•パッと見、データベースのガイダンスのようにとれる かもしれませんが、データベースに限定される概念で はありません。
•情報(データ)を更新する場合に適用できるデザインパ ターンです。
•各パターンのポイントをざっくり紹介いたします。
3
- 5. Data Consistency とは？？
•Data Consistency
→ データ整合性
–結果に矛盾のないデータとなっている
•二種類の整合性モデルの紹介
–強い整合性(Strong Consistency)
–結果整合性(Eventual Consistency)
5
- 8. 処理の一例
8
データA
データB
データC
データD
処理A
4 つのデータ(項目)
が更新できたら
処理を完了
- 9. 強い整合性
9
データA
データB
データC
データD
処理A
処理B
処理Aの一連の流れが
完了していないため、
同一のデータを使う
処理Bの要求がブロック
※RDBMSではロックの競合
処理が完了しておらず整合性が取れていない、 データにはアクセスができない
- 10. センターB
センターA
複数の拠点間のデータを利用
10
データA
データB
データC
データD
処理A
ネットワーク遅延
ネットワーク障害
処理B
障害の状況により
データにアクセスできない 期間が長くなる可能性がある
センターBの応答停止が 長い場合には、手動でロー ルバックする等も検討
- 11. データストアB
データストアA
異なるデータストアを利用
•データを複数のデータストアに分散してもよい
–データストア→データベースに限定されない。
11
データA
データB
処理A
データC
異なるデータストアを
またがるトランザクション をサポートしているか??
そもそも強い整合性が
サポートされるか?
- 15. 結果整合性
15
データA
データB
データC
データD
処理A
A~Dの更新が終わらなくても データへのアクセスを許可
一部のデータの更新の状態でも
データへのアクセスを許可する
- 16. 結果整合性
16
データA
データB
データC
データD
処理A
処理B
複数のデータの更新をもって処理を 完了とする場合でも途中でアクセス可能
このデータの更新は
まだ未完了
- 18. 結果整合性
18
データA
データB
データC
データD
処理A
一連の処理が終了
その結果は矛盾していない??
処理を完了
- 19. 結果整合性
19
データA
データB
データC
データD
処理A
その結果は矛盾していない??
失敗の内容に基づいて 処理を実施
一連の処理が終了
最終的に処理の整合性を担保し
矛盾のない状態にする
- 23. Data Partitioning とは??
•パーティショニング
–データを特定の分割単位で複数のデータスト アに分散して格納する
–複数のデータストア
•同一の筐体の異なる論理領域
•異なる筐体の領域
•異なる種類のデータストア
23
- 26. スケーラビリティの改善
26
H/W
データ
H/W
データ
H/W
データ
H/W
データ
スケールアップ
いずれ
スケールアップ 限界に到達する
パーティションに分割し
異なるH/Wに配置
(スケールアウト)
- 27. パフォーマンスの改善
27
パーティション1
データA
パーティション2
データB
データA
データB
処理
処理
パーティション単位に
並列に実行
パーティションに応じてデータを 配置する場所を分散できる
-マスターは1 拠点で集中管理
-トランザクションは処理に近い場所で管理
- 28. データストアB
可用性の改善
28
データストア
データA
データB
処理
データストアA
データA
データB
処理
ログデータ
マスター
最新のトランザクション
データストアの停止が
すべてのデータに波及
H/W 障害
計画メンテナンス
一部のデータストアの
データにのみアクセス ができない状態
- 29. パーティションB
セキュリティの改善
29
データストア
セキュリティ レベルA
セキュリティ レベルB
セキュリティ設定の境界が
データストア(パーティション)の
場合にデータの重要度に応じた
セキュリティ最適化が煩雑に
パーティションA
セキュリティ レベルA
セキュリティ レベルB
セキュリティの個別最適化が
柔軟に行える
- 30. 運用の柔軟性
30
データストア
データA
データB
パーティション1
データA
パーティション2
データB
データストアがバックアップ
リストア境界の場合、
データBのみバックアップ
するのが難しい
パーティション(データストア)
単位でのバックアップ
リストアを実施可能
-メンテナンス単位
-コストの低いストア
-監視レベルの変更
-異なる種類のストア
- 34. 水平分割
34
同一のスキーマ
パーティション(シャード) キーに基づいて分割
-レンジ
-ハッシュ
シャード
シャード
SQL Database では
ElasticScalePreview
- 35. 水平分割の考慮点
35
•負荷を均等にするためには特定のシャードに データが偏らないようにする
•定期的なシャードのメンテナンス
•分割の定義を更新する必要があるか
•既存シャードの分割/結合の必要性
•シャードをホストするサーバーのスケール上限 に達しないように注意
•スケールアップ上限
•シャード数の上限
•全シャードに保持しておきたい情報の管理
•マスターテーブルの最新化
Azure Subscription and Service Limits, Quotas, and Constraintshttp://azure.microsoft.com/ja-jp/documentation/articles/azure-subscription-service-limits/
- 37. 垂直分割
37
異なるスキーマ
利用パターン(例: 頻繁に一 緒に利用される項目) に基づ いて分割する
-商品の基本情報(名称/金額)
-在庫/最終注文日
-拡張テーブル
機密性の高い情報を分割する
-カード番号
-セキュリティコード
一つのエンティティ(実体) を
複数のエンティティに部分的に正規化
- 38. 垂直分割の考慮点
38
•頻繁に検索される項目のサイズを小さくする
•分割をしすぎて、頻繁に複数の項目を合わせないと一つの情報 をなさないのでは効果が薄い
•変更の頻度を考慮
•変更の少ない項目と多い項目を分割する。
•変更の少ない項目: マスター用途で参照が多い
•変更の多い項目: トランザクション用途で参照が少ない
•情報の重要性
•データの重要性によってセキュリティレベルを変更する
•カード情報
•セキュリティ番号
- 40. 機能分割
40
在庫データ
顧客データ
トランザクション
ヒストリー
マスター
データをコンテキストまたは
サブドメインにより分割
- 41. 機能分割の考慮点
41
•サイズに応じてデータストアのスケールを変更
•データのコンテキストによってデータストアの性 能を調整することが可能
•データサイズの上限に注意
•コンテキスト単位でデータを分割するため、トラ ンザクション系のデータについては必要となる データストアのサイズが大きい可能性がある
•ノードで許容される上限に注意する
•求められる性能に応じて他の分割と併用も検討
•機能分割+ 水平分割
- 46. 可用性の向上
•パーティション単位で最適化
–データストアの配置場所の拠点のオフピーク時間帯で実施
•オフピーク時間帯でメンテナンスが実施できるか?
–複製対象/ 複製頻度の調整
•重要なデータのみを短い頻度で複製
•障害発生時のアクセス不可能なデータの最小限化
–障害が発生しているパーティションのデータのみアクセスをすること ができない
–特定のパーティションのみを復元
•運用粒度の最適化
–重要なデータが格納されているパーティションを高品質なデータスト アに配置
–パーティションによって監視レベルを変更
46
- 48. もっと詳しく知りたい方は
48
• ペーパー
• Kindle
• PDF
各種取り揃えています!!
Cloud Design Patterns: Prescriptive Architecture Guidance for
Cloud Applications
http://msdn.microsoft.com/en-us/library/dn568099.aspx
