企业数据架构演进
「数据」与「流量」是系统架构中最难解决的两个问题。横向扩展通常是解决系统容量最简单的方式，但是在系统横向扩展过程中，数据库仍是最容易产生瓶颈的服务组件。
1 读写分离
读写分离中，主库负责事务性操作：Insert/Update/Delete, 从库负责 Select 操作，从库与主库之间通过 MySQL 原生 binlog 同步。
这种方式原则上可以无限扩展数据库的读能力，但是由于只能写主，所以仍无法解决写容量的问题。除此之外，数据库单表的容量是有限制的，当单表数据量过多时，性能会显著下降。
此种架构的核心思路是：垂直扩展。
2. 分库分表
分库分表正是用来解决单库的写瓶颈，与单表的容量限制问题。
这种架构的核心思路是：水平扩展。如用户存储以用户ID进行分库分表，商家数据存储以商家ID进行分库分表。
此种架构需要「数据库中间件」支持，中间件用来做库表路由，客户端主备切换，数据源管理与动态变更，监控，排序支持等。如淘宝的 TDDL，点评的 Zebra，当当的 ShardingJDBC 等。
2.1 数据拆分维度
以维度进行拆分需要考虑如下几点：
- 数据尽可能平均。数据倾斜也可能带来流量倾斜，热点问题。
- 单次查询扫描库表数。如订单系统中只用订单ID分库分表，那么用户维度的查询需要对所有表进行扫描才能得到结果。
2.2 数据异构（多维度拆分）
数据异构是用来解决高并发下的查询全表（所有分表）扫描问题，如为了解决订单系统查询问题，对数据同时以订单ID、用户ID、商家ID分表，冗余存储三分数据。
这种架构的思路是：空间换时间。
数据异构最难解决的问题是数据一致性，数据复制有两种实现：
- 数据库层，如阿里的「精卫」，通过 binlog 采集，经过处理应用到目标数据库上。
- 应用层，这种最大的问题是事务的有序性无法保证。推荐的方式还是第一种。
当然还可以基于如开源的 DataBus 组件，最重要的还是保证源操作和目标操作的同序。
3 搜索引擎
如 ElasticSearch 类产品。
需要注意的是，搜索引擎并不是数据架构的最终形式，其只是数据库架构的补充。数据库主要做 「查询」，而搜索引擎主要承担「不确定多条件搜索」。通常在后端系统中（非搜索类系统），查询和搜索的比例在 95% vs 5% 左右，搜索比例甚至更少。
除此之外，还有类如 Hadoop 类产品主要为系统数据做离线辅助分析，类 Strom 产品做实时流数据分析或生产。
4 总结
数据架构的思路主要有：水平、垂直拆分；数据冗余；数据异构等。
需要注意的是，数据架构中，最难解决的问题是「数据一致性」问题，而数据一致性问题最可能是由数据冗余引起，所以「简单可靠」应该是数据架构最核心的指导思想。如数据异构虽然可以解决系统扩展和性能问题，但是其带来的运维复杂度也是不可忽视的，降低了系统的可靠性。