Python 如何使用addToSet提高更新性能

Python 如何使用addToSet提高更新性能,python,mongodb,pymongo,mongodb-query,Python,Mongodb,Pymongo,Mongodb Query,我收集了60多万张唱片。所有记录的结构如下(从我的js控制台) place字段是经常更新的内容。我想在place子文档中添加一些新记录。下面是我如何完成它的python过程 def update(doc, pos_list): add_to_set = {} add_to_set['place'] = {} add_to_set['place']['pageid'] = doc._id add_to_set['place']['index'] = pos_lis

我收集了60多万张唱片。所有记录的结构如下(从我的js控制台)

place
字段是经常更新的内容。我想在
place
子文档中添加一些新记录。下面是我如何完成它的python过程

def update(doc, pos_list):
    add_to_set = {}
    add_to_set['place'] = {}
    add_to_set['place']['pageid'] = doc._id 
    add_to_set['place']['index'] = pos_list # eg, pos_list = [1,2,3]

    data = self.collection.find_one({'_id': _id})
    # Check if 'pageid' is already there in the record.
    # If not, then update

    self.collection.update(
                        {'_id': _id},
                        {'$addToSet': add_to_set},
                        upsert=upsert, 
                        w=1
                    )
但是这个更新似乎慢得很!avr每次更新1.3秒。我正在运行10个子进程来提高速度。但这里是
mongostat

insert  query update delete getmore command flushes mapped  vsize    res faults    locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
    *0     25     19     *0       0     1|0       0  68.1g   137g   691m    130 spider:65.1%          0       1|0     6|0     5k    63m    37   20:14:30 
    *0      2      1     *0       0     1|0       0  68.1g   137g   629m    194 spider:10.8%          0       0|0     2|0   647b     8m    37   20:14:31 
    *0      5      8     *0       0     1|0       0  68.1g   137g   650m     27 spider:71.9%          0       6|0     1|0     1k     4m    37   20:14:32 
    *0     15     15     *0       0     1|0       0  68.1g   137g   654m    105 spider:52.4%          0       7|0     0|1     4k    32m    37   20:14:34 
    *0      9     12     *0       0     1|0       0  68.1g   137g   666m     38 spider:53.9%          0      11|0     0|1     2k     7m    37   20:14:35 
    *0     16     13     *0       0     1|0       0  68.1g   137g   633m    222 spider:46.6%          0       2|0     1|0     4k    40m    37   20:14:36 
    *0     10     11     *0       0     1|0       0  68.1g   137g   666m    103 spider:39.5%          0       6|0     0|1     2k    22m    37   20:14:38 
    *0     13     15     *0       0     1|0       0  68.1g   137g   655m     20 spider:90.0%          0      14|0     0|1     3k     1m    37   20:14:39 
    *0     18     17     *0       0     1|0       0  68.1g   137g   672m    179 spider:48.5%          0       0|0     5|0     5k    47m    37   20:14:40 
    *0     12     15     *0       0     1|0       0  68.1g   137g   661m    119 spider:40.2%          0       2|0     4|1     3k    15m    37   20:14:41 
insert  query update delete getmore command flushes mapped  vsize    res faults    locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
    *0      9      8     *0       0     1|0       0  68.1g   137g   682m    109 spider:27.5%          0       6|0     0|1     2k    32m    37   20:14:43 
    *0     19     21     *0       0     1|0       0  68.1g   137g   659m    147 spider:85.6%          0       6|0     2|0     5k    20m    37   20:14:44 
    *0     15     20     *0       0     1|0       0  68.1g   137g   684m    137 spider:63.1%          0       9|0     1|0     4k    12m    37   20:14:45 
    *0     18     13     *0       0     1|0       0  68.1g   137g   634m    197 spider:39.0%          0       0|0     4|0     5k    51m    37   20:14:46 
    *0      6      6     *0       0     1|0       0  68.1g   137g   638m    209 spider:13.9%          0       0|0     2|0     1k     3m    37   20:14:47 
    *0      4      9     *0       0     1|0       0  68.1g   137g   641m    121 spider:37.4%          0      13|0     0|1   866b     3k    37   20:14:49 
    *0     19     15     *0       0     1|0       0  68.1g   137g   618m    141 spider:50.7%          0       0|0     4|0     5k    58m    37   20:14:50 
    *0      2      3     *0       0     1|0       0  68.1g   137g   624m    181 spider:15.4%          0       6|0     0|1   528b   207k    37   20:14:51 
我唯一的索引是
\u id
字段。我有4GB内存。现在,我的问题是

  • 这是正常速度吗
  • 如何提高更新速度
编辑:我的索引

> db.invindex.stats()
{
    "ns" : "spider.invindex",
    "count" : 595306,
    "size" : 1302386304,
    "avgObjSize" : 2187,
    "storageSize" : 1580150784,
    "numExtents" : 19,
    "nindexes" : 1,
    "lastExtentSize" : 415174656,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 1,
    "totalIndexSize" : 25648112,
    "indexSizes" : {
        "_id_" : 25648112
    },
    "ok" : 1
}

为什么“place.index”本身就是一个数组?这没有任何意义。另外,谢谢你的统计数据,但是你的索引在哪里?如果您从未费心为正在查询的字段值编制索引,那么就没有多大用处。甚至在字段上有过多的索引,导致插入或更新时性能滞后。请在这里告诉我们整个故事。哦,修复我前面提到的阵列混乱。Just和advice point.@NeilLunn
place.index
是文档上出现的
\u id
的数组(由pageid标识)。所以它必须是一个数组(或集合)。正如我在问题上所写的,我唯一的索引是
\u id
(我也添加了这个日志!)。所以继续吧。重点是什么?大概有两个“键”及其值决定了集合。这应该很简单。您的性能统计数据表明,这些“阵列/集合”很可能有许多成员。有多少这里的快速提示是,如果您经常查看500个数组/集合条目,那么这是一件坏事。我预计,
$addToSet
尤其会随着实际数字的增加而“降级”。但在我展示我的之前,轮到你展示了。正如我所说,这将解释很多,500是真正的“下降”点。除此之外,性能几乎呈指数级下降。所以这是MongoDB和阵列的一个真正的硬限制。您的要求似乎更适合这些条目的单独集合。处理额外请求的成本似乎超过了您将看到的其他性能问题。我们将对此进行解释和“回答”,但这有点混乱。短视是“不要构建每个文档超过500个元素的数组”。
> db.invindex.stats()
{
    "ns" : "spider.invindex",
    "count" : 595306,
    "size" : 1302386304,
    "avgObjSize" : 2187,
    "storageSize" : 1580150784,
    "numExtents" : 19,
    "nindexes" : 1,
    "lastExtentSize" : 415174656,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 1,
    "totalIndexSize" : 25648112,
    "indexSizes" : {
        "_id_" : 25648112
    },
    "ok" : 1
}