Здравствуйте! Прошу совета, ибо уже сломал голову пытаясь решить задачу.
Нужно сделать поиск по пользователям сайта.
У пользователей могут быть указаны некоторые атрибуты (число возможных атрибутов 200-300).
В основном эти атрибуты не имеют значений, а являются, по сути, просто флагами (например, "есть борода").
Но есть и атрибуты со значениями (например, "рост" - "185").
Реально каждому пользователю присваивается порядка 5-50 атрибутов.
Количество пользователей - сотни тысяч. Но нужно иметь уверенность, что это сможет быть без проблем смасштабировано еще на пару порядков.

Таким образом, вроде бы, эта задача идеально ложится на Entity-attribute-value модель.
В принципе, можно конечно иметь в таблице несколько сотен колонок со всеми этими атрибутами, но поддержка решения при этом заметно усложняется (особенно учитывая, что оно должно работать в режиме 24/7, а новые виды атрибутов появляются довольно часто). Да к тому же индексирование каждой из этих колонок тоже повлечет свои проблемы.

В общем, типовой use case - это выборка пользователей, подпадающих под заданные критерии.
Критериев может быть указано довольно много (от единиц до десятков), нужно поддерживать их сочетания для AND и OR, а также крайне желательно и NOT IN.
И трудность заключается в том, что это должно работать быстро. Для рядовых запросов - моментально, для тяжелых - в пределах 5-10 секунд (и то это уже долго).

Я пробовал моделировать это на Postgres, для 100 тыс. пользователей, для запросов по нескольким критериям работает конечно нормально. Но при увеличении количества критериев в запросе быстро умирает, даже при оптимизации по самые помидоры.
SQL Server заметно более шустрый, но все равно, большое количество критериев быстро обработать не получается.

Тут, видимо, нужен какой-то принципиально другой подход нежели реляционная база, но какой выбрать - хз. Вариантов вроде бы много, но пока не сделаешь тестовый стенд, не поймешь - будет-ли быстро работать выборка по сложному условию. Поэтому обращаюсь к коллективному разуму - может кто такое уже делал.

miksoftЯ бы предложил использовать EAV c нормализованными attribute-value. Тогда основная табличка сокращается всего до двух числовых полей.

Сейчас в таблице есть три поля:
attribute_id int
value int
user_id int

Как это будет выглядеть в случае нормализованных attribute-value? Просто я честно говоря немного не в курсе что значит нормализованные...

Yo.!можно еще попробовать indexed view или взрослый партитионинг по юзер ид.
имхо ничего лучше реляционной субд для такой задачи не найти

Да, насчет indexed view пожалуй неплохая мысль. А в PostgreSQL или в MySQL это можно реализовать? Если нет, то подскажите плиз какие-нить бесплатные решения, очень уж не хочется на Оракл или SQL Server завязываться, т.к. лицензии стоят весьма ощутимо.
Насчет партицирования - честно говоря не очень понятно как тут это может помочь. По идее, надо наоборот стремиться все в одну кучу, на одну машину собрать, сколько бы не было записей в базе. Иначе (вроде бы) затраты времени на агрегирование информации с разных машин будут очень уж ощутимы. Да и не очень понятно, по какому признаку партицировать... Ну или поясните плиз, как Вы это видите.

pkarklinGgg_oldПоддерживаю идею с гибридным подходом. Наверняка какие-то атрибуты являются наиболее используемыми/селективными в поиске - их в колонки. Остальные атрибуты в отдельную таблицу.

+1. Решение, оправдавшее себя многолетней практикой.

Спасибо, попробую поэкспериментировать с этим.

Dimitry SibiryakovКажется, именно с проблемой выборок по большому количеству критериев призваны бороться
GIS-расширения. Всякие там R-tree индексы и т.д... Почему бы не попробовать их?..


Как-то с ходу не очень понятно как их прикрутить-то с таким прицелом...

MasterZivА типовые запросы можно увидеть ?

Просто хотя бы "поддерживать их сочетания для AND и OR" уже будет достаточно
проблематично (в смысле OR) для ЛЮБОЙ БД, не только реляционной, реляционность
тут вообще ни при чём.

А NOT IN вообще очень тяжёлая операция.


Типовой запрос с AND и OR например такой:

женщина
И
город - С.Петербург
И
не замужем
И
цель знакомства - (брак ИЛИ романтические отношения ИЛИ дружба)
И
цвет волос - блондинка
EXCLUDE
курит

Насчет NOT IN - тут может быть несколько облегчает задачу то, что это условие можно накладывать в самом конце, на то, что уже выбрано предыдущими операторами. Т.е. в теле основного запроса этих ограничений встечаться не будет.

Alexander RyndinMasterZivОни вообще мало подо что подходят. Да и вообще они не индексы.
Аргументов не будет. Так же, как и флейма на тему "Занахрена кому
нужны битмап-индексы".Мдя-я-я. Не ел, но уверен, что гадость.
MasterZivOn 10.01.2011 7:13, Васисуалий Пупкинсон wrote:

> В общем, типовой use case - это выборка пользователей, подпадающих под заданные
> критерии.
> Критериев может быть указано довольно много (от единиц до десятков), нужно
> поддерживать их сочетания для AND и OR, а также крайне желательно и NOT IN.
> И трудность заключается в том, что это должно работать быстро. Для рядовых
> запросов - моментально, для тяжелых - в пределах 5-10 секунд (и то это уже долго).

А типовые запросы можно увидеть ?

Просто хотя бы "поддерживать их сочетания для AND и OR" уже будет достаточно
проблематично (в смысле OR) для ЛЮБОЙ БД, не только реляционной, реляционность
тут вообще ни при чём.

А NOT IN вообще очень тяжёлая операция.
BITMAP-индекс как раз отлично решает эту задачу с AND и OR.
Они также специально предназначен именно для случаев, когда количество различных значений невелико. Тут подойдет даже рост, который имеет диапазон от 100 до 210.
Как применять? Строим на часто используемые поля BITMAP-индексы и все.

Ох, попробую конечно, если больше никаких вариантов не будет. Просто очень уж не хочется с Ораклом связываться. При всем уважении, конечно. Если бы это корпоративный софт был, за который есть кому хорошо заплатить, тогда без вопросов, но тут ситуация несколько другая... Бюджет довольно-таки ограничен, увы.