Возможно ли оптимизировать структуру таблицы Mysql через сортировку?

Question

[drdios]

Всем привет.
Мне необходимо хранить большое количество информации о связях между объектами. Например объект1 -> объект65
От одного объекта может быть сколько угодно связей с другими объектами (иначе говоря у нас направленный граф).
Я хочу хранить это в таблице с ключами obj1 / obj2
Получается нечто вроде

объект1 -> объект65
объект1 -> объект100
объект2 -> объект65
объект1 -> объект2
объект5 -> объект13
....

Искать буду по первой колонке не уникальных, повторяющихся значений.
ИТАК: Имеется ли в СУБД (mysql или PostgreSQL) инструменты более продвинутые, чем простое задание ключа и есть ли какая-либо команда ПРЕДВАРИТЕЛЬНОЙ сортировки значений в таблице по первой колонке для более быстрого поиска по ней в процессе работы??

PS: Возможно Вы предложите другие способы хранения графов и RDF триплетов в СУБД. Пока связь между объектами только по типу "смотри также" и "включает в себя", но в будущем возможно расширение до полноценных RDF.

Comments

[Алексей Хворостов]

Прошу прощения, а чем foreign key's не подходят?

[drdios]

Алексей Хворостов, внешние ключи на строки в той же таблице от куда они и делаются ("на себя")?

Answer 1

[Melkij]

mysql/innodb всегда кластеризована по первичному ключу. Т.е. данные физически упорядочены в порядке задаваемом первичным ключом. Собственно данные и лежат в листьях первичного ключа.

postgresql умеет команду cluster которая одноразово переписывает таблицу в порядке указанного индекса (плюс внимание на блокировку таблицы на всё время перестроения). В дальнейшей работе пишущих запросов кластеризацию данных не поддерживает.

Имеет ли кластеризация смысл для вашей задачи - не уверен. Надо смотреть диски и объём горячих данных по отношению к буферной памяти.

А для графов вероятно лучше взять графовую, а не реляционную СУБД.

Comments

[drdios]

Спасибо за подсказки!
CLUSTER - это то, что нужно. С учетом того, что таблица у меня нечасто изменяемая.
ссылки по теме :
https://postgrespro.ru/docs/postgrespro/9.5/sql-cluster

Answer 2

[Rsa97]

Для быстрого поиска в реляционной БД предназначены индексы. Саму таблицу сортировать смысла нет, не будете же вы полностью переписывать её при добавлении новых значений. Сделайте составной уникальный индекс (obj1, obj2) и при поиске по obj1 он будет использован для ускорения.

Answer 3

[eRKa]

Rsa97 все правильно сказал. Бд может физически хранить данные вовсе не в том порядке как их отображает в таблице по дефолту и сортировка Вам ничего не даст. Для ускорения поиска данных существуют индексы. Делаете из своей связи составной ключ и индексируете все это дело.