Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Еще один момент, который неплохо знать заранее: индекс по полю «carsOwned» займёт больше памяти, чем индекс по полю «co» (длина названия поля имеет значение!). Не намного, но больше. Когда счёт идёт на десятки и сотни миллионов записей разница может оказаться сотни мегабайт.
О, не знал и не думал о таком, спасибо!
Провел эксперимент:
После:
На 3М у меня разницы нет даже в байте.
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М у меня разницы нет даже в байте.
Ложное утверждение. Mongodb не хранит названия ключей в индексах для экономии места.
пруф www.youtube.com/watch?feature=player_embedded&v=a7TrHP1C6qQ#t=765s
пруф www.youtube.com/watch?feature=player_embedded&v=a7TrHP1C6qQ#t=765s
7workers:
ответ на Ва ш коммент ( сорри, нет кармы)
docs.mongodb.org/manual/faq/developers/
мотайте на заголовок «use shorter field names». Не знаю, почему у Вас в тесте так, у меня на боевых серверах разница значительная.
Да, но приведенная Вами ссылка говорит именно о данных, а не о индексах.
На счет данных не буду спорить, у самого поля называю короткими именами, а в приложении идут разъяснения что «это» такое, т.к. вопрос стоит не только в хранении этих имен полей, а еще и в передаче их между приложением и базой! Тут не как в старом привычном Мускуле где сперва идет заголовки с именами, а за ними уже идут данные, тут в каждом документе идут имена всех полей, ну это и понятно, т.к. документы могут быть кардинально разными.
На счет данных не буду спорить, у самого поля называю короткими именами, а в приложении идут разъяснения что «это» такое, т.к. вопрос стоит не только в хранении этих имен полей, а еще и в передаче их между приложением и базой! Тут не как в старом привычном Мускуле где сперва идет заголовки с именами, а за ними уже идут данные, тут в каждом документе идут имена всех полей, ну это и понятно, т.к. документы могут быть кардинально разными.
Мучают меня сомнения по поводу статьи.
Если вариативность и сортируемого поля (допустим — точное время регистрации 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})
При таком индексе мы быстро получим данные, но затем будем их сортировать. НО: так как данных будет мало, то время на сортировку будет незначительно!
Так что, не следует слепо следовать данной методике.
Если вариативность и сортируемого поля (допустим — точное время регистрации 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})
При таком индексе мы быстро получим данные, но затем будем их сортировать. НО: так как данных будет мало, то время на сортировку будет незначительно!
Так что, не следует слепо следовать данной методике.
Меня вот и смутила эта статья отсутствием такого анализа. И писал же при этом не кто-нибудь, а Эрик.
Слепо следовать ничему не следует – в этом один из главных посылов статьи. Оценивать реальное выполнение запросов и использование индексов – вот что предлагает делать нам автор (что вы, собственно, и делаете).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Важнейшие $in'ы: производительность MongoDB в диапазонах