php - 如何创建一个性能系统来计算大型动态数据集中的标签

Question

概览

我有一个 iOS 应用程序，人们可以在其中通过 tags 进行搜索，其中一些标签是预定义的，一些是用户定义的。

当用户写下他/她想要搜索的标签时，我想显示一行，显示这些标签可用的结果数量(参见示例搜索图片)。

注意 #Exercise 或 #Routine 是父级 tag 意味着这个人总是会使用其中之一。

我正在使用 PHP 和 MongoDB 服务器端。我虽然创建了一个文件，其中包含每小时计数的标签，以便所有客户端都可以获取它并最大限度地减少资源消耗。

鉴于被操纵的信息是用户控制的标签，该列表将随着时间的推移而显着扩展。

挑战

• 我对考虑到什么是最好的方法感到困惑创建、操作和存储此类的性能和开销列表。

我的第一个想法 是创建一个二维数组(参见图片)来存储我的所有值。然后将其转换为 JSON，以便将其存储到 MongoDB 中。

但这种方法会让我获取所有标签并将它们加载到内存中以执行任何 +1 或 -1。因此，我认为它可能不是最好的。

所有操作都发生在插入、更新和删除每个元素时。因此会有相当大的 RAM 开销。

我的第二个想法是创建一个文档，我在其中存储所有使用过的标签，并每小时进行一次计数查询以生成列表客户使用。

这意味着在每次删除、更新和插入时检查标签是否存在于此文档上，并根据条件创建或删除或什么也不做。

每小时获取所有标签，生成一个包含所有标签组合的数组。针对所有标签组合查询数据库并计算返回结果的数量并创建文件。

鉴于我使用 MongoDB 而不是 MySQL，我认为这种方法可能是更好的方法。但我仍然不确定它的性能。

有没有人制作过类似的系统并且可以建议更好的方法？

搜索示例图片

二维数组

Answer 1

使用 mongodb 时要考虑的最重要的事情之一是，在决定数据库设计时，您必须考虑应用程序的访问模式。我们将尝试通过一个示例来解决您的问题，并看看它是如何工作的。

假设您的收藏中包含以下文档，下面让我们看看如何让这种简单的数据格式发挥作用:

> db.performant.find()
{ "_id" : ObjectId("522bf7166094a4e72db22827"), "name" : "abc", "tags" : [  "chest",  "bicep",  "tricep" ] }
{ "_id" : ObjectId("522bf7406094a4e72db22828"), "name" : "def", "tags" : [  "routine",  "trufala",  "tricep" ] }
{ "_id" : ObjectId("522bf75f6094a4e72db22829"), "name" : "xyz", "tags" : [  "routine",  "myTag",  "tricep",  "myTag2" ] }
{ "_id" : ObjectId("522bf7876094a4e72db2282a"), "name" : "mno", "tags" : [  "exercise",  "myTag",  "tricep",  "myTag2",  "biceps" ] }

首先，您绝对必须在标签上创建索引。 (如果需要，您可以创建复合索引)

> db.performant.ensureIndex({tags:1})
> db.performant.getIndexes()
[
    {
            "v" : 1,
            "key" : {
                    "_id" : 1
            },
            "ns" : "test.performant",
            "name" : "_id_"
    },
    {
            "v" : 1,
            "key" : {
                    "tags" : 1
            },
            "ns" : "test.performant",
            "name" : "tags_1"
    }
]

要从上述集合中查询标签数据，通常会使用 db.performant.find({tags:{$in:["bicep"]}})，但这不是个好主意 。让我告诉你原因:

> db.performant.find({tags:{$in:["bicep","chest","trufala"]}}).explain()
{
    "cursor" : "BtreeCursor tags_1 multi",
    "isMultiKey" : true,
    "n" : 2,
    "nscannedObjects" : 3,
    "nscanned" : 5,
    "nscannedObjectsAllPlans" : 3,
    "nscannedAllPlans" : 5,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
            "tags" : [
                    [
                            "bicep",
                            "bicep"
                    ],
                    [
                            "chest",
                            "chest"
                    ],
                    [
                            "trufala",
                            "trufala"
                    ]
            ]
    },
    "server" : "none-6674b8f4f2:27017"
}

您可能已经注意到，此查询正在执行整个集合扫描。这可能会让你想知道，为什么我们添加了那个索引，如果它没有被使用，我也想知道。但不幸的是，这是一个 mongoDB 尚未解决的问题(至少在我看来是这样)

幸运的是，我们可以绕过这个问题并且仍然使用我们在标签集合上创建的索引。方法如下:

> db.performant.find({$or:[{tags:"bicep"},{tags:"chest"},{tags:"trufala"}]}).explain()
{
    "clauses" : [
            {
                    "cursor" : "BtreeCursor tags_1",
                    "isMultiKey" : true,
                    "n" : 1,
                    "nscannedObjects" : 1,
                    "nscanned" : 1,
                    "nscannedObjectsAllPlans" : 1,
                    "nscannedAllPlans" : 1,
                    "scanAndOrder" : false,
                    "indexOnly" : false,
                    "nYields" : 0,
                    "nChunkSkips" : 0,
                    "millis" : 10,
                    "indexBounds" : {
                            "tags" : [
                                    [
                                            "bicep",
                                            "bicep"
                                    ]
                            ]
                    }
            },
            {
                    "cursor" : "BtreeCursor tags_1",
                    "isMultiKey" : true,
                    "n" : 0,
                    "nscannedObjects" : 1,
                    "nscanned" : 1,
                    "nscannedObjectsAllPlans" : 1,
                    "nscannedAllPlans" : 1,
                    "scanAndOrder" : false,
                    "indexOnly" : false,
                    "nYields" : 0,
                    "nChunkSkips" : 0,
                    "millis" : 0,
                    "indexBounds" : {
                            "tags" : [
                                    [
                                            "chest",
                                            "chest"
                                    ]
                            ]
                    }
            },
            {
                    "cursor" : "BtreeCursor tags_1",
                    "isMultiKey" : true,
                    "n" : 1,
                    "nscannedObjects" : 1,
                    "nscanned" : 1,
                    "nscannedObjectsAllPlans" : 1,
                    "nscannedAllPlans" : 1,
                    "scanAndOrder" : false,
                    "indexOnly" : false,
                    "nYields" : 0,
                    "nChunkSkips" : 0,
                    "millis" : 0,
                    "indexBounds" : {
                            "tags" : [
                                    [
                                            "trufala",
                                            "trufala"
                                    ]
                            ]
                    }
            }
    ],
    "n" : 2,
    "nscannedObjects" : 3,
    "nscanned" : 3,
    "nscannedObjectsAllPlans" : 3,
    "nscannedAllPlans" : 3,
    "millis" : 10,
    "server" : "none-6674b8f4f2:27017"
}

如您所见，n 非常接近 nscanned。扫描了三个记录 1，每个记录对应于“bicep”、“chest”、“trufala”。由于“bicep”和“chest”属于同一个文档，因此只返回1个对应的结果。一般来说，count() 和 find() 都会进行有限的扫描，而且效率很高。此外，您永远不必为用户提供过时的数据。您也可以完全避免运行任何类型的批处理作业!!!

因此，通过使用这种方法，我们可以得出以下结论:如果按n 个标签进行搜索，并且每个标 checkout 现m 次，则扫描的文档总数为n * m。现在考虑到你有大量的标签和大量的文档，并且你通过几个标签进行扫描(这反过来对应于几个文档 - 虽然不是 1:1)，结果总是非常快，因为发生 1 个文档扫描每个标签和文档组合。

注意: 这种方法永远无法覆盖索引，因为数组上有一个索引，即“isMultiKey”:true。您可以阅读有关涵盖索引的更多信息 here

局限性:每种方法都有局限性，这个也有!!对结果进行排序会产生极差的性能，因为它将扫描整个集合的次数等于传递给此查询的标记的次数加上它扫描与 $or 的每个参数对应的其他记录。

> db.performant.find({$or:[{tags:"bicep"},{tags:"chest"},{tags:"trufala"}]}).sort({tags:1}).explain()
{
    "cursor" : "BtreeCursor tags_1",
    "isMultiKey" : true,
    "n" : 2,
    "nscannedObjects" : 15,
    "nscanned" : 15,
    "nscannedObjectsAllPlans" : 15,
    "nscannedAllPlans" : 15,
    "scanAndOrder" : false,
    "indexOnly" : false,
    "nYields" : 0,
    "nChunkSkips" : 0,
    "millis" : 0,
    "indexBounds" : {
            "tags" : [
                    [
                            {
                                    "$minElement" : 1
                            },
                            {
                                    "$maxElement" : 1
                            }
                    ]
            ]
    },
    "server" : "none-6674b8f4f2:27017"
} 

在这种情况下，它扫描 15 次，等于 3 次全集合扫描，每次扫描 4 条记录，加上每个参数扫描的 3 条记录，用于 $ 或

最终结论:如果您对未排序的结果没有问题，或者愿意在前端付出额外努力自行对结果进行排序，则使用此方法可以获得非常高效的结果。