Cloud Native时代SaaS类Web应用的后端数据库架构设计：核心概念的简化：主键设计

云计算时代要求偏业务类的SaaS Web应用做到：可伸缩可扩展、高可用高并发。核心在于数据库后端架构设计。怎么做到这一点呢？引入微服务，将原来的单体Web应用拆分为多个分离的服务（实质就是数据库存储层的拆分，分库分表），以及敏捷／精益的项目管理思想（前者在于适应变化保证质量去除冗余，后者在于引入核心度量指标以改善），DevOps（价值有限，今早发布频繁发布）过程管理。而Cloud Native则要求直接基于PaaS产商成熟的部署平台开发Web服务应用，使得其达到立即可水平扩展。

这些话题有点杂乱，我主要还是讲后端数据如何做架构设计。以下全是干货：

（1）不管是支持ACID事务的SQL数据库，主流开源的如MySQL／PostgreSQL，商业的Oracle／DB2／SQL Server，而是宣传CAP任选其二的NoSQL（MongoDB／HBase／Cassandra／Redis），其实质还是领域建模，CRUD操作那一套。但更核心的是，理解主键和索引键的关键作用。SQL数据库显然也可以直接拿来当NoSQL来用，一点问题也没有。

什么是主键？Primary Key（MySQL里又称覆盖索引）唯一地标识一行记录，或者一个领域对象实例，在需要高并发的场景下，实质就是对主键如何设计要有更深一层的考虑：不要简单地使用自增key（会带来安全性问题），UUID也不一定就合适，自然主键（可能是组合的）需要考虑如何水平拆分。

不仅仅如此，主键如何设计不是依据sql数据库里表模式设计来（表模式又来源于关系数据库理论的E-R建模及规范化），而应该看实际的用例：不同用户角色的数据查询、更新需求。这里可能对应的就不再是单独的一张表，而是适配了不同领域对象、不同用户视图的不同的表。——用关系数据库的名词来说，就是“去规范化”引入冗余，以至于在数据查询更新的后台操作中，不再需要跨多表的连接事务，而只是单行记录的事务。

这里相当于把主键的概念扩张了，但是实质上它变得更简化了！对于分布式系统下的大并发需求，主键将随着领域的转换实际上可能对应不同的取值。这里需要跨越一个最重要的误解（miss）：喜欢使用数据库生成的主键，自增列。但是这种主键无法解决CRUD操作中Create操作的幂等性要求，同时DHT的hash也无法做到更好的水平均匀分布。实际上，既然在某些移动Web架构里，可以使用客户端负载均衡方案，那么为什么客户端不能直接生成主键呢？当然可以！没有一点问题。。。

so，后端架构／数据设计第一步：设计好主键！

（2）除去主键外，另外一个就是辅助键，或者称二级索引，这一般是用来支撑Range查询的，即选中某指定属性连续取值范围的一系列记录，以进行批量操作。索引键其实倒没什么值得一说的，关键在于“可选择性”。

（3）除去主键，辅助键（索引键）外，剩余的全是领域对象的一般关联属性，乃至全表扫描类操作，不值得一说了。