Стоит ли добавлять index для полей таблицы EAV?

Question

[Jedi]

У меня в данный момент простой e-commerce проект. Реализованы EAV таблицы для характеристики товаров. Всё довольно просто:

product_attribute_values
- product_id (index)
- value
- product_attribue_data_id (index)

product_attribute_data
- slug (memory)
- display_name (объём памяти)

Нужно ли добавлять индексы тем полям, которые будут использованы для фильтрации?
Это может быть поле value в product_attribute_values, также поле slug в product_attribute_data, а возможно в некоторых местах и поле display_name.

Каждый из вышеупомянутых полей имеет тип varchar (255).

Товаров будет около 10,000. Спецификаций к ним в среднем по 20 записей. Это получается что по идее, записей будет меньше одного миллиона.

Дополнительный вопрос касательно индексов: Нужно ли добавлять индексы в полиморфную таблицу?

Comments

[Akina]

Вместо малопонятного описания выложите полные CREATE TABLE обеих таблиц. Добавьте пример данных (скажем, 2 товара, по 3 свойства на товар) и запрос на фильтрацию (скажем, который должен отобрать только один товар из двух).

Товаров будет около 10,000. Спецификаций к ним в среднем по 20 записей. Это получается что по идее, записей будет меньше одного миллиона.

Ни о чём... обе таблицы и все их индексы стопудово будут закэшены в памяти. Так что лишний индекс от производительности особо и не откусит.

Можно вообще закэшить статические таблицы, создав копию с ENGINE = Memory, только там создавать индексы, и поплёвывать на производительность дисковой подсистемы. А изменения класть обратно триггерами.

-----------------------------

Дополнительный вопрос касательно индексов: Нужно ли добавлять индексы в полиморфную таблицу?

Индексы добавляют для обслуживания конкретных запросов. Ну не считая контроля на уникальность, конечно, но это сейчас не при чём.

Индекс используется не вообще, а в момент выполнения конкретного запроса. В этот момент данные таблиц известны, фиксированы и (если не считать dirty и phantom reads) неизменны - то есть таблица динамически полиморфна исключительно в динамике, но не в статике, не в момент выполнения запроса. А потому эффективность индекса никак не зависит от того, каноническая связь или полиморфная. И, как следствие, необходимость создания индекса тоже не зависит от типа связи.

[Jedi]

Akina, Спасибо за информацию!

[Vitsliputsli]

Akina,

Можно вообще закэшить статические таблицы, создав копию с ENGINE = Memory, только там создавать индексы, и поплёвывать на производительность дисковой подсистемы. А изменения класть обратно триггерами.

А что это даст? Кроме того, что экономим место на диске для индексов, но имеем тяжелый "холодный" запуск во время которого будут создаваться эти индексы в таблице в памяти.
При этом просто любая таблица с индексами и так будет в памяти во время работы и читать ее с диска нет нужды. Конечно, при условии что достаточный buffer pool.
Смысл наверное только для тяжелых таблиц, которые читаем раз в год, и в добавок buffer pool ограничен, так что вытеснение ее из памяти при обычном хранении вполне реально. Но, это чтото очень экзотичное.

[Akina]

Vitsliputsli,

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

В памяти как раз можно создать структуру со всеми индексами, а потом грузить в неё данные. Запись достаточно компактна, количество невеликое - вот не могу посчитать такой холодный старт тяжёлым, ну никак.

Зато в этом случае чхать на размер buffer pool - таблица всегда в памяти и почти что сама себе кэш.

[Vitsliputsli]

Akina, допустим, но какой смысл этой таблицы в памяти? Любая таблица всегда помещается в память, зачем эти манипуляции?

Answer 1

[rPman]

Если нужны сложные индексы, то в EAV модели появляется дополнительная таблица объектов с выделенными полями под нужные атрибуты, наполняемая тригерами, и уже на них настраиваются индексы.

Скажи, зачем ты выбрал EAV модель? Зачем создал себе проблем?

В чем проблема каждому атрибуту создать колонку в таблице, сотни колонок никаких особых проблем (главная рекомендация - не делать default value, если в будущем понадобится удалять добавлять колонки), структура отлично кодом модифицируется и анализируется средствами базы данных, и главное гибко организуются многоуровневые индексы, что сложно реализовать на EAV

Comments

[Jedi]

Изначально EAV мне показался лучше. Со своей задачей архитектура справляется, но вот когда дело доходит до ускорения работы, я уже не знаю. Нет опыта работы с индексами в связке с EAV. Был ли у вас аналогичный опыт? Какие проблемы могут быть, если я установлю индексы на выше написанные поля?

В будущем, если конечно результат не оправдается, буду внедрять meilisearch.

[rPman]

это главная проблема EAV - очень низкая производительность и очень сложная оптимизация, вырождающаяся в правильное решение - одна запись в таблице = один объект с кучей полей

[Jedi]

rPman, Что думаете о meilisearch? Решает ли это проблему EAV?

[Jedi]

rPman, И хотел бы получить ответ на вопрос, стоит ли вешать иднексы на поля указанные в вопросе. Впервые использую EAV, нет опыта с этим…

[rPman]

любое поле таблицы с большим количеством данных (наверное больше десятков записей), которое будет использоваться в where, order by и group by (а так же в агрегирующих функциях) - нужно добавлять в индекс

если несколько полей используется одновременно в order by и where то рекомендуется создавать составной индекс (но EAV часто этому препятствует), иначе в таких запросах обычные не будут использоваться

p.s. про meilisearch понятия не имею что это такое, гуглить умею... я считаю, что лучше сначала решать задачу имеющимися инструментами, прежде чем из-за незнания примитивов бежать и покупать готовое решение, надеясь что оно все проблемы решит, а не создаст новые

[Jedi]

rPman, спасибо Вам большое!

Answer 2

[mayton2019]

Стоит ли добавлять index для полей таблицы EAV?

Добавляй конешно. Если ты уже докатился до такого состояния что затащил EAV.
Но это - вопрос не к Qna а к тебе. Ни один архитектор не умеет прогнозировать время
исполнения запроса. Это - слишком шумящая и слишном сложная формула. А знать ее можешь
только ты сам после нагрузочного тестирования. Загрузи фейковые данные. Смоделируй без индекса
и с индексом.

Ну... по возможности подумай о том чтоб как-то уйти от EAV и заменить характеристики
товара JSON-документом. Это - эволюционный путь и все к этому приходят.

Comments

[rPman]

осторожно с json, объединять так данные лучше те что по типу работы с данными сгруппированы и так или иначе используются скопом

[Jedi]

Спасибо! Но разве таблицы в сумме с миллионом записей, разве это тяжело запрашиваемые данные?

[mayton2019]

rPman, ну да. Это только практика покажет. Собственно эволюция MongoDb, CouchDb, e.t.c идет от практики применения документов со слабой спецификацией полей. Если там будут какие-то реляционные операции над атрибутами - то она будет работать не очень быстро. Но если надо просто найти товар и показать его - то вполне себе пойдет.

Здесь нет идеального решения. Здесь - матрица компромиссов. Где-то чуть-чуть мы проиграли. Где-то выиграли.
Но и EAV - это не серебрянная пуля. Это просто теоретизированная концепция.

[Vitsliputsli]

mayton2019, именно так, просто фраза выше реально звучит как "серебряная пуля". Действительно, надо исходить из того, как данные будут использоваться. Если плевать на производительность, нет проблем - json. Если не работаем с большими таблицами - тоже да. Причем данных может быть много, но, например, мы так удачно расшардировались, что даже при фильтрации по внутренностям json нам надо пробежать только 1 маленький шард. А если таблица большая и нам важны милисекунды, то выносить из json в отдельные поля и индексировать.

Answer 3

[Jedi]

rPman mayton2019 Спасибо Вам больше за подсказку, за ответы. Прочитал также статьи у англоязычных разработчиков, убедился в том, что от EAV откажусь, но это уже в будущих проектах. Дайте совет, что на сегодняшний день является лучшим решением для хранения Attribute и Attribute Value значений, записей?

Также отвечу почему я не выбрал JSON тип данных. Это из-за сложности фильтраций. Советуясь с коллегами, я убедился, что EAV это хорошее решение. Возможно так оно и есть, так как у меня не 5,000,000 плюс записей.

Если имели опыт работы с сервисами типа Algolia, ElascticSearch и MeiliSearch, что думаете об этих сервисах? Поделитесь профессиональным опытом, мне будет очень интересно прочитать ваше мнение и ваш опыт.

Спасибо!

Comments

[rPman]

на сегодняшний день является лучшим решением для хранения Attribute и Attribute Value значений

колонки в таблицах

это лучшее решение, реляционные базы данных для этого и создавались