首页手记当对你的业务进行数据库选型时，你真的会选择吗？

当对你的业务进行数据库选型时，你真的会选择吗？

标签：

大数据架构数据库

数据库选型的背景

随着计算机技术的发展，数据库已经成为计算机系统里面最不可或缺的关键基础设施之一。相比于其他基础设施软件，如操作系统、编译器等，数据库不仅需要提供基础功能，还要于业务发生联动，并通过提供更广泛的能力来满足不同的业务诉求。
特别是，数据库软件相比于操作系统等软件，具有更多的可选择性，不同的数据库软件也是各有特色。这就面临着，我们在真实的业务场景中，需要根据业务诉求的不同进行技术选型。
但是，面对复杂的数据库软件系统，你真的会选择吗？

常规选型方式

有的人说，对于关系型数据库，就无脑选择MySQL就行了，反正业内就是这么用的。而如果是商业版应用，那就选择Oracle即可。这种说法在某些场景下是ok的，但是对某些具体的业务诉求来说，可能就是埋了个坑。
首先，对于数据库来说，上面两种数据库都是典型的OLTP业务场景下的选型。虽然Oracle具备较强的OLAP能力，但是这毕竟是商业数据库，对于绝大多数小公司或者互联网公司来说，是根本不在选型列表里的。
那么，对于互联网业务，首先需要做的就是识别业务场景，看看数据规模如何，数据模型是什么，是否需要选择关系型数据库，是否需要支持较强的可扩展性，是否能够容忍数据丢失，要求的端到端性能指标是多少等等。

选型示例

以类似微博这种应用场景为例，我们不妨进行一个简单的系统设计。

首先，需要有一个表结构来记录用户信息，这个表结构需要有一个主键，来记录用户的唯一id
需要存在一个记录信息流的地方，由于信息流非常大，这里需要面对处理大量数据的场景
需要有地方承载起他用户评论、点赞、转发等相关信息
需要具备缓存能力，否则当业务规模很大的时候，无法及时响应用户信息
如果具备缓存能力，我们虽然提升了响应速度，但是这个缓存的数据可能及时性又不够强，完全存在用户看到的数据不是最新数据的情况
对于搜索场景，如何进行快速的检索？
…

对于这个业务场景中存在的系统设计问题，我们只是进行了非常粗浅的讨论，便可以列举出一系列的问题，这里面我们做一个简单的总结，即在不同的业务场景中，我门可能需要面对的是不同数据规模、数据一致性、响应速度、可用性等问题。这里面其实都可以通过关系数据库来承载，也可以通过进行SQL语句进行业务抽象。但是MySQL显然不可以胜任，这就需要我们选择其他更适合的数据库产品了，例如ClickHouse，Cassandra等。

其中，如果我们识别到数据等价值密度很大，一点都不能出错（例如银行转账场景，或者用户充值场景）那就必须要选择ACID完整性支持很好的数据库，否则真出现问题的时候，面临的是公司破产的风险。至于这里为什么？其实事务本身的特性就已经告诉我么答案了。