海量数据实时使用面对的问题和想法

在不久之前有一个业务系统，数据量不断地增加，经过了5年的岁月，它终于达到了每天上百万级的交易流水的规模。而在它不遥远的将来的规划中，它目标是每天达到上亿条交易流水的规模。

且不论这个目标是否靠谱，也许靠谱。

当一个习惯了关系型数据库的研发部门发现关系型数据库再也无法满足业务的数据量了，肯定会有一个很痛苦的过程。但目前，业务系统还是运转正常，一切看上去都很美好。业务方还没有意识到他们的系统快要挂了，所以不肯投钱投人在短期内无法见效的技术研究上。

而因为没钱没人，研发部门看着数据库慢慢走向夕阳的背影，除了同情还是同情。

当系统真的濒临死亡的那段时间，业务方和研发部门就会进入一个相互指责、谩骂、诋毁的阶段，好吧，我心理很阴暗，也许他们会手拉手好基友，共度难关。无论如何，总是会有一个巨大的火坑等着人跳。很不幸，按目前的情况看，我会是跳火坑的第一号。

这就是我面对的情况。

然后问题就变成了，我需要干什么？

按照一般的做法，我需要分析一下，我要解决的问题是什么先，然后再看怎么解决。

一开始我以为我只需要给一个关系型数据库的分库分表的方案就行了，可后来考虑到目前开发人员的情况，觉得这是自己给自己挖坑。

分库分表需要从设计人员到开发人员到数据库管理人员的全体人员都很清楚：俺们到底是他妈的如何分的数据，有一个环节上出问题，就挂了。尤其是对于开发编程，有很多限制，对于排序此类需要全表扫描的需求，实现很困难。所以，这变成了备选方案。

抛弃了上面方案之后，我思考了几天，我到底需要解决什么问题？

这时候，屏幕打出一行大字，欲知后事如何，请参见下列链接海量数据CRUD的功能需求说明