php - 关于构建大数据量数据库的建议

Question

我正在 Windows 服务器上使用 JavaScript、MySQL 和 PHP 进行 RIA。

我想将 5,000 个结构相同的数据集放入数据库中。 5 个表足以容纳数据，除了一个表对于典型数据集有 300,000 多条记录外，所有表都相当小。

此外，500 位用户将获得对从这些数据集编译的统计数据的只读访问权限。这些统计信息由 PHP 提供(不允许直接访问)。此外，他们对数据的访问也各不相同。一些用户只能使用一组数据，另一些用户只能使用一些、一些、全部。

用户看到的结果比较小；大多数请求返回的行数远低于 100 行，最大的请求约为 700 行。所有请求都是通过 JavaScript RIA，它使用 Ajax 连接到 PHP，然后 PHP 连接到数据，执行其操作并输出 JSON 作为响应，然后 JavaScript 相应地呈现该 JSON。

在考虑如何构建它时，出现了三个选项:

1. 将数据集放在同一个表中。这可以轻松地在最大的表中提供 1,500,000,000 条记录。

2. 为每个数据集使用单独的表格。这将限制最大的表大小，但可能意味着 25,000 个表。

3. 忘记数据库并坚持使用专有格式。

出于几个原因，我倾向于#2。

1. 我担心使用非常大的表时出现的问题(例如:查询速度、实现限制等)。

2. 单独的 table 看起来更安全；它们限制了错误和结构变化的影响。

3. 单独的表允许我使用 MySQL 的表级安全性，而不是实现我自己的行级安全性。这意味着更少的工作和更好的保护；例如，如果在没有行级安全性的情况下意外发送查询，用户可能会获得未经授权的数据。表级安全性并非如此，因为数据库会立即拒绝查询。

这些是我的想法，但我想听听你的想法。您认为这是正确的选择吗？如果没有，为什么不呢？我忽略了哪些考虑因素？如果可扩展性是一个问题，我是否应该考虑其他平台？

Answer 1

1) I'm concerned about issues in using very large tables (eg: query speeds, implementation limits, etc...).

DBMS 是否必须...

• 搜索一个表的大索引，
• 或搜索正确的表，然后搜索该表的较小索引

...在性能方面可能没有太大区别。如果有的话，第二种情况有一个未记录的组件(定位正确表的性能)，所以我不愿意完全信任它。

如果要对数据进行物理分区，MySQL supports that directly从版本 5.1 开始，因此您不必通过单独的表来模拟它。

2) Separate tables seem safer; they limit the impact of errors and structure changes.

这就是备份的用途。

3) Separate tables allow me to use MySQL's table level security rather than implementing my own row level security.

确实如此，但是可以通过 View 或存储过程实现类似的效果。

总而言之，我的直觉是使用单个表，除非您事先知道这些数据集在结构上有足够的差异以保证单独的表。顺便说一句，我怀疑与优化良好的数据库相比，使用专有格式是否能够做得更好。