每個實體組實際上就像一個小的數據庫，在實體組內部提供了完整的序列化ACID語義（Serializable ACID Semantics)支持。
Megastore提供了三種方式的讀分別是current、snapshot和。其中current讀和snapshot讀總是在單個實體組中完成的。在開始某次current讀之前，需要確保所有已提交的寫操作已經全部生效，然后應用程序再從最后一個成功提交的失誤時間戳位置讀取數據。對于snapshot讀，系統取出已知的最后一個完整提交的事務的時間戳，接著從這個位置讀數據。和current讀不同的是，snapshot讀的時候可能還有部分事務提交了但未生效。inconsistent讀忽略日志的狀態(tài)直接讀取最新的值。這對于那些要求低延遲并能容忍數據過期或不完整的讀操作是非常有用的。
Megastore事務中的寫操作采用了預寫式日志（Write-ahead Log),也就是說只有當所有的操作都在日志中記錄下后寫操作才會對數據執(zhí)行修改。一個寫事務總是開始于一個current讀以便確認下一個可用的日志位置。提交操作將數據變更聚集到日志，接著分配一個比之前任意一個都髙的時間戳，然后使用Paxos將數據變更加入到日志中。這個協議使用了樂觀并發(fā)（OptimisticConcurrency):盡管可能有多個寫操作同時試圖寫同一個日志位置，但只會有1個成功。所有失敗的寫都會觀察到成功的寫操作，然后中止并重試它們的操作。
一個完整的事務周期要經過如下幾個階段。
(1)讀：獲取最后一次提交的事務的時間戳和日恚位置。
(2)應用邏輯：從Bigtable讀取并且聚集數據到日志入口。
(3)提交：使用Paxos達到一致，將這個入口追加到日志。
(4)生效：將數據更新到Bigtable中的實體和索引。
(5)清除：清理不再需要的數據。
Megastore中事務間的消息傳遞是通過隊列、（Queue)實現的，圖2-23顯示了這一過程。
Megastore中的消息能夠橫跨實體組，在一個事務中分批執(zhí)行多個更新或者延緩作業(yè)(Defer Work)。在單個實體組上執(zhí)行的事務除了更新它自己的實體外，還能夠發(fā)送或收到多個信息。每個消息都有一個發(fā)送和接收的實體組：如果這兩個實體組是不同的，那么傳輸將會是異步的。雖然這種消息隊列機制在關系型數據庫中已經有了很長的應用歷史，Megastore實現的這種消息機制的最大特點在于其規(guī)模：聲明一個隊列后可以在其他所有的實體組上創(chuàng)建一個收件箱。
除了隊列機制之外，Megastore還支持兩階段提交（Two-phase Commit)。但是這會產生比較高的延遲并且增加了競爭的風險，一般情況下不鼓勵使用。
