而且很有可能高手之间的最后设计出来的差别反而更大，实际上我认为是世界观的相互碰撞，呵呵。所以，要领域建模，我觉得每个人都应该去学学哲学知识，这有助于我们更好的认识世界，更好的理解事物的本质。
画出领域模型图，圈出每个模型中的聚合边界；
设计领域模型时，要考虑该领域模型是否满足业务规则，同时还要综合考虑技术实现等问题，比如并发问题；领域模型不是概念模型，概念模型不关注技术实现，领域模型关心；所以领域模型才能直接指导编码实现；
思考领域模型是如何在业务场景中发挥作用的，以及是如何参与到业务流程的每个环节的；
场景走查，确认领域模型是否能满足领域中的业务场景和业务流程；
模型持续重构、完善、精炼；
随着互联网而兴起的新兴数据库产品很多都兼容了MySQL协议，因此成为替代MySQL的一个可选项。而这些分布式数据库产品大部分采用了分布式Share Nothing的方案，其一个核心特点是使用分布式一致性协议来保障单个partition多副本之间的数据一致性。
在PolarDB中除了有原生MySQL的行存串行执行，还有能够发挥多核计算能力的基于行存的Paralle Query功能。因此实际优化器会在1)行存串行执行，2）行存Paralle Query 3)IMCI 三个选项之中选择。在目前的迭代阶段，优化器按如下的流程操作：
上述策略是基于这样一个判断，从执行性能对比，行存串行执行 < 行存并行执行 < IMCI。从SQL兼容性上看，IMCI < 行存并行执行 < 行存串行执行。但是实际情况会更复杂，例如某些情况下，基于行存有序索引覆盖的并行Index Join会比基于列存的Sort Merge join有更低的Cost. 目前的策略下可能就选择了IMCI 列存执行。
崩溃恢复过程可以复用InnoDB的Redo事务日志模块, 与现有实现无缝兼容。同时也方便支持PolarDB的物理复制过程，支持在独立RO节点或者Standby节点上生成列存索引提供分析服务。
同时二级索引与主表有一样的生命周期，方便管理。
对于全表行转列的情形，我们使用并行扫描的方式对InnoDB的Primary Key进行扫描，并依次将所有涉及到的列转换为列存形式，这一操作的速度非常快，其基本只受限于服务器可用的IO吞吐速度和可用CPU资源。该操作是一个online-DDL过程，不会阻塞在线业务的运行。
在一个表上建立列索引之后，所有的更新事务将会同步更新行存和列存数据，以保证二者的事务一致性。下图演示了在IMCI功能关闭和开启之间的差异性。在未开启IMCI功能时，事务对所有行的更新都会先加锁，然后再对数据页进行修改，在事务提交之前会对所有加锁的记录一次性方所。
数据量TPC-H 100GB, 22条Query
CPU Intel(R) Xeon(R) CPU E5-2682 2 socket
内存 512G, 启动后数据都灌进内存。
