MasterZivOn 10.01.2011 20:22, Васисуалий Пупкинсон wrote:

> Типовой запрос с AND и OR например такой:
>
> женщина
> И
> город - С.Петербург
> И
> не замужем
> И
> цель знакомства - (брак ИЛИ романтические отношения ИЛИ дружба)
> И
> цвет волос - блондинка
И
> NOT курит

Что-то не видно тут OR.


Да, и правда, то что я имел в виду под OR - это не что иное как IN для значений.
Тогда правильный пример будет таким:

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

В принципе, если с реализацией OR возникнут проблемы, то без него можно и обойтись, прибегнув к данной тактике - превратив атрибуты, которые могут употребляться через OR в значения, объединенные каким-нибудь общим атрибутом.

MasterZivПодозреваю, что ключевое умение СУБД тут -- возможность при запросе использовать
несколько индексов по одной таблице, делая merge join таблицы самой с собой
(каждая отобрана по условию с использованием индекса).

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


Со способом, использующим соединение таблиц, есть проблема, если в условии поиска заданы не очень селективные атрибуты. Например, условия поиска такие:

Страна: Россия или Украина (допустим, есть 300 тыс. записей с таким атрибутом).
Пол: мужской (есть 170 тыс. записей)
Семейное положение: холост (есть 100 тыс. записей)
Цель знакомства: брак (есть 80 тыс. записей)
Цвет волос: брюнет (70 тыс. записей)
Возраст: от 25 до 45 (50 тыс. записей)

Таким образом, в лучшем случае (если планировщик выберет правильный порядок соединения) будет сделано как минимум 5 соединений по 50 тыс. записей. И хорошо еще если только 5 и только по 50 тысяч - что, в принципе, отрабатывает за приемлемое время при разогретом кеше. Но если кеш холодный, то время отклика уже не лезет ни в какие ворота (более 10 секунд). А если будет не очень селективный запрос с бОльшим числом параметров, то у пользователя определенно все зависнет.

Естественно, на выходе нужно получить всего лишь десяток записей. Но этот десяток должен быть выбран из списка, отсортированного по времени регистрации пользователей. И никуда не деться от того, чтобы не проделать прежде все эти соединения.
Вот если бы СУБД умела соединять таблицы не последовательно (сначала полностью первую пару, потом к тому что получилось, полностью третью таблицу, и т.д.), а выбирать совпадающие записи из этих таблиц (отсортированных, конечно) по одной, пока не наберется количество, указанное в опции LIMIT (или TOP). Я даже пытался сделать сам такой велосипед посредством скрипта в Postgres. Но ничего путного из этого не вышло.

pilot911а что мешает разбить аттрибуты на группы и хранить их в разных таблицах, связываемых с основной?
тогда сможете хранить аттрибуты с множественными значеними и производительность будет на высоте

Да, это я пробовал делать. Для каждого вида атрибута - отдельная таблица. Действительно, хорошая оптимизация. Но к сожалению, это не устраняет основного камня преткновения - ситуаций, когда нужно сделать много (5 - 10, а то и больше) связываний таблиц, где каждое связывание - по нескольку десятков тысяч записей. Естественно, такие ситуации будут встречаться не на каждом шагу. И может быть даже придется с этим смириться. Но хотелось бы прежде испробовать все возможности найти решение, которое позволило бы с приемлемой скоростью обрабатывать даже такие вот неудобные запросы.

servit Bitmap -индексы в СУБД Caché.


Почитал, хорошее дело. Вот правда, непонятно, сколько стоит лицензия. На сайте указано только
авторI love Caché! How can I purchase a license?
We offer a variety of license types – one of them is sure to be right for you. Please call us toll-free at +1.800.753.2571, or contact your local InterSystems office to discuss your needs.

Как-то мутно это... Вообще, когда вижу такой подход к делу (типа цену озвучивают только при личном общении), как-то сразу интерес снижается. Навевает что-то вроде
"Скажите, сколько стоит ваша пищевая добавка? - Это зависит от множества факторов! Для начала скажите, пожалуйста, какой марки Ваш автомобиль?".

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

pilot911Васисуалий Пупкинсон,

надеюсь, в проведенных тестах ваш запрос выглядел INNER JOIN a ON a.id=b.id AND a.have_boroda=1 AND a.have_girl=1
если так - то запрос должен выполняться очень быстро даже на миллионах записей

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

pilot911я недавно оставил работу с каше, точнее с ее частью, так вот, бит индекс - не панацея в вашем варианте, поскольку позволяет искать точное совпадение, с диапазоном дат как вы битиндекс будете использовать?
и каше плохо работает на миллионах записей, я вам не советую, хотя ради интереса можете потестировать

Насчет диапазонов - на их сайте написано вот это:

авторThe SQL Engine can use bitmap indices for the following operations:
* ANDing of multiple conditions on a given table.
* ORing of multiple conditions on a given table.
* RANGE conditions on a given table.
* COUNT operations on a given table.

вроде бы, пункт про RANGE - как раз на эту тему. Но я, как говорится, за что купил, за то продал, судить не берусь.

Насчет "плохо работает на миллионах записей" - тоже конечно судить не берусь, т.к. не юзал, но вообще просто интересно - как же тогда они на этом строят учетные системы государственного масштаба?

pilot911Васисуалий Пупкинсон,

системы госмасштаба на каше мне неизвестны, может вам известны? поделитесь

Да, пожалуй, с госмаштабом я возможно погорячился :). Просто когда их сайт просматривал, то создалось впечатление, что национальная система здравоохранения это дело использует. Но при ближайшем рассмотрении - просто отдельные госпитали.