SQL或者NoSQL的方案
问题：
本人开发的点餐系统，20家酒店每日200张账单，如此以来一年就能积累出百万张订单数据，每张订单中包含的菜品单品自定义菜品组合菜品几个到几十个，想想数据量就很恐怖，在这些数据之上需要实现许多报表，如哪个员工销售了哪些类别菜品的数量，员工在不同餐段的绩效，账单优惠统计，不同的菜品有的打折有的不打折…
解决：
如果按照传统的开发思路，账单应该是一个关系表，账单号和菜品id都是外键，那么这张关系表的数据量将会达到千万级，随着时间的推移，用户变多，数据轻松达到几十亿级，这样的一张关系表，想想就挺头疼。于是想到一个比较折衷的方法，当时知道MySQL5.7版本可以支持JSON了，于是用一个很长的JSON字符串来存每一个账单，账单的菜品信息，支付信息，操作人信息等都内置进去，然后其他字段存一些整体性信息，索引性信息。
效果:
优势：账单信息更新方便，更新只需要按照索引取出修改再更新即可，一次操作只涉及一个表的一行数据，关系少容易分片存储。
缺点：key-value的JSON因为每一行数据都要从新存储key，所以存在较大的空间浪费。更新容易读取困难，想要写个erp的报表，费那个劲，逐行读出来反序列化JSON字符串，遍历json（也许可以直接用MySQL实现，我不会，应该也不容易吧）
下面是转别人总结的经验，基本和我的实践情况一样
1、使用反三范式模型，设置冗余字段，减少多表联查。
2、数据量增多，单靠主键查询效率低效，增加查询字段索引，提升查询效率。
3、单节点压力过大，采用读写分离，将查询压力增加到其他节点，查询节点设置索引，插入节点不设置索引。但会导致数据存在时差，如果有多个读节点，将会导致短时间内数据不一致。
4、使用redis、memcached等缓存中间件，将常用的查询数据缓存。但是会存在数据一致性问题，需要通过代码来保证数据强一致。
5、数据到达百万级以上，采用数据库分表分区，将同一个表中的数据分散到不同的分表分区中。运维难度加大，并且如果分区hash不合理，会产生数据倾斜，重分区数据迁移会导致产生大量io，重分区过程中，服务提供的性能大大降低。
版权声明：本文为CSDN博主「开着小马奔腾哟」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lpp_dd/article/details/87969392