2018-05-22感觉分库分表是分布式数据库到来之前的临时方案，另外感觉老外们好像并不怎么会采用分库分表，是这样吗？ 6
2018-05-19请问如果采用阿里云华为云的话，那么多技术要实现是不是只要购买阿里云他们相应的产品，然后配置下就可以了，就没程序员什么事了？ 5
2018-06-13一致性哈希 4
2018-05-17CQRS应该用在没有事务强一致性要求的场合，才能充分发挥其作用。不过微服务架构似乎更倾向于设计出最终一致性的程序。作者回复: 嗯。另外，仔细想想，强一致性这种场景真的不多。
4
2018-05-17请只考虑业务分片。请不要走哈希散列的分片方式
对这句话不太理解，走哈希分片虽然是有跨表查询隐患，后续数据量再次暴涨也需要重新哈希，比较恶心，但也可以解决热点问题，而且互联网公司的用户数据大部分场景下都是有热点的吧，为什么皓叔这么反对呢？实际场景中会遇到什么更痛的点嘛？能否更详细地讲讲呢 3
2018-05-17索引表也越来越多大 需要分片怎么办呢作者回复: 索引表没有业务属性，就是kv，没有join，没有group，所以非常容易用哈希分片
3
2018-05-17按照哈希散列分片，实现方案最简单，只需要在操作数据库的时候特殊处理就可以了。
按照业务分片，为了减少跨分片操作，在请求的前端就需要明确业务字段的值，所以并不是所有场景都适用，这些方案各有利弊。
不过有一点我还是赞同的，不到万不得已，不要用哈希散列分片，不然等到以后要重新分片的时候代价巨大。作者回复: 业务分片，其实直接就数据分库，服务拆分，走向微服务得了。
2
2020-01-15打卡：60 | 性能设计篇之“数据库扩展”
对分布式系统中，数据库的分布式有了更深刻的认识
1. 主从、一主多从架构
2. 根据SQL语句拆分为 俩种类型的操作，然后借助数据库访问中间层，做请求的路由
3. 分库分表
4. 分库最基本的要求，就是从业务角度设计，这点也符合现在的微服务观念，单服务单库
5. 分表，水平分片、垂直分片 ：水平分片最常见的方式就是按时间维度拆分，垂直分片的含义就是按表中的字段拆分了；展开
2020-01-06坚持学习，学习笔记 https://mubu.com/colla/1xqu-zBrKB0
2019-07-24为了提高性能，有两种拆分数据库的方式，一种是读写分离CQRS，另一种是分库分表。
读写分离Command and Query Responsibility Separation，保证读服务是无副作用，写操作又可以改进为事件回溯的方式，从而提高系统性能。
在拆分数据库前应该先做服务拆分，并保证每个服务都有对应的数据库，不同服务间的库通过服务访问的方式来交换数据。
2018-10-16先是读写分离，再扩展到按租户、地域等维度分库，再按时间维度进行分表，按数据进行水平或垂直分片。最后在讲到微服务的数据库设计模式，如当服务对单库，在之上应用之前提到的设计方法，拉近业务。
2018-07-27新公司用到Postgres的Citus,感觉比较小众，老师怎么看这个技术选型。我们是大数据中心。
2018-06-23一致性哈希的问题，个人认为很难绕开。实现通用型nosql数据库，不能根据业务分片。就如文章所说，一致性哈希在扩容时，需要重新整合，需要移动大量数据，成本太大。目前优化，也只是在数据移动时的优化，治标不治本。不知道，有没有其他解决方案
2018-06-14谢谢耗子老师。 我涉及的业务是金融交易的清算（批处理系统），需要保证主从库的数据强一致性，但mysql复制不能保证强一致性，这种情况怎么做为好呢？是在应用层写双库，做两阶段提交？还是有什么产品可用呢？作者回复: 业务层上，只有两阶段提交，数据层上，只有Paxos