Производительность больших систем EAV / открытой схемы на SQL Server

Question

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

Answer 1

Независимо от 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-фреймворке, - это некоторый шаблонный код, который извлекает многострочный набор результатов, подобный этому, и отображает атрибуты в свойствах объекта, а затем возвращает коллекцию заполненных объектов.

Answer 2

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