1

我确实提出了以下想法，但我不知道它是否适用于生产应用程序。

我们有一个基于 PHP/mySQL 构建的 Web 应用程序，使其变得简单。数据库中的表很容易变大 - 几百万条记录很容易，因此表分片可能是这里的一种选择。

这是我想象的工作过程的方式：

缓存文件包含数据库中可用表的列表。每个表最多包含一百万行，当达到这一点时，在构建新表后重新创建缓存列表。

显然，检查每次写入表时的行数并不是一个好主意，因此可以在设定的时间间隔内完成，例如一周或每天 - 取决于每百万数据的创建速度。

这是处理大量数据并保持索引大小相当低的好方法吗？

谢谢

4

4 回答 4

3

如果您正在提前计划巨大增长的可能性（例如，游戏病毒式传播），您可以按照您之前的步骤并使用 NoSQL。

Couchbase / 为 Zinga 提供支持（并且是个人最喜欢的）
Apache Cassandra / 为 Twitter
mongoDB 提供支持/ 为 Craiglist 提供支持

但是你在php/MySQL 中建立一个站点是为了“让它变得简单”，所以不要在一个非常大的问题上重新发明轮子。

不要乱用数据。寻求经过验证的解决方案。包括 MySQL。

于 2010-08-13T18:53:22.283 回答
2

您应该使用水平分区，按记录数对表进行分区，假设每个分区将有一百万条记录，这样 mysql 将在内部处理分区，除了一个大索引之外，索引也将被分区。

在这里阅读更多http://dev.mysql.com/tech-resources/articles/performance-partitioning.html

于 2010-08-13T19:36:01.313 回答
1

老实说，我认为这不是一个好主意。您应该考虑归档旧数据或使用像 MOngo 这样的 NoSQL 解决方案。

于 2010-08-13T18:43:22.290 回答
1

The performance of indexes does not degrade linearly with the size of the table. Tables have to be seriously massive before that becomes an issue. If you are seeing performance problems, I'd start doing mysql 'explains' and making sure all your queries are doing the least amount of row scans they can do. You might be suprised at what the actual bottleneck ends up being.

So, basically, if you need the data, I wouldnt go messing around with it. On the other hand, if its something like session data, just delete the rows that are too old.

于 2010-08-13T19:44:22.343 回答