标签: big-data

我们正在运行的应用程序收集数据的速度比我们预期的要快得多。为了适应这一点，我们正在重新设计数据库。读完这个、这个和这个后，我不确定我们设计的最佳方法是什么......考虑到我们的硬件非常简陋。

三个主要表导致了问题：

• 扫描
• 域名
• 文件
• 价值观

目前我们只有一张表来存储数据。它们之间的关系是：

• 1 次扫描->（平均 4x）域名->（平均 3000）许多文档->（平均 51000）许多值
  • 1 次扫描平均指向域名上的 4 个条目。
  • 域名上的 4 个条目意味着文档上平均有 12,000 个条目
  • DOCUMENTS 上的 12000 个条目意味着 VALUES 上平均有 204000 个条目

目前我们每天执行大约 100 次扫描。也就是说，每天向 VALUES 中插入大约 20,400,000 个项目。

我们正在考虑将 VALUES 表拆分为一个“VALUE_table_per_month”：

• VALUES_year_month旨在在它们之间分配负载。但如果我们增加扫描仪的数量，这种机制就无法升级。
• VALUES_year_month_day那么我们最终将在同一个数据库中放入如此多的表。

在这两种情况下，如果我们增加每天的扫描次数，似乎没有一个解决方案具有可扩展性。

此时，出于可扩展性的原因，将所有数据保存到集中式数据库中似乎不是最佳选择……但与此同时，分布式系统将显着增加加载时间。

什么是合理的方法？我确信我们不是第一个发现这个问题的团队！：P

编辑

每个查询读取多少数据？

这取决于扫描。并非所有扫描都具有相同数量的数据。范围变化如下：

• 1 次扫描 --> 200 个值
• 1 次扫描 --> 200.000 个值

该信息在前端呈现给最终用户。因此，我们将查询请求的方式拆分到后端，以避免服务器过载，但在某些情况下，由于 VALUES 数量较多，这还不够。

什么时候读取数据？

这完全取决于最终用户。有时他们每天会读 10 篇 SCANS，有时则不读，有时甚至每天读 …