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