ＮＨＮカンファレンスでもらったHBaseの本を、ざっと斜め読みして、適当にまとめるシリーズ「HBaseを読む」の続きです。
ちゃんとした情報を知りたい人は、HBaseの本を見てください。
今回は、１．１、１．２章
■１．３ 非リレーショナルデータベースシステム、
Ｎｏｔ−Ｏｎｌｙ ＳＱＬあるいはＮｏＳＱＬ？
・ここ４、５年の間、この問題領域のイノベーションのペースは
ゆっくりしたものから、信じがたいほど速いものになった
→ＮｏＳＱＬソリューションの到来
→Johan Oskarssonの問いに答えて、
Eric Evansが生み出した用語
→特定の問題群に異なるデータストアアーキテクチャ
以前からあった：Berkeley DBなど
・新しいストレージシステムの多くはクエリの手段にＳＱＬが
提供されていなかった
→もっとシンプルなＡＰＩ
→ＳＱＬの方言を提供するツールが使えることがあり
→すでにクエリを行う制限はＲＤＢＭＳと
差異がなくなっている
・差異はもっと低レベルにある
→スキーマ、ＡＣＩＤのようなトランザクション
→スケーラブルになるとき
トランザクション、セカンダリインデックスをサポートしない
固定的なスキーマを持たない
※コラム：一貫性
・一貫性の強さ
Ｓｔｒｉｃｔ：アトミック
Ｓｅｑｕｅｎｔｉａｌ：あらゆる変更が適用された順番で
Ｃａｕｓａｌ：関連する要因で生じた変更が、順番で
Ｅｖｅｎｔｕａｌ：一定期間更新なければ、最終的には
Ｗｅａｋ：保証されない
・ＣＡＰ定理
分散システムにおいて実現可能なのは、一貫性、可用性、分散耐性
の中の２つまで
・一貫性を緩和し、可用性を高めるというのは、強力な考え
→そうなれば、一貫性はアプリケーションで：複雑さ増す
※コラム：ここまで
・ＲＤＢＭＳでないものはすべてＮｏＳＱＬにされる
→memcachedまで
→技術的可能性をぼやけさせてしまう
・ＮｏＳＱＬには、それぞれのシステムの強みの分類に役立つ多くの
観点がある
１．３．１ 観点
・それらの観点のいくつかを見ていく
データモデル：ＫＶＳ、半構造化の列指向、ドキュメント指向
ストレージモデル：インメモリ、永続型
一貫性→レイテンシーに影響（収穫と生産）
物理モデル：分散型、単独のマシン
読み書きのパフォーマンス
セカンダリインデックス
障害の処理
圧縮
ロードバランス
アトミック名読み出し−変更−書き込み
ロック、ウェイト、デッドロック
・インピーダンスマッチ
ひとつでなんでもまかなうアプローチをとる代わりに
ほかのどんなものが使えるかを知るべき
１．３．２ スケーラビリティ
・ＲＤＢＭＳのパフォーマンス
トランザクション処理には向いている
超大規模な分散処理には向いていない
サーバーを垂直にスケールさせると、十分な効果得られない
トランザクションや並列度に対し、ウェイトやデッドロック
・商用のＲＤＢＭＳ
処理してくれるのは特定の面だけということよくある
とても高価
・リレーショナルな機能をパフォーマンスのために恒久的に犠牲に
するのが、よいことなのか？
・スケーラビリティを実現するものと同じメカニズム
→ＮｏＳＱＬのソリューション
HBaseが提供するのと同じソリューション
１．３．３ データベースの（非）正規化
・大規模システムの場合、スキーマの設計のやり直しを考えないと
いけないことがよくある
→非正規化、複製、インテリジェントキー
・読み出し時にそれ以上集約を行う必要がないように２つ以上の
テーブルにデータを複製
→スキーマを非正規化
必要なビューを事前にマテリアライズ
・旧来のリレーショナルデータベースモデルからHBaseへの列指向の
正確により適しているモデルへの変換
一対一、一対多、多対多の関係をHBaseの下位層のアーキテクチャ
に適合するように変換するには、様々なアプローチがあります
どのアプローチをとるか、HBaseのストレージ設計の潜在能力を
完全に理解しとかなければいけません
・疎で幅の広いテーブルと、列指向の設計がサポートされている
→データを正規化する必要がなくなり、ＪＯＩＮ操作もなくせる
・インテリジェントキーを使う
データがどのように、どこに保存されるかを細かく制御できる
キーの一部分を使ったルックアップが可能
→複合キーと組み合わせて使えば、
属性をインデックスの先頭部分として利用できる
・スキーマを適切に設計すれば、データ数が１０から１千万になっても
読み書きのパフォーマンスが変わらないようにできる
次回は、１．４章
ちゃんとした情報を知りたい人は、HBaseの本を見てください。
今回は、１．１、１．２章
■１．３ 非リレーショナルデータベースシステム、
Ｎｏｔ−Ｏｎｌｙ ＳＱＬあるいはＮｏＳＱＬ？
・ここ４、５年の間、この問題領域のイノベーションのペースは
ゆっくりしたものから、信じがたいほど速いものになった
→ＮｏＳＱＬソリューションの到来
→Johan Oskarssonの問いに答えて、
Eric Evansが生み出した用語
→特定の問題群に異なるデータストアアーキテクチャ
以前からあった：Berkeley DBなど
・新しいストレージシステムの多くはクエリの手段にＳＱＬが
提供されていなかった
→もっとシンプルなＡＰＩ
→ＳＱＬの方言を提供するツールが使えることがあり
→すでにクエリを行う制限はＲＤＢＭＳと
差異がなくなっている
・差異はもっと低レベルにある
→スキーマ、ＡＣＩＤのようなトランザクション
→スケーラブルになるとき
トランザクション、セカンダリインデックスをサポートしない
固定的なスキーマを持たない
※コラム：一貫性
・一貫性の強さ
Ｓｔｒｉｃｔ：アトミック
Ｓｅｑｕｅｎｔｉａｌ：あらゆる変更が適用された順番で
Ｃａｕｓａｌ：関連する要因で生じた変更が、順番で
Ｅｖｅｎｔｕａｌ：一定期間更新なければ、最終的には
Ｗｅａｋ：保証されない
・ＣＡＰ定理
分散システムにおいて実現可能なのは、一貫性、可用性、分散耐性
の中の２つまで
・一貫性を緩和し、可用性を高めるというのは、強力な考え
→そうなれば、一貫性はアプリケーションで：複雑さ増す
※コラム：ここまで
・ＲＤＢＭＳでないものはすべてＮｏＳＱＬにされる
→memcachedまで
→技術的可能性をぼやけさせてしまう
・ＮｏＳＱＬには、それぞれのシステムの強みの分類に役立つ多くの
観点がある
１．３．１ 観点
・それらの観点のいくつかを見ていく
データモデル：ＫＶＳ、半構造化の列指向、ドキュメント指向
ストレージモデル：インメモリ、永続型
一貫性→レイテンシーに影響（収穫と生産）
物理モデル：分散型、単独のマシン
読み書きのパフォーマンス
セカンダリインデックス
障害の処理
圧縮
ロードバランス
アトミック名読み出し−変更−書き込み
ロック、ウェイト、デッドロック
・インピーダンスマッチ
ひとつでなんでもまかなうアプローチをとる代わりに
ほかのどんなものが使えるかを知るべき
１．３．２ スケーラビリティ
・ＲＤＢＭＳのパフォーマンス
トランザクション処理には向いている
超大規模な分散処理には向いていない
サーバーを垂直にスケールさせると、十分な効果得られない
トランザクションや並列度に対し、ウェイトやデッドロック
・商用のＲＤＢＭＳ
処理してくれるのは特定の面だけということよくある
とても高価
・リレーショナルな機能をパフォーマンスのために恒久的に犠牲に
するのが、よいことなのか？
・スケーラビリティを実現するものと同じメカニズム
→ＮｏＳＱＬのソリューション
HBaseが提供するのと同じソリューション
１．３．３ データベースの（非）正規化
・大規模システムの場合、スキーマの設計のやり直しを考えないと
いけないことがよくある
→非正規化、複製、インテリジェントキー
・読み出し時にそれ以上集約を行う必要がないように２つ以上の
テーブルにデータを複製
→スキーマを非正規化
必要なビューを事前にマテリアライズ
・旧来のリレーショナルデータベースモデルからHBaseへの列指向の
正確により適しているモデルへの変換
一対一、一対多、多対多の関係をHBaseの下位層のアーキテクチャ
に適合するように変換するには、様々なアプローチがあります
どのアプローチをとるか、HBaseのストレージ設計の潜在能力を
完全に理解しとかなければいけません
・疎で幅の広いテーブルと、列指向の設計がサポートされている
→データを正規化する必要がなくなり、ＪＯＩＮ操作もなくせる
・インテリジェントキーを使う
データがどのように、どこに保存されるかを細かく制御できる
キーの一部分を使ったルックアップが可能
→複合キーと組み合わせて使えば、
属性をインデックスの先頭部分として利用できる
・スキーマを適切に設計すれば、データ数が１０から１千万になっても
読み書きのパフォーマンスが変わらないようにできる
次回は、１．４章