规划数据库扩展和架构更改 [关闭]

Question

在创建我的社交网络数据库之前，我正在做研究，我发现了很多与社交网络的图形和键值数据库有关的问题/资源。我知道有很多不同的选项和方法来实现数据库。我也明白大公司所做的事情很复杂，而且远远超出了我目前的需求（1b+ 用户）。我也知道每家大公司都修改了他们的数据库，以应对他们经历的疯狂扩展。

因为我不知道网络将如何发展，而且我不相信我可以准确地创建一个可以扩展到 100 万用户的模型（由于未知数，例如人们将如何使用它、人们发布的频率、评论等）。但我至少可以尝试创建一个在（如果）需要时最容易扩展的数据库。

大多数公司是否会创建一个数据库来处理多达 1000 个用户，然后一旦它们增长，他们会针对 10000 个用户进行改造，然后是 100000 个用户，等等？如果他们这样做，在这些任意数字中的每一个（由于上面列出的未知数），公司是否通常会更改一些表/节点/等，或者他们是否完全重新创建数据库以利用新技术（例如从 SQL 迁移图表）？

我想选择最佳解决方案，但我发现在图形、键值、SQL 等之间做出决定非常困难——尤其是在没有数据知道哪些关系/数据最重要的情况下。我相信我可以使用可以支持多达 10k 用户的图形创建一个可靠的系统，但我担心随着系统的增长必须完全重新创建数据库。这是现在担心避免问题，还是现在实施并适应以后的类型问题？

进一步说，如果我确实需要计划完整的数据库重组，使用多模型 NoSQL DBMS（例如 OrientDB 或 ArangoDB）通常是否有意义？

Answer 1

我个人认为你在问过早的问题。

说真的，即使模型不好，一个数据库也可以处理 10k 个用户。

您考虑扩展，但最困难的问题不是扩展，而是到了需要扩展的地步。

我敢肯定每个人都想要 10 亿用户，但你已经梦想拥有一个用户数比 Github 本身多 200 倍的社交网络？ （Github 有大约 500 万用户）。

此外，即使提前考虑，您肯定会在几年内重构并再次重构，并且您将拥有不止一个持久层，请确定。

代码和代码都很好，保持精简，保持快速更改、部署、向用户展示、重构、测试、部署并在同一天向用户展示的能力。这些是你现在需要做的事情，不要问你还没有的问题，你现在肯定还有很多其他的问题要解决;-)

更新

根据您的评论，您可能需要认为有些问题我们无法简单回答，因为我们不需要您的确切要求。

我有一个简单的应用程序，它使用了 4 个持久层，而这个应用程序还没有上线。我会给你我关于使用它的“为什么”以及哪个用例：

1. Neo4j : 它是应用程序数据的核心，我使用它是因为我喜欢它，我非常了解它（这是我的工作），而且由于应用程序的概念很新并且可以发展很快，拥有一个无模式数据库正在减少很多重构工作。此外，我现在通过构建应用程序有很多用例，当您需要添加功能而又不破坏已经完成的功能时，这使 Neo4j 成为一个不错的选择。

2. MySQL

我将它用于用户帐户和个人资料。为什么 ？因为我使用的框架已经有很多包在几行代码中集成了这种东西，所以这些包维护得很好，如果我要使用（当前）neo4j，我将不得不重新发明轮子。此外，我使用的所有模块都在稳定性和与框架的兼容性方面不断发展。

当然，mysql 数据（最少）与 neo4j 数据耦合。但是我知道这种数据不会进化那么大，所以Mysql是一个不错的选择，万一我不得不重构一些点，这不会是一个巨大的痛苦。

1. Redis

我使用 Redis 存储分析数据，Redis 非常灵活，我可以轻松创建新键并在其上添加数据。

4. RabbitMQ：

我使用了很多消息队列，为什么？用于测试重构。我可以轻松地处理多个消费者的消息以测试“重构”、在应用程序运行时测试多个数据库层以测试更改、测试新功能、测试重构……

你将重构！尽量保持简单。