Googleは，自社内で使用中のMesaという，新しいデータウェアハウスシステムの資料を公開した。Mesaは複数のデータセンタにスケールして，ペタバイト単位のデータを扱うと同時に，秒以下の単位でのクエリ応答とACID特性を実現する。
Mesaは主に，Googleの広告関連のユースケースを中心として設計された。Googleによると，同社の広告プラットフォームは拡大を続けていて，ユーザは広告キャンペーンのさらなる可視化を求めている。より詳細で粒度の低いデータへの要望は，データ量の驚異的な増加に結び付いている。Googleは，増加の一途をたどるデータ容量を処理すると同時に，データの一貫性の提供と準リアルタイムのデータクエリを可能にするために，Mesaを開発した。Googleの公式資料の言葉を引用すれば，Mesaの要件は次のようなものだ。
アトミックなデータ更新。リレーションデータのレベルでは，単一のユーザ操作が複数のアップデートを引き起こす場合があります。これは，(広告主や国を単位とする)ディメンジョンのセット間のメトリックス(クリック数やコストなど)セットに対して定義された一貫性のあるビューに，数千という単位で影響を与える可能性があります。更新処理が部分的に適用されているだけの状態で，システムが参照されることが可能であってはなりません。
一貫性と正確性。ビジネスと法的な理由から，このシステムは一貫性を持った正確なデータを返す必要があります。クエリに複数のデータセンタが関与する場合であっても，強力な一貫性とクエリ結果の再現性が求められます。
可用性。システムに単一障害点があってはなりません。データセンタ全体，あるいは地理的なリージョンに影響するサービス停止を伴うような，計画的ないし計画外のメンテナンスや障害によるダウンタイムは許されません。
リアルタイムに近い更新スループット。このシステムは，毎秒数百万行というオーダの更新容量で，既存行への増分更新と新規行追加のいずれにおいても，継続的な更新処理をサポートする必要があります。更新の結果は数分以内に，別のビューや他のデータセンタからも，一貫性を保って照会可能でなければなりません。
クエリのパフォーマンス。システムは，非常に低レイテンシなライブユーザレポートを求めるレイテンシ重視のユーザと，非常に高いスループットを要求するバッチ実行ユーザをサポートしなければなりません。システム全体としては，99%のクエリを100ミリ秒のレイテンシでサポートすると同時に，１日あたり数兆行のフェッチが可能なクエリスループットをサポートする必要があります。
スケーラビリティ。システムはデータサイズとクエリボリュームの両面でスケーラブルでなくてはなりません。例えば数兆行で構成された，ペタバイト単位のデータを扱う必要があります。これらのパラメータが大きく増加したとしても，更新とクエリのパフォーマンスは同等を維持しなくてはなりません。
オンラインデータとメタデータの変換。新機能のローンチや既存データの粒度変更をサポートするため，クライアントでは多くの場合，データスキーマの変換や既存データボリュームの修正が必要になります。このような変更が，通常のクエリや更新操作を妨害することがあってはなりません。
Googleによれば，既存のビッグデータテクノロジで，これらの要件をすべて満たすものはひとつもない。BigTableはアトミック性と強い一貫性を提供しない。Megastore, Spanner, F1は地理的にレプリケートされたデータ間の一貫性を保証しているが，いずれもMesaクライアントに必要な更新スループットの最大値をサポートしていない。
ただしMesaは，インフラストラクチャのさまざまな部分でGoogleのコンポーネントを活用している。すべてのメタデータの永続化にはBigTableを，データファイルの保存にはColossus(Googleの分散ファイルシステム)を使用する。さらにシーケンシャルデータの処理にはMapReduceを活用している。
Mesaの概念的データモデルは，従来のリレーショナルデータベースに近い。データはすべてテーブルに格納される。テーブルは他のテーブルのマテリアライズドビューであってもよい。各テーブルには，その構造を規定するスキーマがある。広告目的では"いくつあるか"というような問い合わせが一般的であることから，"SUM"のような集約関数をテーブル定義内で指定することが可能になっている。スキーマでは，１つないし複数のインデックスをテーブルに定義することも可能だ。
Mesaで興味深い部分のひとつは，その更新処理の方法だ。Mesaのデータはマルチバージョンで格納されている。新たな更新処理を実行中であっても，それ以前の状態の一貫性データを提供することが可能だ。上流システムでは通常，数分に１回の割合で，バッチ処理によって更新データを生成する。Mesaの実行中は，独立したステートレスなコミッタインスタンスが，すべてのデータセンタを対象に更新処理のコーディネートを行う。コミッタはそれぞれのバッチに新たなバージョン番号をアサインした上で，更新に関係するすべてのメタデータを，Paxos合意アルゴリズムに基づいて構築されたバージョンデータベースに公開する。コミット基準に到達すると，コミッタはその更新が世界中の十分な数のMesaインスタンスに反映されたものと判断して，更新のバージョン番号をコミットバージョンとして宣言し，その値をバージョンデータベースに格納する。クエリは常に，そのコミットバージョンに対して発行される。
クエリが常にコミットバージョンに対して発行されるため，Mesaでは更新とクエリの間でロックを取る必要がない。更新処理はMesaインスタンスによって，バッチで非同期的に適用される。これらのプロパティによってMesaでは，クエリと更新の高いスループットを実現すると同時に，データの一貫性を保証している。
Googleは，Mesaの更新とクエリのパフォーマンスを示すベンチマークを提供している。サンプルデータソースでは，平均で毎秒30～60MByteの圧縮データの読み込み，3～600万の異なる行の更新，30万行の新規追加を行う。Mesaは1日当たりおよそ5億のクエリを実行して，1.7～3.2兆行の行を返却している。平均遅延時間は10msで，99%の遅延時間は100ms以下だ。
Googleによれば，Mesaに格納されているデータの容量は，この２年間で５倍に増加したという。つまりMesaはGoogle社内で，少なくともこの期間は実運用されてきたということになる。
Mesaについて詳しく知りたいのであれば，GoogleのMesa white-paperが参考になるだろう。