数据库可扩展性问题

Question

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

现在，有一个MySQL数据库可以存放所有的数据，但是看起来可能每月都会增加很多数据（我会说每个连接的业务至少有5-10k条目，而且我们可能有100-200个业务连接），我开始担心数据库将快速增长，并且由于可用数据量的原因，查询可能会比较缓慢。

系统托管在AWS上，因此可扩展。

一些问题：

1）经济放缓的担心是否合理？

2）我最好分成多个数据库，每个企业一个？ 3）如果您建议使用多个，请注意会有共享成员可能能够访问多个业务的数据。我将如何处理？

问候，

鲍勃

Answer 1

假设你有100家企业各报告5K实体，你看500万条记录，每月的增长。

避免把这个数字想象成大或小，至少是其本身。您实际上必须退后一步，思考要存储的数据类型，您将要运行的查询类型，您可以承担多少内存以专门用于MySQL，以及什么样的响应时间可以接受。如果这是SaaS，那么您会希望保持较低的响应时间......也许您的数据是非常基本的（少数几列），并且人们希望提出这样的问题，例如“每个企业平均拥有多少实体过去的一年。“有了好的指数，这将是一个非常可行的查询。由于像物化视图（http://en.wikipedia.org/wiki/Materialized_view）或汇总表之类的良好索引，它可能根本就不成问题。也许你可以在方程中添加缓存。这一切都非常依赖。

虽然回答你的问题是担心减速有效吗？那么，是的，不。可能吗？非常好。你应该害怕吗？不可以。您应该以不可能发生的方式管理您的数据。

这将我们带入问题的第2-3部分：您是否更好地将数据分解为多个数据库，以及如何处理访问？

那么，答案又是“它取决于”。但鉴于您提出的问题是，我怀疑数据库复制并确保跨多个数据库的一致性可能不是您想要咀嚼的东西，至少现在不是。

因此，您有几个选择。一，考虑你需要问什么问题，以及是否可以对它们进行有意义的预先总结。即使不是特别的OLAP，也可以考虑OLAP（http://en.wikipedia.org/wiki/Online_analytical_processing）。也许你可以用某种过程总结数据并将其存储在更小的表格中......在这种情况下，好的索引应该可以让你摆脱困境。

也许你需要回退一些基于Hadoop的东西，比如Storm或Impala或Spark。弹性搜索也可能派上用场，依赖于Redis/memcache。

这实际上完全取决于（a）你将要存储的数据（b）你需要执行什么查询以及（c）你最熟悉和熟练使用哪些技术。并非所有的大数据问题都是平等的。不难想象有5亿条记录比一条涉及5000万条记录的记录更小的“大数据”问题。这实际上取决于你处理的数据以及你需要做什么。

所以....足以说这个问题没有一个正确的答案。这就是为什么大数据行业的人们总是把他们的手放得满满的原因。有很多你必须考虑，而且很少有黑白的简单答案。