読者です 読者をやめる 読者になる 読者になる

Google Megastore

Google Megastoreについて今更ながら調べたよ

概要

  • 複数レコードで構成されたひとまとまりの"entity group"の中では、トランザクションが可能。entity groupはキー値のprefixを共有。entity groupは階層化されたentityの集合である。entity group毎にトランザクションログが使用される(他の行と同様、永続化・レプリケーションされている)。
  • コミットログのレプリケーションはPaxosプロトコルで実現されており、ACIDなトランザクション
  • カラム指向のDB。
  • entity group内に限って、join操作が可能。entity groupを跨ぐjoinをしたい場合はconsistencyが保証されない。
  • BigTableはインデックスをサポートしない。primary keyでソートされているだけ。Megastoreがインデックスを提供しているが、詳細は不明。倍なりテーブルを用意して、もともとのprimary keyをカラムに入れているようだ。
  • entity groupのコンポーネント間の参照整合性は保証されていない。
  • 多対多のリレーションはサポートされないが、逆関数として保存可能…materialized view?
  • 既に一年ほどサービスで利用実績がある。

TITLE: Megastore – Scalable Data System for User-facing Apps

SPEAKERS: Jonas Karlsson, Philip Zeyliger (Google)

  • 依然、参照系重視だが、多少の更新系機能を追加。スキーマが正しければスケール可能。
  • スケール可能なDB技術を付加: インデクス、スキーマ、データ型、パーティショニング
  • レプリケーション層を隠蔽、DC間フェイルオーバ
  • SQL風の柔軟な宣言型スキーマ言語(MDL)
  • トランザクション
  • rollbackなし、rollforward logのみ
  • entity group内でのみconsistentが保証される
  • 楽観的な隔離性制御
  • api: newTransaction, read/write, commit (pb: couldn’t type fast enough for the details)

  • スキーマで物理的な距離を宣言(prefix, entity group, attributes,...)
  • ディスクseek, RPC, 帯域、ストレージを最適化
  • コストが見えるプリミティブなAPIのみ提供
    • only add scalable features
    • cost of writes is linear to data/indices
    • avoid scalability surprises

  • Paxos-basedなレプリケーションは思ったより複雑になる
  • クエリのフェイルオーバを行う(処理中に死ぬ)

  • どんどん使われている
  • 宣言型スキーマはとてもよい
  • コストが見えるAPIはよい(SQLはコストが見えにくい)
  • joinするな
  • スキーマレビューはよい