总计数十亿行和每天数百万行插入：哪种数据库系统最适合

Question

我们开发了一个数据量非常大但数据结构非常简单的系统。我们只有cellX，cellY，timeStamp和value列。

操作是：

• 每天插入455+ 千行
• 使用范围过滤器查询cellX,cellY和timeStamp
• 查询不需要立即返回，我们可以在请求的数据准备好时通知用户。

因为数据太大，查询需要索引，所以采用了这个方案：

1. 使用 SQL Server。
2. 聚集在指数cellX，cellY和timeStamp。
3. 每年都有单独的表，因此表中的总行数保持在限制范围内（~1.66 亿）。
4. 使用自定义格式timeStamp。跳过年份，只保留月份、日期和小时。我们能够将其保持在 16 位整数内。
5. 在每个年份表上使用分区。
6. 一次插入一天的数据。在插入数据时使用分区切换来保持数据库处于活动状态。

到目前为止，这一直运作良好。虽然我们在数据准备好后通知用户，但只要查询合理，延迟不会超过几秒。
但最近我们有机会获得更精确的数据，数据量增加了68 倍！。因此，现在我们有：

• 每天插入30 多万行。
• 在一个表中存储110 亿行一年。这可以通过制作季度（27 亿）或每月（10 亿）表来减少。

这可能是我们在一两年内能够收到更精确的数据。因此，数据量可能会再次显着增加。

问题是，我们使用的这个方案会持续吗？或者我们应该迁移到另一个方案，可能是另一个数据库系统离开SQL Server？

---

编辑

这三个维列cellX，cellY并timeStamp在本质上非常有规律。您可以通过f(x) = mx + c, 为某些整数x范围 ( 0, 1, 2, ..., X)定义所有这些 。

Answer 1

我使用过一个 30+ 十亿行的每月分区表，具有页面压缩和 10 年的历史。表模式相当简单，在 varchar 列和几个非索引列上有一个 datetime2(2) 聚集索引和 3 个非聚集索引。存储容量约为 2TB，性能相当不错。由于需要近乎实时的数据，因此使用 SqlBulkCopy 全天连续插入大约 1500 万行。

根据这个轶事，我相信 SQL Server 可以使用足够大的硬件来处理您预期的容量。话虽如此，我完全同意 @DamianoVerzulli 的观点，即由于您对延迟的容忍度，您的应用程序是成本较低的 NoSQL 解决方案的绝佳候选者。