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

Question

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

Answer 1

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

Answer 2

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