MySQL或MongoDB，用于按降序排序的数百万行

在每台服务器上，我都有几个客户数据库，其中包含用户活动表、帐户更改日志和其他一些表。每个表将在未来一年左右的时间内添加数千万行

对于用户活动的情况，所有数据都将按时间降序读取，其中userID为X，但一次只能读取大约10个

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

我想知道MySQL InnoDB是否是在每个客户数据库中存储这些数据的最佳方式。我在考虑MongoDB，但我一直在读skip（）变得非常慢，我找不到关于sort then skip的详细信息。也许还有另一种选择

---

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

您的MySQL版本是什么？ 如果是5.1或更高版本，表是否已分区？我认为按年划分可能会有所帮助，因为您对表的关注会持续多年

两种方法都要尝试

简单地说，这里真的没有一个正确的答案。它会因您的需求、模式或文档结构、查询、索引、硬件、您是否愿意（以及硬件的可用性）进行切分而变化很大

这两种方法都适用于您想要实现的目标，并且对于这些类型的问题，每种方法都有自己的解决方案—例如：

外键和连接vs嵌入式文档

或

分片vs分区

。如果操作正确，两个数据库都可以很好地工作

随着您的扩展，您的性能改进很可能包括缓存、预聚合/预处理、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...
    ]
}

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

---

但是，您也可能会发现，在按类型或日期查询活动日志时需要更大的灵活性，在这种情况下，嵌入可能不起作用。

为什么不将10个活动分组，列出并形成一个文档。这样跳绳就不会那么慢了。每个查询最多只能是单磁盘抓取。我这样做了，但将其修改为有一个文档记录用户在哪一天完成的日志，然后是另一个文档记录用户在哪一天完成的日志。