MongoDB: слишком много полей для индексации? Используйте общий индекс

[mayorovp]

Хм. А ведь это решение можно обобщить для всех баз данных, не только MongoDB…

[RNZ]

уже: postgresql hstore + gis/gist

[mayorovp]

Это какая-то технология, поддерживаемая СУБД?
Я-то говорил про модификацию схемы данных, что можно сделать независимо от используемой СУБД.

[RNZ]

такая схема называется «слабоструктурированные данные», под них и заточен hstore с индексами gis/gist.

[ncix]

Ну да, можно и в реляционной БД хранить данные в формате key-value, однако сразу огребаем проблемы с типами. Также, невозможно использовать внешние ключи и каскадные операции.

[mayorovp]

Да, с внешними ключами проблема, хотя про невозможность вы зря сказали — гибридную схему никто не отменял.
Про недостатки схемы key-value я давно знаю, а вот тот факт, что у такого способа есть еще и достоинства, я узнал только сейчас.
Впрочем, мне и поиск по всем полям раньше делать не доводилось.

[ncix]

Да, истина как всегда где-то между :) гибридная схема может иметь смысл.

Но на счет эффективности одного индекса против нескольких в реляционной БД, я бы так сходу ответ не дал. Сложный вопрос. И от данных зависит.

[servitRM]

> Для наглядности создадим миллион документов состоящих из фиктивных свойств
> for (var i = 0; i < 5000000; ++i)

И всё же миллион или пять миллионов?

[ncix]

Автор, явно не хватает зависимости времени вставки от варианта решения.

[yurtaev]

Я не автор, это лишь мой ужасный перевод =) Но я воспроизводил эти примеры и попробовал сделать замер вставки после создания индексов:

Решение #1

> beginTime=new Date();for(var i=0;i<1000000;++i){var arr=[];for(var j=0;j<10;++j){arr.push({n:"prop"+j,v:Math.floor(Math.random()*1000)})}db.generic.insert({props:arr})}print((new Date()).getTime()-this.beginTime.getTime());
531189

Решение #2

> beginTime=new Date();for(var i=0;i<1000000;++i){var arr=[];for(var j=0;j<10;++j){var doc={};doc["prop"+j]=Math.floor(Math.random()*1000);arr.push(doc)}db.generic2.insert({props:arr})}print((new Date()).getTime()-this.beginTime.getTime());
532890

P.S без индексов вставка была ~16к insert/s

[ncix]

Т.е. оба варианта решения уменьшили скорость вставки примерно одинаково, в 8 раз.

[uaoleg]

Делал нечто похожее. Только я склеивал ключ и значение. Например: prop0-40, prop1-198. Ваше решение конечно более гибкое, т.к. даёт возможность искать в том числе и по диапазоном, а моё работает только на сравнение.

[nightshadows]

А теперь создадим в 10 раз больше документов и всё равно получаем индекс, не влазящий в оперативную память. А на FreeBSD это гарантированный крэш, даже не торможение.

[mayorovp]

Хм, а почему на FreeBSD индекс, не влазящий в оперативную память, приведет к крэшу?

[nightshadows]

Это вопросы к разработчикам. По-моему, они неправильно используют memory map. Там всё очень плохо становится, когда база вместе с индексами приближается по объёму к размеру оперативной памяти. На линуксе всё просто тормозить начинает (довольно логично), а на фрях — плохо дело.

[anonimizer_me]

Отлично! Решил после этого поста обновить mongodb и переписать поиск по таблице с пользователями

[Lihonosov]

Правильно ли я понимаю что в первом варианте нельзя сделать сортировку, а во втором варианте возможен поиск только по одному полю?