由mysql5.7支持JSON 浅谈数据库设计

为什么MYSQL更新的幅度越来越大 是因为原来的三NF设计完全不够用了 又没有大神提出新的标准 虽然暂时还是最热门的数据库 但是挑战者已经在敲门了 说说这问题 顺便整理下思路 以观后效

以一个简单需求举例 用户发表文章 其它用户可以点赞 前端页面需要显示哪些用户点赞了此文章 本用户点赞了哪些文章

开始数据库设计 

1.用户表 用户名 密码 UID

2. 文章表 UID 文章标题 内容 tid

3.点赞表 UID TID

通过联表查询 以TID为条件索引可查询到点赞了本文章的用户列表

以UID为条件索引可查询到某用户点赞了哪些文章 

需求搞定 如果数据量不大的话一点问题没有 但是如果是新浪微博呢 问题就大大的来了

       首先从背景上来说 之前所有的系统基本都是以公司工厂为单位运行的局域网环境中 90%以上了不起就三~三百台电脑的规模 简单说就是业务流程复杂 数据规模不大 并发性基本不用考虑 在此基础上总结的数据库设计规范 中心思想是一份数据只保存在一个地方 只在一个地方更新 表与表之间通过ID外键互联即可 只要是接触过由EXCEL建立的系统的人 都能理解这种设计的优越性 彻底的解决了数据不一致的困扰。在此基础上发展了外键 触发器 存储过程 索引等概念 将数据库作为数据仓库集中处理数据的作用发挥到了极致。

      但是现在使用的环境已经完全变了 随便一个最简单的帐本应用都是面向互联网公开的 并发量 数据量都不可同日而语 各种新的理论 工具层出不穷  分库分表 Memcache  redis 还有MongoDB 都是为了解决一个问题 MYSQL不够用了 性能不够造成业务崩溃的例子每天都在发生 MYSQL有各种问题 我觉得其它问题什么修改表结构慢之类那都不算事 最主要还是这个中心思想一份数据只保存在一个地方 到底还合不合时宜

     同样以这个需求举例 如果按照文档数据库的设计思路 例如MONGO 可能我会以文章建一个表 包含TID 标题 内容和一个点赞用户列表

再以用户建一个表 包含UID 用户名 密码和一个点赞文章的列表 这样无需联表 只需要一个主键查询 就能获取到需要的数据 但是写入的时候比如某用户点赞了某文章 就要在二个地方写数据 有可能带来数据不一致的问题 当然使用一些手段可以避免或修复 但是这就引入了复杂度 有没有必要？这里我觉得是有必要 大多数的系统读比写多 也比写复杂 这样改写之后 应该可以几乎完全的避免MYSQL死锁的问题 但是如果业务场景太复杂 可能会需要维护不止二份的数据

    来点对比

    1.MongoDB在阿里云比MYSQL贵2倍不止 

    2. MongoDB与MYSQL语法完全不同 有不少坑要踩

    基于以上在简单系统上试用过一段时间的 MongoDB之后 还是没敢切换 用回MYSQL了 但是这次更新支持JSON之后我就在想既然MYSQL成本明显比MongoDB低 稳定性成熟度又比MongoDB好 那能不能把文档数据库的设计思路用来用MYSQL来实现呢？？？或许是个路子。

    总结一下 个人一点小建议：

   .应用层可以无限制的扩张 CPU 带宽 内存都不是个事（除了￥￥。。。） 所以系统瓶颈一般在数据库 所以尽量不要使用外键 触发器 存储过程等任何需要占用数据库锁甚至是数据库服务器CPU的东西 一切计算往前提 在应用层组装计算 甚至可以提到用户端浏览器去

   .应该可以改变一下传统3NF的设计思路 采用文档数据库的思路 中心思想主要是按需求组织数据和保存数据 好处是可以一次获取所有相关数据 至于写数据的多处修改问题 正好可以使用MYSQL的事务机制 通过前面说的日志队列的方式实现快速返回 队列写入

   .尽信书不如无书 透过现象看本质 在现在这个SSD成本大降 存储成本越来越低 数据却越来越大 并发数越来越高的时代 我觉得牺牲点存储空间 和写入速度 换来瓶颈中心数据库的可扩展性 和读取速度的提升 无论怎么算都是划算的也必将会成为主流设计思路 相信一段时间之后必然有行业大牛出来推出新的设计标准 MYSQL又将大行其道 

   .再次印证了 巨头没那么容易被打倒 屌丝永远还是屌丝。。。。残念。。。

  回头找个小应用 实践下看