Readme文档写得真不错，3个问题，希望能够回答

[chenzx]

1、Paxos解决主从复制的性能问题主要就是同步+异步copy相混合吗？如果是这样的话，我觉得实在太简单了。结合MySQL集群里多主情况下的binlog同步，似乎可以对应起来看。但不清楚为什么这个只是用在fe，而不是be？Palo不是MPP OLAP系统吗？数据实时update的需求是怎么回事？不太明白。

2、MVCC更新多个table，升级版本号什么的，感觉说的不怎么清楚。因为像Clojure的STM这种MVCC，如果事务失败的话，是会自动回滚重试的。而像MySQL InnoDB的MVCC实际上又需要加行级锁，所以不清楚MVCC怎么支持大并发的跨表更新事务呢？

3、llvm部分的代码，这个是参考Impala的实现自己定制里一套呢，还是主要照搬Impala的一些实现代码？我看到变量类命名都是palo* 什么的

[imay]

1. 使用BDB JE是解决元数据高可用的。元数据更新量较小使用这种方案，BE我们现在是批量导入方式，所以不适合使用这种一致性方案。
2. 多个table原子生效还是基于Palo是批量导入方式，版本号是记录在元数据里面的，所有表的数据都就绪后再提升版本号，这样就能够保证所有表的一并生效。可以理解为表级别的锁
3. 当前阶段LLVM是Impala自身的。命名为Palo*是由于这部分代码长时间存在于baidu内部，我们内部修改替换的

[chenzx]

非常感谢！据你的回答，

1，这让我感觉很失望，看来跟腾讯／阿里用Paxos做binlog同步的机制不是一样的？
2，MVCC的粒度感觉没那么细，并不是Oracle那种级别的

那就是说Palo的数据源主要是来自批量导入BE的部分？它作为MPP数据库，主要还是用于OLAP类应用，不是大规模并发OLTP？我在想MPP似乎处理不了分布式事务和分布式JOIN查询。。。

[imay]

OLAP设计还是主要面向分析的，更加注重的是怎样高效扫描、计算大量的数据。而OLTP更多的是解决事务请求，注重的更多的是事物之间的隔离性。

还有你说的MPP是能够处理分布式join的。而分布式事务跟MPP是完全两个正交的事情，相互之间是没有排斥的关系的，是完全能够实现在一个系统里面的。不实现的原因是会增加系统的复杂度，不如在某一方面更加擅长。