单式数据库对性能和安全性的影响？

Question

请注意:虽然我在这里专门调用MySQL，但我也希望/接受适用于所有/大多数关系系统的通用答案。

作为一名开发人员，我看不到将表分组到不同数据库的设计好处，尤其是如果所有的表都以某种方式相互连接/相关的话。从性能的角度来看，对于我(一个愚蠢的开发人员)来说，如果我在一个数据库中有100个表，或者10个数据库中有10个表，这有什么关系呢？

因此，我问:将单个数据库分解为较小的数据库是否有性能/安全性/其他好处？他们是什么?

另外，如果我有数百张桌子，而且它们都是以某种方式连接起来的，那该怎么办呢？这意味着，整个系统中没有完全隔离的表；所有这些表中都有其他表的外键。这不意味着我必须只有一个大/单块DB吗？

Answer 1

为了安全起见，您希望尽可能在多台服务器上复制数据，因此，如果其中一台出现故障，其他服务器可以共享负载。

“经典”oltp数据库的性能问题是从并发事务中产生的。主要由于锁，时间/事务呈指数增长。因此，缓解此问题的一个简单方法是拥有多个数据库，因为数据库的并发事务将减少。因此，这是一个吸引人的胶带(便宜和容易，至少与替代品相比)。

需要考虑的一件事是，历史上的瓶颈是存储(磁盘)，因此数据库倾向于通过消耗大量cpu和内存来最小化磁盘访问。此外，分区表还有助于减少磁盘上的负载。

同时，多个数据库允许将其中的大部分缓存在内存中，这也大大提高了性能。

还有其他选择。有些数据库可以使用多台计算机，也可以将机器合并到虚拟计算机中，但这也只能做到这一点。

目前的趋势是将oltp和olap数据库分开。这是合理的，oltp需要快速行“访问”，olap需要高吞吐量列读取。

另一个窍门是有两个数据库，一个是读/写数据库，另一个是只读模式。它们处于主/从配置中。大多数读取都是从读取器完成的，主程序上的更改被推送给奴隶。这减轻了处理事务的主数据库的负担。

如果仔细观察数据库，您会注意到很少有操作真正需要acid事务。当把经典模型抛在脑后，建立两到三个系统时，可能会很有趣。例如，一个用于票证(因为您不想出售库存产品而需要事务处理)，另一个用于其余的系统。如果您更新了一个产品的价格，而旧的价格被使用了0.1秒，那么它并不重要(当然，拍卖系统除外)。重点是，在传统系统中，您不能在更新价格的同时出售门票，因为行将被锁定，而且无法使用的时间更长(1-10秒)，因为您的传统db (现在是庞大的)速度要慢得多。

通常，事务db将“在内存中”(基于内核锁或多个paxos)，其余的99%在"nosql“db中读取。然后将内存中的日志合并到nosql数据库中。与其他技巧相结合，它可以线性地扩展，从而可以以传统数据库难以实现的方式增长。

这是更复杂的，需要分析，学习新的范例，和大量的时间来实施。据我所知，它主要是由“巨人”，如谷歌或twitter使用。这是“大数据”走势的基础。

如果您的公司使用传统的sql数据库，那么在更改完整的系统之前，最好使用所有可用的技巧(切分、分区、读/写dbs、vm)。