performance - 在数据库中存储整数数组

Question

我正在创建一个可存储 100.000(将来可能更多)用户的数据库。虽然这显然发生在每个用户 1 行的表中，但每个用户都可以(并且将会)存储数百个项目。在编程语言中，这意味着用户有 2 个整数数组(或一个二维数组):一列用于 itemid，一列用于金额。

我的直觉告诉我创建一个表来保存所有这些项目，其中的行如 (userid, itemid, amount)。然而，这将导致一张巨大的 table 。 200.000 个用户，每个用户有 250 个项目……一张表中有 5000 万个条目。这一点，再加上 table 会持续快速变化的事实，让我感到害怕。 (多快？我估计每秒最多可进行 100 次修改。)

通常会有 100 到 2000 名用户，他们都在添加和删除项目以及修改金额。这些操作可以并且将会在编程代码中发生。它将如下所示:

• 用户启动 session ，程序从数据库中加载所有用户项
• 用户修改项目列表
• 每隔几分钟，更改就会保存到数据库中
• 当用户结束 session 时，也保存到数据库中

值得注意的是，用户可以存储的项目数量是有上限的。

除了使用单独的表格，还有其他选择吗？也许将值保存在格式化的文本字符串中？或者这是使用 MySQL 数据库实际上是一个 Bad Idea™ 的实例之一？

感谢您的宝贵时间和见解。

Answer 1

My instincts tell me to create a table to hold all these items

你的直觉是对的。

1) 避免过早优化

2) 不要违反规范化规则，除非你有充分和真实的理由这样做

3) 为什么你怀疑多表方法会更快？

that's 50 million entries in one table

那又怎样？即使您只有 userid 上的索引，与每个用户的单个表相比，性能差异也不会明显变慢(实际上，有 200,000 个用户，它会快得多，因为 DBMS 可以轻松地保持开放每个表的文件句柄!)。

I estimate up to 100 modifications per second

应该可以使用 MySQL 和相当基本的硬件，但如果是我，并且我想要一点空间，我会使用一对镜像 SATA 磁盘，一个镜像上的表，另一个镜像上的索引。

我唯一关心的问题(无论您选择两种型号中的哪一种都适用)是支持 2000 个并发连接。连接必须是并发的吗？或者每个用户都可以下载一个工作集(可选地使用乐观锁定策略)并关闭连接，然后在新连接上推回更改？如果没有，那么您可能需要大量使用内存和 CPU。

但是撇开是使用一个大表还是使用许多小表不谈，如果这是数据的唯一用途，并且对特定数据项的访问不是并发的，那么为什么还要费心使用关系数据库呢？ NoSQL 或共享文件系统可能同样有效。