海量数据的可扩展数据库方案和服务器选择

Question

我开始在一家初创公司工作，我打算在那里编写后端。这是我第一次需要与这个大项目合作，我想问几个问题，看看什么是最佳实践。我将首先解释工作流程和信息，而不是征求您的宝贵意见。 该项目旨在将多家制药公司（最多 10 家）与许多（最多 20.000 家）药店联系起来。药店应该上传截图或pdf文件，我需要从这些文件中收集信息。每个药房最多可能上传 100 个屏幕截图和一些 pdf 文件，但他们可能会为不同的制药公司执行此过程。假设一家药店为公司 a、公司 b 和公司 c 上传了 100 个 ss 和 2 个 pdf，所以总共 300 个图像和 6 个 pdf。此外，从 pdf 读取或使用 ocr 系统获取图像需要时间。每个 pdf 将包含有关 50 种药物的信息（交易数据）。我将有药物表和交易表。每种药物平均有 7 笔交易。我觉得一段时间后事务表会很大，在那个大表上运行查询会很昂贵。 这是我的问题

1)我打算使用 MySQL，是否足以满足我的目的？

2)我是否应该为每家公司建立一个单独的数据库，或者最好将所有内容都保存在一个公司中。

3) 实施 Drugs and Transactions 表的最佳做法是什么。最简单的方法就是使用外键，但正如我所说，一段时间后事务表会很大，所以也许有更好的方法来规划它。

4）我应该使用专用服务器还是选择像 AWS 这样的服务。正如我所说的从 pdf 阅读或使用 ocr 需要时间。

5) 哪个存储选项对这个项目是合理的。同样，专用服务器或 AWS 存储等服务。

6）当我阅读药品信息时，它会有药品数据和大约 7 笔交易。所以我需要每种药物写入数据库 8 次。有没有更便宜的选择？

非常感谢您的回答:)

Answer 1

对 MySQL 的思考：

• 数千行是“小”；百万是“中等规模”。
• 十亿行的表存在一些挑战，但它是可行的。
• 我最好的建议是计划在大约 4 个月内重写整个架构和代码。有了这个建议，您可以匆忙构建一些东西，然后了解为什么它不是最优的；然后重建它。
• 根据需要使用尽可能多的表。 （听起来您可能需要几十个。一千个表可能表明您做错了。）
• 考虑将图像、pdf 等存储在文件中，而不是表中。然后将文件路径放在一个表格中。

阅读 PDF 应该只完成一次，然后将 OCR 的结果捕获到文本文件（或MEDIUMTEXT 列）中。之后，您可以编写代码（使用或不使用 SQL）对其进行解析并将重要数据复制到数据库中。 并且当您发现解析不充分时，您可以重新执行此操作。