@konchober

В какой БД лучше хранить данные связей такого вида entity_id + [another_entity_id, ..., another_entity_id]?

Привет, сейчас использую таблицу для связи сущностей на MySQL MyIsam.
Структура наипростейшая: entity_id, another_entity_id
+ 2 индекса: entity_id + another_entity_id (уникальный) и another_entity_id + entity_id

К таблице используются запросы:
1) Выбрать все another_entity_id по entity_id = X
2) Выбрать все entity_id по another_entity_id = Y
3) COUNT по вышеприведённым выборкам
4) Возможно какие-то аналитические запросы по пересечению айдишников

На каждый entity_id может приходиться до 10млн another_entity_id.

В принципе запросы отрабатывают быстро, но при 300млн записях сами данные занимают 4гб + индексы (!!!) 11 гб.

Стоит задача сократить занимаемое место при сохранении или даже с увеличением производительности.

Первым пришло в голову использовать документно-ориентированные БД.
1) MongoDB отвалился сразу, т.к. имеет физическое ограничение на размер одного BSON документа в 16мб, что хватает только на документ вида: entity_id + [массив 1 млн another_entity_id]. Производительность и размер данных в результате такой подставы оценить не удалось.
2) PostgreSQL и тип jsonb может хранить документы любого размера, также имеет возможность поиска по документу, GIN индексы занимающие гораздо меньше места, но производительность поиска по jsonb отвратительно медленная. Видимо нужно ждать релиза индексов типа VODKA. А так же очень медленные инсёрты. Небольшая экономия жёсткого диска.
2.1) PostgreSQL и массив интов (integer[]) по производительности сопоставим с поиском по jsonb, но более быстрые инсёрты.

Пока что получается, что MyIsam уделывает всех по производительности. Что посоветуете, комрады?
  • Вопрос задан
  • 373 просмотра
Пригласить эксперта
Ответы на вопрос 1
@res2001
Developer, ex-admin
Возьмите PostGRE, а структуру оставьте такой же.
С индексами у вас что-то напутано - по сути 2 одинаковых индекса, думаете СУБД сама не догадается поменять местами поля при необходимости?
Я бы сделал уникальный кластерный индекс по entity_id + another_entity_id, и отдельные дополнительные индексы по каждому полю.
Попробуйте для начала на MySQL с индексами разобраться - место освободится. Может на этом и остановитесь.
Для увеличения производительности - переносите базу на SSD носитель.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы