针对读库的设计

CQRS架构的迷思

当我们想要实现CQRS时，使用enode通过消息队列的扩展解决了C端的高并发写入的问题 那么如何解决Q端的问题呢，针对读库的设计，如果同时要满足多维度的查询和检索，以及海量数据的存储，目前的想法如下

Q端的抉择

在数据选型时有时为了更好的扩展性和性能，我们需要针对性的进行优化，首选我们要解决的问题是构建一个吞吐大，实时性高，扩展性好，性能好的查询引擎 针对于此，关系型数据库 整体的思路：

• 存储和计算分离
• 索引和数据分离

优点如下：

• 索引和数据分离，搜索引擎索引的数据量降下来了，吞吐量大，可针对性的横向扩容
• get by primary key操作对于任何数据库都是极快的，为了极致性能时，很容易针对性的做缓存优化
• 更容易和DDD中聚合根结合起来，修改索引时，对业务数据不影响
• 利用hbase多版本的能力，可存储历史数据快照

但这个选型的缺点带来了索引和数据一致性的问题，需要一些其他工作来实现 缺点如下：

• 针对历史数据的更新需要单独定制
• 索引更新实时性和一致性（只能最终一致）

打包解决方案：阿里云 Lindorm

• https://help.aliyun.com/product/172543.html