--

--

コメント

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
管理者にだけ表示を許可する

この記事のトラックバックURL

http://welcomevac201world.blog84.fc2.com/tb.php/391-e5c4a7b9

06

08

コメント

真面目に考えてるんだけどクラウドサーバ環境に適したDBってなんなの?

Amazon EC2でのMySQLや、GoogleのBigtableを見ていると、
ちょっとした疑問が浮かんでくるんだけど、
言葉にできない。

なんていうのかな、危なっかしいっていうか、
たぶんそれは、今までACIDをきちんと守るように
プログラミングしてきたからなんだと思うんだけど、
実際にAmazonもGoogleも世界一と言っていい大企業。

そこが考えたものにケチをつけるなんて、
個人でいんたーねっとにちょっと詳しいから
企業からお金もらってるエンジニアが言うもんじゃないよね┐(´∀`)┌ヤレヤレ


と、もう一度、DBのお勉強をしているんだけれど、
その中で重要なACID特性についておさらい。
引用しまくり。

e-words
http://e-words.jp/w/ACIDE789B9E680A7.html

ACID特性 【Atomicity Consistency Isolation Durability】
読み :アシッドとくせい

関連する複数の処理を一つの処理単位にまとめて管理するトランザクション処理に求められる4つの特性。“Atomicity”(原子性)、“Consistency” (一貫性)、“Isolation”(独立性)、“Durability”(耐久性)の頭文字をつなぎ合わせたもの。



Wikipedia
http://ja.wikipedia.org/wiki/ACID_(%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E7%A7%91%E5%AD%A6)

Atomicity
トランザクションに含まれるタスクが全て実行されるか、
あるいは全く実行されないことを保証する性質をいう。
日本語ではアトミック性または原子性とも呼ばれる。

口座Aから口座Bに対し1万円送金する場合を考えたとき、
送金操作は次の2操作によって行われる。

1.口座Aの残高から1万円を引く
2.口座Bの残高に1万円を加える

Atomicityが保証されるとは、上の操作1、2が全て行われるか、
あるいは全く行われないことを指す。

どちらか片方だけが実行された場合、
銀行全体の預金残高に矛盾が発生してしまう。

Consistency
日本語では一貫性あるいは整合性とも呼ばれる。
トランザクション開始と終了時に
あらかじめ与えられた整合性を満たすことを保証する性質を指す。

すなわち、データベースのルール、
つまり整合性条件を満たさない状態を起こすようなトランザクションは
実行が中断される。

預金残高を例にすると、
その値は一般的に0あるいは正の値を取る条件を満たす必要がある。
よって、口座Aから送金を行うとき、
その前後でAの口座残高が負になるような額は送金できないようにする。
このようなルールを保証するのがConsistencyの役割である。

Isolation
トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指し、
日本語では分離性、独立性または隔離性ともいう。
より形式的には、isolationとはトランザクション履歴が直列化されていることと言える。

この性質と性能はトレードオフの関係にあるため、
一般的にはこの性質の一部を緩和して実装される場合が多い。

預金残高の例では、
残高100万円の口座Aから残高200万円の口座Bに1万円送金する場合の操作が

1.口座Aの残高から1万円を引く
2.口座Bの残高に1万円を加える

の順序で行われたとする。取りうる内部状態は、

  • 時点
  • 口座A
  • 口座B

  • 送金前
  • 100万円
  • 200万円

  • 実行中
  • 99万円
  • 200万円

  • 送金後
  • 99万円
  • 201万円


の三つになるが、外部からは送金前と送金後のいずれかの状態しか観測できない。

Durability
永続性あるいは持続性と呼ばれる。
トランザクション操作の完了通知をユーザが受けた時点で、
その操作は永続的となり、結果が失われないことを指す。

これはシステム障害に耐えるということであり、
DBMSは整合性制約をチェック済みであり
トランザクションを中止してはいけないということである。

多くのデータベース実装では、
トランザクション操作を永続性記憶装置上にログとして記録し、
システムに異常が発生したらそのログを用いて
異常発生前の状態まで復旧することで永続性を実現している。




秒速何千回、何万回とトランザクションが起こっているであろう
AmazonとGoogle先生なのですが、
どうやってACID保証してるんだろーなー。


で、なにか詳しく書いてるのないかなーってことで、
ぐぐってみると、
こちらの丸山先生?のPDFが紹介されてたので見てみる。
http://qcontokyo.com/tokyo-2009/pdf/GeneralSession-Day2-Maruyama.pdf

(  ´Д`)/ 先生!ちょっとよくわかんないんですけど!


BASEとかCAPとか。

IT業界は日進月歩だわ...(´ー`)y─┛~~


ざっくり言うと、ACIDは大丈夫だってことらしい。

分散させると、処理が大変だけどねってさ。



ACIDは大丈夫だけど、大元になるデータが1個しかないのかなー?

うーん。

分散とかクラウドとか、とにかく用語が先行イメージとして
脳内にありすぎて、本当の情報が遮断されていくぜぃ。

丸山先生の資料に書いてある図を見ると、
データの大元の状態の矢印が1本しかないから、
そこは1なんだろーなー。


でもせっかく分散させてるんだし、
こういうのはどうだろうかという提案。



テーブル定義するときに、

(A)この列のデータはACID保証の数字だよと定義する。
(B-1)このテーブルの行データはDB内でUNIQUEだよっていうのを定義する
(B-2)指定がないときは、時差があると思ってね

としてはどうだろう。


(A)はACIDを保証したい数字形式の列データを持つので、
在庫の管理とかするときに使用する。

例として、100個在庫があったら、
お店に100個ならんでいるんだけど、
分散サーバなので、(い)(ろ)(は)のサーバに
それぞれ33、33、34個展開する。
(い)のサーバは、またそれを、(に)(ほ)にそれぞれ16、17個展開。
それぞれのACIDを保ちつつ、

・0になった時点
・ある一定のタイミング(1時間おきとか?)

に一度データを回収してチェックし、もう一度展開する。


(B-1)はユニークな行データ
パスワードとか個人情報とかを管理したいときに。
これは更新用のトークンを呼びだされるまで、
ひたすら分散せずに待ってる。

あるサーバから問い合わせがあったら、
そのトークンを貸し出す。

あとはひたすら処理が終わるのを待って、
格納。

ここは従来のRDBMSの処理と同じだと思う。


(B-2)はマスタデータとかとか。
どんどん拡散してコピッてキャッシュして。
主に閲覧用。

もしくは、データを積み上げるだけ積み上げていくような
データ。
メールとかかな。


ちょっと思ったんだけど、
DBって、insert、update、delete、selectしかなくて、
Postgresだと、処理的には、insert、update、selectしかないのだけれど、
そうしたら、その3つの処理を分散向けにそれぞれ考えておけば
いいわけじゃない?

そこでACIDを頑張らなきゃいけないのって、
updateだけだよね???


あれ、なんか変なこと言ってる気がするけど、
ちょっとDB設計してみるε≡≡ヘ( ´Д`)ノ
関連記事
スポンサーサイト
管理者にだけ表示を許可する

この記事のトラックバックURL

http://welcomevac201world.blog84.fc2.com/tb.php/391-e5c4a7b9

ようこそ!

ブロとも申請フォーム

ブロ友申請大歓迎です!
一覧に表示されるので自動で相互リンクになります!

>> ブロ友申請はこちら <<

検索フォーム

最近のコメント

メールフォーム

名前:
メール:
件名:
本文:

FC2ブログランキング

人気ブログランキング

人気ブログランキング

ブログ村

アクセスランキング

[ジャンルランキング]
育児
1094位
アクセスランキングを見る>>

[サブジャンルランキング]
パパ育児
80位
アクセスランキングを見る>>

やーんは今、

ブロとも一覧

Designed by

Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。