BASEトランザクションとCAP定理
BASEトランザクションとCAP定理
クラウドや分散システムで使われる用語
BASEトランザクションとは
- Basically Available
- 可用性が高く常に利用できることを重視。
- 楽観ロックやキュー。
- Soft State
- あるノードの状態はその内部に埋め込まれた情報によって決まるものではなく、 外部から送られた情報によって決まるという状態の考え方
- Eventual Consistency(結果整合性)
- 一時的に整合性が満たせない状態が起きるが、 ある一定の期間が経てば満たせるようになる、こと。
- DNSやNTPなど。
CAP定理とは
以下の3つのうち、2つまでしか満たせないという定理。
- Consistency(整合性)
- Availability(可用性)
- Partition(分散)
システムへの要求によって選択する必要があり、クラウドの場合はAとPは必須となる。 厳密なConsistentは満たすことができないが、少し緩めて、結果整合性なら実現できる。
- 複数のレプリカノードにデータ送信時
- いくつかノードで何らかの事情で書き込みに失敗した
- すべて書き込みには成功したが、同時に終わったわけではない
ブライスの法則 (Bryce)
Good Systems Design + Good Programming = Great Systems Good Systems Design + Bad Programming = Good Systems Bad Systems Design + Good Programming = Bad Systems Bad Systems Design + Bad Programming = Chaos
illuminate/database
私の携わったプロジェクトではORMが採用されないケースが多い。
メリットデメリットともにあるし、向き不向きもあるし、アレルギーを持ってる人がいたりするし、論争に興味もないのでそれ自体はいいのだけど、
たとえORMを使わない場合でも、クエリビルダだけは欲しいと思うことが多々ある。
「col1 = 'A' AND col2 = 'B'」のような同じ抽出条件が何度も出てきて、
それをベースにさらにwhere句を追加したSQLを書くような場合、
頻繁に出てくるwhere句を共通化したいのだけど、
文字列でSQLを組み立てているとだんだん訳が分からなくなってくる。
要はSQLの組み立てを構造的に行いたいのだ。
ORMはクエリビルダの機能を含んでいることが多いので、そこだけ使うことができないか調べてみた。