[Moscow.pm] Размышления на тему ORM и вообще работы с БД

[Ivan Petrov]

>> А можно данные каких-нибудь тестов привести в доказательство этого
> тезиса? А то

> будут, если проект попадет на CPAN.

> Меня интересуют тесты производительности, а не юнит-тесты. Они могут (и должны)
> проводиться до выкладывания в production, даже до CPAN.

тут сравнивать то собственно не с чем.

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

сранивать с DBIC? DBIC делает:
1. генерацию запросов
2. генерацию запросов некачественных (с точки зрения
производительности SQL)
3. POST-обработку выборки и сплит ее в объекты (мы отказываемся
от этого сразу, ибо поскольку исключаем кривые запросы, то и
POST-обработка не нужна: то есть в нашем случае получается код в
предельном случае, состоящий из одной инструкции bless).

то есть узкое место в случае с DBIC будет база данных, которая его
кривые запросы будет мучиться исполнять.

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

ну вот есть такой тестик.

    SELECT
        u.*
    FROM
        users AS u

    ?if{filters.role_name} {
        LEFT JOIN roles AS r ON u.rid = r.id
    }

    ?if{filters.user_name} {
        LEFT JOIN user_cards AS uc ON u.id = uc.uid
    }

    WHERE
        1 = 1

    ?if{filters.role_name} {
        AND r.name = ?{ filters.role_name }
    }

    ?if{filters.user_name} {
        AND uc.name = ?{ filters.user_name }
    }


на 1 = 1 пока не смотрим :), сейчас работаем над тем чтобы добавить
оператор для таких случаев. Соответственно тут вариантов обработки
данного запроса три:

1. Все фильтры включены (будет два JOIN'а)
2. Включен один из двух фильтров
3. Все фильтры выключены

времена предобработки такого запроса (после этого управление уйдет в
DBI) такие:

=cut

Two active filters
 1 wallclock secs ( 1.21 usr +  0.00 sys =  1.21 CPU) @ 8264.46/s (n=10000)
One active filter
 1 wallclock secs ( 1.03 usr +  0.00 sys =  1.03 CPU) @ 9708.74/s (n=10000)
No active filters
 1 wallclock secs ( 0.82 usr +  0.00 sys =  0.82 CPU) @ 12195.12/s (n=10000)

=cut


машинка, на которой это делается - P4/1600.

Отсюда видно, что узкое место тут явно будет БД (которая 8000
запросов на данном железе не сделает никогда), а не предобработчик
SQL.

PS: рисование более сложных запросов конечно приведет к большим
временам на предобработку, но очевидно, что более сложные запросы и БД
будет выполнять более долго. это первое.

второе: как ни крути, в рассматриваемом случае SQL-запросов будет три
для трех случаев: введен один фильтр, введено оба, не введен ни один.

и предобработка в этом случае требуется всегда. бесплатной она не
будет ни в каком варианте