1

在每台服务器上，我将有几个客户数据库，其中包含用于用户活动、帐户更改日志和其他一些表格的表格。在接下来的一年左右，每个表将添加数千万行，直至无穷大。

对于用户活动的情况，所有数据将按时间降序读取，其中 userID 为 X，但一次限制为 10 个左右。

这似乎是合理的，但是对于几个数据库中的几个表，这是一个好的方法吗？我担心事情会慢很多，尤其是随着桌子在未来几年的增长。我应该以某种方式拆分表格吗？

我想知道 MySQL InnoDB 是否是将这些数据存储在每个客户数据库中的最佳方式。我正在考虑使用 MongoDB，但是我一直在阅读 skip() 变得非常慢，而且我找不到关于排序然后跳过的太多细节。也许还有另一种选择。

基本上，什么是（存储然后）读取按时间降序排序的最新信息的绝对最快方法？显然，我会尽一切努力使查看用户信息的阅读时间尽可能快。

4

2 回答 2

2

你需要尝试两者。

简单地说——这里真的没有正确的答案。它会因您的要求、架构或文档结构、查询、索引、硬件、您对分片的意愿（和硬件的可用性）等而有很大差异。

两者都适用于您想要实现的目标，并且对于这些类型的问题都有自己的解决方案 - 例如：foreign keys and joins vs embedded documents或sharding vs partitioning. 正确完成后，两个数据库都可以很好地工作。

随着您的扩展，您的性能改进很可能包括缓存、预聚合/预处理、mapreduce 等 - 无论您选择哪种数据库后端。

以 MongoDB 为例：

听起来最近的活动是观看次数最多的——这应该意味着即使您的收藏增加，您的工作集理论上也应该保持较小。因此，您可以为每个用户每天创建一个文档，其中包含每个活动的嵌入式文档。

{
    _id: ObjectId(...),
    user: 123,
    timestamp: 1370847600,
    activities: [
        { _id: ObjectId(...), type: 1, msg: "Something was logged.", date: IsoDate(...) },
        { _id: ObjectId(...), type: 2, msg: "Something else was logged.", date: IsoDate(...) },
        //More Activities here...
    ]
}

如果您觉得一天不够细，或者您觉得您的文件太大，请按小时分组。这将有助于保持索引大小/工作集合理，并允许您在没有连接的情况下获取多个活动。

但是，您也可能会发现在仅按类型或日期查询活动日志时需要更大的灵活性——在这种情况下，嵌入可能无法正常工作。

于 2013-06-10T17:37:09.927 回答
1

你的 MySQL 是什么版本？如果是 5.1 或更高版本，表是分区的吗？我认为按年分区可能会有所帮助，因为您担心表会增长多年。

于 2013-06-10T17:35:40.153 回答