数据库可伸缩性问题

Question

我正在构建一个相当大的SaaS系统，供多个企业使用。

现在，有一个MySQL数据库保存了所有的数据，但似乎每个月都会添加很多数据(我想说，每个连接的业务至少有5-10k个条目，我们可能有100到200个业务连接)，我开始担心DB会增长很快，而且查询可能会因为可用数据量而缓慢。

系统托管在AWS上，因此具有可伸缩性。

一些问题：

( 1)对经济放缓的恐惧是否有效？

( 2)我是否最好将数据库分成多个数据库，每个业务一个？

3)如果您推荐多个，请注意，将会有共享成员可以访问来自多个业务的数据。我该怎么处理呢？

致以敬意，

鲍勃

Answer 1

假设您有100个业务，每个公司报告5k个实体，那么您将看到每月5,000,000记录的增长。

避免认为这个数字是大的或小的，至少本身如此。实际上，您必须后退一步，考虑您将存储什么样的数据，您将运行什么样的查询，您可以将多少内存专用于MySQL，以及什么样的响应时间是可以接受的。如果这是SaaS，您需要保持低响应时间.也许你的数据是非常基础的(一小部分专栏)，人们想问一些问题，比如“在过去的一年里，每个企业平均有多少个实体。”有了好的索引，这将是一个非常可行的查询。有了像物化视图(view)或汇总表这样的好索引，它可能根本就不是问题。也许您也可以在等式中添加缓存。一切都要看情况了。

不过，在回答你的问题时，对经济放缓的担忧有效吗？好吧，是和不是。有可能吗？是的。你应该害怕吗？不是的。您应该以一种不太可能发生的方式来管理数据。

这就引出了您问题的第二至第三部分:将数据分割成多个数据库更好吗?您将如何处理访问？

嗯，答案又是“看情况而定”。但是，考虑到您是在问您的问题，我怀疑数据库复制和确保多个DB之间的一致性可能不是您想要的东西，至少现在不是。

因此，您有几种选择。第一，想一想你需要问什么问题，以及这些问题是否可以有意义地预先总结。按照OLAP (processing)的思路思考，即使不是具体的OLAP。也许您可以用某种进程总结数据并将其存储在小得多的表中.在这种情况下，好的指数应该能让你远离麻烦。

也许你需要回到以Hadoop为基础的东西上，比如Storm，Impala或Spark。弹性搜索可能也会派上用场，这取决于Redis/memcache。

这一切都取决于(a)您将存储什么数据(b)您需要针对它执行什么查询，以及(c)您最舒适和熟练使用的技术。不是所有的大数据问题都是平等的。不难想象，与涉及5000万条记录的情况相比，5亿条记录是一个较小的“大数据”问题。这实际上取决于您正在处理的数据以及您需要处理的数据。

所以..。只要说这个问题没有一个正确的答案就够了。这就是为什么从事大数据行业的人总是忙得不可开交。你需要考虑的东西很多，很少有黑白相间的简单答案。