EAV vs Row Modeling. Тест производительности на PostgreSQL

Первая модель - EAV (Entity-attribute-value) - представляет из себя некую "универсальную" структуру описания данных, в которой данные хранятся фактически в одном линейном списке. Для примера опишу как выглядит структура записи информации о пользователе в данной модели (приведенный пример является крайне грубой реализацией данной модели):

Таким образом мы имеем фактически длинючую табличку для практически всех данных. Достоинство такого подхода - очень существенная гибкость решения и почти полная универсальность. Недостатки - сложность соблюдения целостности данных и производительность (что собственно я и хочу протестировать). Более детально про данный тип модели можно почитать в Википедии.

Вторая модель - Row Modeling - представляет собой более классический подход к проектированию, когда на каждую сущность нашей системы создается отдельная таблица в БД. В этой таблице поля представляют собой имена атрибутов сущности, а сами строки - собственно их значениями:

Итак, приступим к тестированию. Для теста использовалась СУБД PostgreSQL версии 8.2.5. Были созданы следующие таблицы:

CREATE TABLE "test"."eav_test" (
  "entity_id" INTEGER,
  "object_id" INTEGER,
  "attr_name" TEXT,
  "attr_value" TEXT
) WITH OIDS;

CREATE INDEX "eav_test_idx" ON "test"."eav_test"
  USING hash ("object_id");

CREATE INDEX "eav_test_idx1" ON "test"."eav_test"
  USING hash ("attr_name");

CREATE TABLE "test"."rm_test" (
  "id" INTEGER, 
  "attr_1" INTEGER, 
  "attr_2" DOUBLE PRECISION, 
  "attr_3" VARCHAR(30), 
  "attr_4" TEXT
) WITH OIDS;

CREATE INDEX "rm_test_idx" ON "test"."rm_test"
  USING hash ("id");

Далее создана специальная функция по заполнению данный таблиц 10000 объектов с рандомными значениями атрибутов:

CREATE OR REPLACE FUNCTION "test"."fill_test_data" () RETURNS boolean AS
$body$
DECLARE
  v_i INTEGER;
  v_attr_1 INTEGER;
  v_attr_2 NUMERIC;
  v_attr_3 VARCHAR;
  v_attr_4 TEXT;
BEGIN
  FOR v_i IN 1..10000 LOOP
    v_attr_1 := round(random()*100);
    v_attr_2 := random()*100;
    v_attr_4 := md5(v_attr_1::text || v_attr_2::text)::text;
    v_attr_3 := v_attr_4;
    
    INSERT INTO test.eav_test (entity_id, object_id, attr_name, attr_value)
    VALUES (1, v_i, 'attr_1', v_attr_1),
           (1, v_i, 'attr_2', v_attr_2),
           (1, v_i, 'attr_3', v_attr_3),
           (1, v_i, 'attr_4', v_attr_4);
    INSERT INTO test.rm_test (id, attr_1, attr_2, attr_3, attr_4)
    VALUES (v_i, v_attr_1, v_attr_2, v_attr_3, v_attr_4);
  END LOOP;  
  RETURN true;
END;
$body$
LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;

Для тестирования работы заполненных структур я выбрал несколько типовых запросов:

1. Получение всех атрибутов конкретного объекта
2. Получение одного атрибута конкретного объекта
3. Получение списка объектов, у которых некоторый атрибут имеет определенное значение
4. Получение результата агрегирующей функции (SUM) на некотором атрибуте при заданных условиях

Результаты тестирования я свел в таблицу:

Результат, как говорится, на лицо. При более сложных запросах можно прогнозировать еще большее отставание EAV модели от RM.

PostScriptum

Выгода от применения модели EAV конечно немалая, в основном, конечно, в гибкости. Но по скорости она однозначно проигрывает традиционной RM. Данные тесты, безусловно, являются синтетическими, и на истину в последней инстанции не претендуют. К сожалению, рабочей системы с применением EAV модели у меня под рукой не оказалось, так что протестировать реальную систему, построенную на EAV пока не получается.