Какие СУБД подходят для выборок записей, которые зависят друг от друга?
Если, для примера брать реляционную базу, то в таблице необходимо находить записи которые зависят друг от друга определенным образом. Комбинации из нескольких записей могут зависеть от других комбинаций из нескольких записей.
Записей может быть миллионы.
В реляционной СУБД это можно реализовать, используя определенное кол-во join. Но так как записей может быть миллионы, то после первого join, СУБД будет иметь дело уже с триллионом записей и т.д. И запрос в этом случае может обрабатываться неограниченно долго (уже проверено).
Возможно есть субд, предназначенные как раз для таких задач? Пока смотрю на графовые СУБД (neo4j), но еще не разобрался, подойдет она или нет.
Посоветуйте, в каком направлении хотя бы двигаться.
Мне кажется, Вам нужно посмотреть этот список. Так как БД такого типа не очень популярные, думаю, Вам лучше спросить это на каком-то очень узкоспециализированном форуме или как минимум точнее описать суть проблемы. JOIN на миллиард записей и неограниченно долгое его выполнение - возможно, это проблема не реляционных БД, изначально, а подхода к их использованию... Никто обычно не получает данные в количестве "миллиард записей" за 1 заход.
Добавлю, если JOIN проводить сразу по нужным условиям, то может оказаться, что после первого же JOIN'а у вас стало не триллион, а всего тысяча записей.
PrAw, как раз изначально мне нужно получить декартово произведение, а потом уже анализировать полученные данные. Начальный запрос следующий select * from a join a as a2 ON a.id < a2.id.
В задаче необходимо сначала получить разницу между значением записей. Т.е. для каждой записи получить разницу со всеми остальными записями. И в дальнейшем эти разницы анализировать.
Начальных записей, которые анализируются, может быть миллион, а после первого join их будет чуть меньше триллиона.
koliane, На этот случай могут помочь либо хранимые процедуры либо вложенные подзапросы, всё зависит от реальной задачи.
Ну и в случае миллиардов записей в результате переходим на подходы Big Data. Как вариант можно реляционную БД использовать как тупую хранилку ключ-значение, а всю магию делать на клиенте.
сильно условный псевдокод на несуществующем языке программирования:
for var_id in (select * from a):
results = (select * from a where id < $var_id)
for r in results: ....
PrAw, в этом случае нужно будет либо брать всю выборку в память, что невозможно, либо делать несколько более мелких запросов в цикле и уже по отдельности анализировать, но более мелкие выборки также нужно будет анализировать друг с другом, а значит хранить где-то в памяти. Извернуться конечно можно, но скрипт будет отрабатывать слишком долго, поэтому и хочу решить задачу, используя СУБД.
koliane, проблема в том, что СУБД тоже надо где-то хранить промежуточные данные.
Скорей всего Вы решаете какую-то задачу оптимизации, а это не всегда требует полного перебора.
И с использованием некоторых оптимизаций можно как минимум сократить объемы памяти.
>>И запрос в этом случае может обрабатываться неограниченно долго (уже проверено).
Криво логика значит построена. Если зависимости уж слишком сложные - тогда писать логику самому на NoSQL базе. Они по ключу тебе быстро будут выбирать нужные данные.
Комбинации из нескольких записей могут зависеть от других комбинаций из нескольких записей.
.
В реляционных СУБД необходимо в первую очередь построить схему данных - для разных наборов данных, описывающих разные сущности, построить разные таблици, описать связи между ними.
Почитайте про нормализацию данных, достаточно про первые 3 нормальные формы.
приведите пример вашего запроса, который обрабатывается неограниченно долго, и опишите немного предметную область из которой обрабатываете данные.
хорошо сформулированная задача содержит в себе половину решения
Вы собираетесь решать задачи на графах?!
Тогда вам просто надо выбрать одно из нескольких представлений графов
(Хранить можно и РСУБД)
Но все равно в пределе у вас может оказаться NP-полная задача.
Тыды ой, ничто не поможет. :-)
Простой
Простой
