Блог

Кто-нибудь реализовал очень большую базу данных EAV или открытую базу данных в стиле схемы в SQL Server? Мне интересно, есть ли в этом проблемы с производительностью и как вы смогли преодолеть эти препятствия.

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

 SELECT e.id, a1.attr_value as "cost", a2.attr_value as "color",
  a3.attr_value as "size", . . .
FROM entity e
  LEFT OUTER JOIN attrib a1 ON (e.entity_id = a1.entity_id AND a1.attr_name = 'cost')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a2.entity_id AND a2.attr_name = 'color')
  LEFT OUTER JOIN attrib a2 ON (e.entity_id = a3.entity_id AND a3.attr_name = 'size')
  . . . additional joins for each attribute . . .
 

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

Решение состоит в том, чтобы извлекать атрибуты в строках вместо столбцов и писать класс в коде приложения, чтобы перебирать эти строки, присваивая значения свойствам объекта по одному.

 SELECT e.id, a.attr_name, a.attr_value
FROM entity e JOIN attrib a USING (entity_id)
ORDER BY e.id;
 

Этот SQL-запрос настолько проще и эффективнее, что он компенсирует дополнительный код приложения.

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

Я не эксперт по EAV, но несколько более опытных разработчиков, чем я, прокомментировали, что платформа электронной коммерции с открытым исходным кодом Magento работает медленно в основном из-за архитектуры EAV через MySQL. Самый очевидный недостаток нелегко преодолеть. В этом заключается сложность устранения неполадок, связанных с тем, где и как представлена информация для сущностей и значений атрибутов по мере увеличения размера приложения. Второй аргумент против EAV, который я слышал, заключается в том, что для этого требуются объединения таблиц, которые имеют низкие двузначные числа, но было отмечено, что использование InnoDB поверх MyISAM несколько улучшило производительность (или это может быть наоборот, но я не могу вспомнить полностью).