Важнейшие $in'ы: производительность MongoDB в диапазонах

[7workers]

Еще один момент, который неплохо знать заранее: индекс по полю «carsOwned» займёт больше памяти, чем индекс по полю «co» (длина названия поля имеет значение!). Не намного, но больше. Когда счёт идёт на десятки и сотни миллионов записей разница может оказаться сотни мегабайт.

[freetonik]

О, не знал и не думал о таком, спасибо!

[Rathil]

Провел эксперимент:

var f = function (t) {
    for (var i = t; i < t + 1000000; ++i) {
        db.test.insert({t:i, tttttttttt:i});
    }
}
f(0)
f(1e6)
f(2e6)

db.test.ensureIndex({t:1})
db.test.ensureIndex({tttttttttt:1})

После:

db.test.stats()
{
        "sharded" : false,
        "primary" : "rs2",
        "ns" : "test44.test",
        "count" : 3000000,
        "size" : 168000032,
        "avgObjSize" : 56.00001066666667,
        "storageSize" : 230584320,
        "numExtents" : 15,
        "nindexes" : 3,
        "lastExtentSize" : 62537728,
        "paddingFactor" : 1,
        "systemFlags" : 1,
        "userFlags" : 0,
        "totalIndexSize" : 259326368,
        "indexSizes" : {
                "_id_" : 97343456,
                "t_1" : 80991456, // размер первого
                "tttttttttt_1" : 80991456 // размер второго
        },
        "ok" : 1
}

На 3М у меня разницы нет даже в байте.

[xdevel]

Ложное утверждение. Mongodb не хранит названия ключей в индексах для экономии места.
пруф www.youtube.com/watch?feature=player_embedded&v=a7TrHP1C6qQ#t=765s

[Rathil]

7workers:
ответ на Ва ш коммент ( сорри, нет кармы)

docs.mongodb.org/manual/faq/developers/

мотайте на заголовок «use shorter field names». Не знаю, почему у Вас в тесте так, у меня на боевых серверах разница значительная.

[Rathil]

Да, но приведенная Вами ссылка говорит именно о данных, а не о индексах.
На счет данных не буду спорить, у самого поля называю короткими именами, а в приложении идут разъяснения что «это» такое, т.к. вопрос стоит не только в хранении этих имен полей, а еще и в передаче их между приложением и базой! Тут не как в старом привычном Мускуле где сперва идет заголовки с именами, а за ними уже идут данные, тут в каждом документе идут имена всех полей, ну это и понятно, т.к. документы могут быть кардинально разными.

[jinxal]

Мучают меня сомнения по поводу статьи.
Если вариативность и сортируемого поля (допустим — точное время регистрации reg_date) и поля фильтрации (допустим — дата рождения birth_date) очень высока, а диапазон мал ( db.collection.find({«birth_date»: {"$in": [ISODate(«1980-01-01»), ISODate(«1981-01-01»)]}}).sort({«reg_date»: 1}) ), то:

1. ensureIndex({reg_date:1, birth_date:1})
При таком индексе мы просканируем практически весь индекс для фильтрации, что долго. Но да, не потратим время на сортировку.

2. ensureIndex({birth_date:1, reg_date:1})
При таком индексе мы быстро получим данные, но затем будем их сортировать. НО: так как данных будет мало, то время на сортировку будет незначительно!

Так что, не следует слепо следовать данной методике.

[vittore]

Меня вот и смутила эта статья отсутствием такого анализа. И писал же при этом не кто-нибудь, а Эрик.

[freetonik]

Слепо следовать ничему не следует – в этом один из главных посылов статьи. Оценивать реальное выполнение запросов и использование индексов – вот что предлагает делать нам автор (что вы, собственно, и делаете).