Web 应用程序数据库 - 最佳性能和可扩展性答案

【问题标题】：Web Application Database - Optimum performance and scalabilityWeb 应用程序数据库 - 最佳性能和可扩展性
【发布时间】：2017-07-24 22:31:45
【问题描述】：

我目前正在构建一个 Web 应用程序，每个客户都可以创建多个项目。对于每个项目，用户将上传数千行数据（1,000-50,000），我们称它们为“帖子”。

是创建一个每行包含其项目 ID 的单个项目数据库、为每个客户创建一个每行包含其项目 ID 的数据库还是每个项目一个数据库更好。

“更好”被定义为更好的性能和扩展能力。每个项目的所有帖子都将用于具有数千个特征（5,000-10,000）的机器学习算法，并显示给用户以标记为正面或负面。我们还没有决定一个数据库。

【问题讨论】：

您能否更具体地说明您计划对数据读取或写入执行哪些查询？第一步似乎是“繁重”的写入工作来插入数据，如果可能的话，分批插入。您使用的是 MongoDB、PostgreSQL 等什么数据库？
@RistoNovik 已添加信息。
感谢您提供的附加信息，因为它似乎不是通常的 CRUD 应用程序，更像是添加数据然后忘记。 “帖子”数据只是上传而不更新吗？如果是这样并且数据是非结构化的，为什么不存储在压缩的 CSV 文件中？
@RistoNovik 将向用户显示的所有数据将用于训练 ML 模型，作为模型的输入提交，更新和导出。数据是结构化的。

标签： database database-design architecture scalability

【解决方案1】：

看看你的简短问题，你有三个实体： N User , (N * 1000) Project, (N * (N*1000) * 50000 )Posts

根据我关于机器学习和可扩展性的假设，因此我可以安全地假设至少有 100,000 个用户。每个用户可以创建多个项目，比如说 1000 个。每个项目可以有 50,000 个帖子。

100,000 Users * 1000 Project * 50,000 Posts.

RDBMS 解决方案是 Create User table(UserId, Name etc..), Create Project Table (ProjectId, etc..) Create Mapping table for UserProject (UserProjectId, UserId, ProjectId) Create Posts table (PostId, PostContent..., PostDate)

最后一个表真的取决于实际数据和读/写频率。如果您只想通过很少的插入操作获得读取性能，那么在任何现代 RDBMS 中都可以实现，多个选项：

一个表 UserPosts(UserProjectId, PostId) 这将是一个巨大的表，肯定会跨越数十亿行，但它可以处理它。
您可以根据数量为 UserProjectId 的范围创建多个 UserPosts 表，然后在其上创建一个 View/Function 以根据 UserProjectId 决定选择哪个表。

【讨论】：

【解决方案2】：

如果我理解您的应用程序，您目前正在比较两种解决方案：

创建N个数据库，每个数据库包含1个表，包含1个项目数据
创建 1 个数据库，包含 1 个表，包含 N 个项目的数据（需要一个额外的项目 ID 列）

还有第三种可能，就是

创建1个数据库，包含N个表，每个表包含1个项目

性能：如果您只访问一个项目的数据，(1) 和 (3) 之间的性能差异往往是微不足道的在任何给定时间，（在 (1) 的情况下都在同一台服务器上运行）。如果您一次访问多个项目，(3) 往往会更快、更容易。 There is a ton StackOverflow 上比较其他两个选项 (2) 和 (3) 的信息，单表与多表-桌子。大多数情况下，性能差异很小，索引到位，但并非微不足道。

可扩展性：您声明每个项目都有数千行。你没有说明可能有多少项目。您也没有说明需要多久请求或更改该数据。因此，以下所有内容都只是一个指导原则：现代服务器可以在单个数据库实例中轻松处理数百万行（1k/行，即千兆字节），并且每分钟轻松处理数千个请求（如果设计得当）。当涉及数十亿行或更多行（数 TB 数据）或multiple thousands of requests per second 时，他们开始挣扎。这在很大程度上取决于数据库本身的设计何时会碰壁，但是一旦达到某个数据库实例由于大小或速度原因无法再处理它的大小，您将不得不扩展@ 987654326@。使用多个数据库时，水平扩展（即添加更多服务器）更容易且成本更低。将您的项目分离到不同的数据库中可能会使这更容易，但这样一个简单的解决方案很可能会导致大量服务器闲置而其他服务器运行很热。大多数现代数据库系统允许将单个数据库拆分到多台机器上，即使在一个数据库中也是如此。

最后，您没有指定足够的内容来真正回答您的问题。从你写它的方式来看，我猜你目前还没有真正做出最终决定——你只是想不把自己打到自己的脚上。所以这里有一个快速指南

如何不射中自己的脚

将所有数据库访问代码从一个代码单元中分离出来。
将所有程序逻辑保留在该代码之外
妥善维护和记录这段代码
让了解多个 DBMS 的人查看您的查询，以确保它们易于移植

如果您这样做，您以后只需修改一个文件即可更改数据库系统或更改数据分区。您甚至可以通过交换单个代码文件来对不同的设计进行基准测试。

【讨论】：