非常讨厌大而全

有一段时间，我的状态一直是“非常讨厌大而全”，列举几个例子.

 

做数据库拆分方案的时候，一张很大的表，要在线使用的用户数据，我们要拆分出来，放到n个小数据库里去。

这时候就有人问了：那你们事务怎么做啊，不同数据库之间怎么保证一致性啊。

我就说：不同数据库之间我们不在这里考虑事务的问题，需要应用去考虑，我们这里解决的是超大数据量的问题。

曰：ACID都不行，那这个方案不行啊～～

 

ACID是小家子气，单机的时候，我们强调的东西了。在高并发，大数据量，分布式的环境下，我们只能CAP，而且还只能做到其中两点，我们一般会选择可用性和分区，详细的论证可以参考程立的一篇分享大规模SOA系统中的分布式事务处理，哎，要是一致性、可用性、分区全部能完美的做到的话，我还待这里干嘛呢？

 

学习面向对象的时候，我们知道“只做一件事情”，在一个类里，只做一件事情，在一个模块里，只完成一个功能，同样，我们设计一个类库，或者一个产品，应该也需要有最核心的一个价值所在。但是，我们经常在设计一个系统的时候，会逐渐逐渐的偏离原来的方向，为什么？每一次添加需求，添加功能的时候都觉得挺合理的啊，为啥过了一段时间再来看整个系统就觉得不是那么一回事情了呢？我认为是在添加需求的时候，没有把好关，要添加的东西是我确实需要的么？还是可有可无的？是必须要有的么，还是锦上添花的？我总觉得锦上添花的事情不做也罢，还有好多人在雪中等着我们去送炭呢？先做最重要的事情不吧，分清优先级很重要。

 

现在有些人在做设计的时候经常想的很美好，很长远，挺好的，有长远的规划是挺好的，但是实际操作起来就不应该大而全的做，应该向敏捷学习，一点一点的做，经常release。

 

工作中也是，经常是挺好的一个想法，结果为了求全，结果做的四不象，需要的东西做得不够好，暂时不需要的东西，做了一点，集中精力做好需要的东西不是挺好的么？干嘛要大而全呢？

 

补充：犯了一个错误，CAP的P是Partition而不是 Persistence，感谢指正。

 

CAP中的P不是Persistent而是Partition。

一张很大的表，要在线使用的用户数据，我们要拆分出来，放到n个小数据库里去。

----------到底是拆分表？还是拆分数据？

大表通常指的是field很多的表。

似乎我们叫大表都是说数据多的....

用户表多也多不到那里去吧？ 一个公司顶天了，比如农行，2000万员工，已经号称世界第一了，至于网站，xxxx天不登陆的用户，通常都被arched.

很想知道为什么要拆分成几个数据库，原来的数据库的性能log文件写了些什么?