我正在构建一个相当大的SaaS系统，将被多家企业使用。
目前，有一个MySQL数据库可以保存所有数据，但是看起来每月可能会添加很多数据（我会说每个连接的业务至少有5-10k个条目，我们可能有100个-200业务连接），我开始担心数据库会快速增长，并且由于可用的数据量，查询可能会很慢。
系统托管在AWS上，因此可以扩展。
有些问题：
1）害怕减速有效吗？
2）我最好分成多个数据库，每个业务一个？
3）如果您推荐多个，请注意将有共享成员可以访问来自多个企业的数据。我该怎么处理？
此致
鲍勃答案 0 :(得分：0)
假设您有100个企业，每个企业报告5k个实体，那么您每个月都会看到5,000,000条记录的增长。
避免将这个数字视为大或小，至少本身。实际上你必须退后一步，考虑一下你将要存储什么样的数据，你将运行什么样的查询，你可以为MySQL提供多少内存，以及什么样的响应时间是可以接受的。如果这是SaaS，你会希望保持较低的响应时间...也许你的数据非常基础（少数几列），人们想问一些问题，例如“每个企业平均有多少实体过去的一年。“有了好的索引，这将是一个非常可行的查询。如果像物化视图（http://en.wikipedia.org/wiki/Materialized_view）或汇总表那样具有良好的索引，那么它可能根本就不是问题。也许你也可以在等式中添加缓存。这完全取决于。
但是，在回答你的问题时，担心减速是否有效？嗯，是的，不。可能吗？非常好。你应该害怕吗？不可以。您应该以不太可能发生的方式管理您的数据。
这将我们带到您问题的第2-3部分：您最好将数据拆分为多个数据库以及如何处理访问？
嗯，答案是“这取决于”。但鉴于你问的是你的问题，我怀疑数据库复制并确保多个数据库的一致性可能不是你想要咀嚼的东西，至少现在不是。
因此，您有几种选择。一，想想你需要问什么问题，以及它们是否可以有意义地预先总结。按照OLAP（http://en.wikipedia.org/wiki/Online_analytical_processing）的思路思考，即使不是专门的OLAP。也许你可以用某种过程来总结数据并将它存储在更小的表中......在这种情况下，好的索引可以让你免于麻烦。
也许你需要回归基于Hadoop的东西，比如Storm或Impala或Spark。弹性搜索也可以派上用场，具体取决于Redis / memcache。
这完全取决于（a）您将要存储的数据（b）您需要执行哪些查询以及（c）您最熟悉和熟练使用的技术。并非所有大数据问题都是平等的。不难想象，5亿条记录是一个较小的“大数据”问题而不是涉及5000万条记录的情况。这实际上取决于您正在处理的数据以及您需要处理的数据。
所以......足以说这个问题没有一个正确的答案。这就是为什么处于大数据职业生涯中的人总是把手放满。你需要考虑很多，而且很少有黑白，简单的答案。