徐老师好，Megastore的实体组数据通过行键顺序存储，一个实体组会被分成多个分区，这些分区分布在不同的服务器上，所以操作实体组时，需要使用chubby提供分布式事务。我认为事务日志应该存储在GFS上，日志数据应该尽可能满足本地写入，也就是一个Block由一个服务器负责写入。在事务提交的5个步骤的第1步提到“我们先要获取到时间戳，以及最后一次提交的事务的日志的位置”，这样可以让已经加载了Block的服务器来写入事务日志。

MegaStore 是事务机制是用的 Percolator 吗

Photo 表本身能为 id 创建单独的全局索引吗？如果不能的话，那我觉得这其实就是个文档数据库，Photo 其实就是 User 下面的一个 Nested Object 而已，并不是真正意义上的独立表。所谓的实体，其实就是一个 Document 而已，这样认知更容易理解吧。

另外，全局索引是弱一致的，也就是说可能发生数据写入成功，事务也提交成功，但是就是查询不到的情况，是吗？

Megastore 的 prejoin 机制，如何解决实体组数据会增加的问题呢？比如一开始只写入了一个 User，以后慢慢的为其增加关联的 Photo，这种情况下，如何预先为 Photo 分配空间来实现 prejoin 呢？

索引优化这里的第一点，在索引中添加数据，这个做法目前在文件系统中也有，如果文件数据很小，例如只有1kb，那么完全可以在文件头部的header结构体中直接保存数据，也就是extend list block和gang block的概念出现，但是这里的限制就是对数据量有限制，不知道数据库的这个索引优化会不会也是这样。 当然，这样做了以后，在代码层面和功能实现方面也有了一些麻烦点，例如以前遍历数据的时候，是找到文件的header头部信息之后一层层访问的，但是现在不用了，需要做很多工程上的条件判断。算是一种特殊情况。而且数据库这样的做法，感觉会更加繁琐。

事务提交带上时间戳的这个特性，会隐藏依赖时间同步，如果节点的时间没有同步的，那么可能会出现问题。当然比较可靠的方法是依赖version版本的，每次事务先给你当前的版本，然后提交的时候就直接递增，但是如果发现服务端的版本更大，那么就需要拒绝该事务重新刷新数据了。

Hbase 也支持这些功能了吧？

徐老师建，Megastore的数据通过实体组分区后，所有的事务日志都与实体组关联的。日志数据应该与分区实体靠近，数据应该写到GFS上，并且与实体的分区规则一致。