SQL大家再熟悉不过了，不普及了。SQL到底解决了现实中什么问题？

在小门店的时候，流水较少，一个简单的账本可以很简单的完成当天甚至当月的流水统计报表，完全hold住的。

由于流量少，在客人点餐和结账时客人不需要等待可以直接点餐和结账是可以保障的，后厨的厨师也不用太勤劳，有单就干没单子就歇着。

老板很能干，一年后餐厅扩大了三倍，流水大大增加了。但是流水的账单和点餐结账的业务的模式没有变，每天都很忙，雇的人已经很多了但是在中午和晚上人多的时候还是忙不过来。晚上老板看账单，在电脑上拉流水一看3000多行，数字密密麻麻。老板很高兴，赚钱啊。但是老板想看看今天各项的支出和收益，比如蔬菜用了多少，那些蔬菜用的多，肉类还剩多少，明天需要那些，调料之类的啊，之前少都是老板自己算，现在老板自己算算到了凌晨5点多。老板感觉太他妈的累了，就雇了一个会计（SQL），这个会计很好能力出众，刚来就把报表流水处理的井井有条，而且还会根据老板的需求去增加调整表报。老板感觉太好了，这个人太棒了给了很高的工资。

账单是处理好了,后厨开始有问题了，之前一个大厨一个帮工，什么菜都是他们干。规模变大之后增加了两倍人手，但是菜也加了很多，老板本着术业有专攻，一个负责主食，一个热菜，一个负责汤品，但是呢顾客热菜点的多，负责热菜的厨师很累，就找到老板说了这件事，不给解决就离职。老板也很头疼，再招一个热菜师傅（费用高）有点多余，怎么办呢？老板说你找个徒弟吧，边学边做，大厨想有人总比没人强，就说好（MySQL 主从复制）。

服务员也抱怨太累了忙不过来，服务员的工资不高，老板就直接又招了三个人。服务员人多了自己管管不了太多，就升了的自己的小姨子做大堂经理。服务员不敢有意见，没办法啊。（分布式，一台不行两台）

看似美好，但是在结算和点餐的时候还是好多问题。结账只能去前台结账，服务员只负责点菜和上菜，本来开始的时候运行良好，但是在晚上客人很多的时候大家结账就必须等着（保证ACID），客人对菜单打发票付钱确认下来没有10来分钟下不来，在外满等的客人不耐烦就走了。老板在想这种集中式的模式不行，我要换个模式。正好有个亲戚回国，老板就把这件事和他说了，这个亲戚学问很高，告诉老板一句话“分而治之”。老板牢记在心，但始终不得其解，老板很郁闷就去街边喝酒去了。街边的小摊的菜单都是贴在桌子上的，摊主一个人太忙，顾不上找钱，就让客人自己算好放桌子上，不是整数的就再找摊主找零。老板很郁闷，问摊主要是有人吃霸王餐怎么办？摊主很无奈，来吃的都是熟人没事的。

老板边往家里走边想，如果让每个服务员都可以收账那么这个问题就可以解决了，但是入账不及时只能当天结束之后才能够入账，该怎么办呢？一桌结账的时候就去找会计对账，估计会记会离职，显然不行。对了，每个桌的菜都是从后厨出来的，只要记录每桌的菜品的价格和服务员的收账款对上就不会有问题了啊。老板很开心，连夜制作了计划。

第二天一早老板开会说了自己的想法，会计说没问题，新建一个账单存放key桌子编号（加时间，服务员）对应value菜品集合。收银台也很高兴，减轻了很多负担。服务员感觉活多了，钱不对还得自己补，不开心，但是老板说涨工资还有绩效考核，服务员涨钱了也很开心。（NoSQL模式，KV模式，一个桌子编号加时间加服务员编号就是一个Key,菜品就是Value）。

但是服务员不想要当天结束才入账，这样下班时间会延迟。老板想想也是，本来服务业下班就很晚了。流水那么多老板想要实时查看收益，晚上下班还要计算库存之类的。老板找到会计，说了这件事情，问会计有没有很好的办法？会记说可以先做一个虚拟表单，就是说一桌客人点餐结账就默认完成交易，但是现金并没有入账，这个交易就是虚拟交易。下班时服务员只需要交付当天的收入即可不需要和对账操作这样，当天每个服务的交付现金，记录一个新表，当天服务员记录表。然后在每天早上由会计完成虚拟表和服务员当天记录表完成校队，就可以了，出入不一致的当时补齐就好了。

老板想了想，这样可能会造成短时间真实收入为假的状态，虚拟表的正确性决定了支出和收益的正确性。单就以一张表格判断信息的正确与否，显得单薄而不稳定，假如在某时丢失某些信息，该如何回复和补救呢？之前的话是当时结算完成之后，数据丢失并不会造成直接的资金损失，老板在平衡之间的权益。老板在想不能够把所有的风险全部自己承担，应该分担出去。既然每个服务员都可以完成点餐收银的功能，那么就每个人收取一定押金，但是押金不能去收，只能在工资和绩效里面分担出一定金额担保。也就是不要虚拟表，只需要一张服务员当天记录表，表里面增加一个押金字段，每天开始这个服务员当天记录表押金默认一定的数额，当天服务员账单资金从押金扣除，可以保证当前一桌的支出和收入完全真实和有效正确的。然后在早上核对收入时只需要核对服务员当天记录表的押金和收入金额是否可以匹配上就好了。

老板想到这里十分感谢会记，然后详细的计划去了。然后告诉服务员这样并不是在当天直接拿出工资部分当做押金，只是一种形式保证，而且每天清零，如何押金没有出现负值还会提升绩效奖金，服务员不用主动掏腰包交钱就行，就同意了。

从开始的手动记账，到后来的SQL,然后SQL无法满足大数量的操作，然后需要NoSql的高性能和快速扩展能力，到后为了事务操作完成了NewSQL