脳みそスワップアウト

揮発性なもので。おもにPHPのこととか。

BASEトランザクションとCAP定理

BASEトランザクションとCAP定理

クラウドや分散システムで使われる用語

BASEトランザクションとは

  • Basically Available
    • 可用性が高く常に利用できることを重視。
    • 楽観ロックやキュー。
  • Soft State
    • あるノードの状態はその内部に埋め込まれた情報によって決まるものではなく、 外部から送られた情報によって決まるという状態の考え方
  • Eventual Consistency(結果整合性)
    • 一時的に整合性が満たせない状態が起きるが、 ある一定の期間が経てば満たせるようになる、こと。
    • DNSやNTPなど。

CAP定理とは

以下の3つのうち、2つまでしか満たせないという定理。

  • Consistency(整合性)
  • Availability(可用性)
  • Partition(分散)

システムへの要求によって選択する必要があり、クラウドの場合はAとPは必須となる。 厳密なConsistentは満たすことができないが、少し緩めて、結果整合性なら実現できる。

  • 複数のレプリカノードにデータ送信時
    • いくつかノードで何らかの事情で書き込みに失敗した
    • すべて書き込みには成功したが、同時に終わったわけではない

STUPID

良くないコードの兆候

  • Singleton (シングルトン) ※古典的なパターン
  • Tight Coupling (密結合)
  • Untestability (テスト不能)
  • Premature Optimization (時期尚早な最適化)
  • Indescriptive Naming (説明的ではない名前)
  • Duplication (重複)

illuminate/database

私の携わったプロジェクトではORMが採用されないケースが多い。
メリットデメリットともにあるし、向き不向きもあるし、アレルギーを持ってる人がいたりするし、論争に興味もないのでそれ自体はいいのだけど、
たとえORMを使わない場合でも、クエリビルダだけは欲しいと思うことが多々ある。

「col1 = 'A' AND col2 = 'B'」のような同じ抽出条件が何度も出てきて、
それをベースにさらにwhere句を追加したSQLを書くような場合、
頻繁に出てくるwhere句を共通化したいのだけど、
文字列でSQLを組み立てているとだんだん訳が分からなくなってくる。

要はSQLの組み立てを構造的に行いたいのだ。
ORMはクエリビルダの機能を含んでいることが多いので、そこだけ使うことができないか調べてみた。

続きを読む