Хранимые процедуры. Кто быстрее

[@Maxkn]

Чую скоро, для оценки производительности хранимок, начнут на них 3D сцены обсчитывать. и писать чтото типа — мускуль сосет, ни транзакций ни поддержки CUDA :)

[@Damaskus]

Ну тут как в театре: если на стене висит ружье — кто-нибудь из него выстрелит.

[@Maxkn]

лучше так: если в лаборатории есть микроскоп…

[@szKarlen]

… значит кто-нибудь будет забивать им гвозди.

[@alecksey]

вы забыли postgresql)

[@UUSER]

и Caché

[@rpeMJIuH]

И DB2, Oracle…
Опять же, автора, видимо, не озадачил выбор языка, на котором писать хранимую процедуру, или возможность вынесения вычислений в скомпилированый модуль…

Помимо прочего, меня немножко смутил синтаксис… Мокрое с мягким сравниваем… PSQL(если не ошибся, копируя из поиска) против PureSql

[@rpeMJIuH]

Можете не рассказывать даже… Сейчас на мейнфрейме DB2 ворочается с огромной системой, имею наглость наблюдать и даже немного дописывать…
Впрочем, сильного увеличения гемороя я не заметил. Что в лоб, что по лбу, чуть больше писанины — да это от языка зависит, компиляция и dbrm-ы — секундное дело… Прописка туннеля база-программа привычным create procedure. Всё — можно вызывать.

[@ncix]

В Firebird тоже есть UDF, это обычные DLL, импортируемые сервером и вызываемые из SQL.

[@alexius2]

Проверил под PostgreSQL 9.0.4 на ноутбуке (core 2 duo 2.4GHz), результат — 16±0.3 секунд. код:

CREATE OR REPLACE FUNCTION ARCTG2(X double precision) RETURNS double precision AS $$
DECLARE U double precision DEFAULT X;
DECLARE S double precision DEFAULT X;
DECLARE I INT DEFAULT 3;
BEGIN
WHILE abs(U) >= 0.0000001 LOOP
U := -U*X*X*(I-2)/I;
S := S + U;
I := I + 2;
END LOOP;
RETURN S;
END
$$ LANGUAGE plpgsql;

[@INCWADRA]

Oracle пока круче всех)

[@Damaskus]

У автора так и написано.

[@compdemon]

[минутка КО на Хабре]
СУБД — система управления базами данных.
Главная ее задача — обеспечивать целостность данных и скорость доступа к ней. Ну, плюс безопасность, масштабируемость и т.д. — то есть все то, что относится к хранению данных. Плюс некоторое обеспечение корректности за счет внутренних проверок и условий (сравнение полей и віборок с минимальными вычислениями).
Бизнес-логику надо выносить наружу.
По большому счету самым оптимальным является трехзвенная система — СУБД + app server + клиент. Клиент — отображение и взаимодействие, сервер приложений отвечает за бизнес-логику, СУБД хранение и доступ к данным. Относительная независимость каждого компонента обеспечивает стабильность.
Писать High Perfomance Computing на интерпретируемых языках и хранимых процедурах — это жесть. :)

[@Swordsman]

Уважаемый, High Perfomance Computing на интерпретируемых языках и хранимых процедурах никто и не собирался писать, сравнивалась скорость обсчета математической формулы и не более…

[@Stepanow]

а выносить логику за пределы СУБД

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

[@mr_avi]

Только может настать момент когда сервер БД будет задыхаться, а его масштабировать сложнее чем «app server»

[@Swordsman]

Абсолютно согласен.

[@INCWADRA]

Запустил для интереса на работе на oracle 7.36 сек
машина у меня хлам
Celeron 2.67

896 ОЗУ

[@Archangel]

Я тоже ради интереса запустил на MsSQL, правда это один из продакшн серверов, на нем активно крутятся полтора десятка баз (негодяй я, я знаю). Так вот пришлось увеличить точность на порядок, чтобы хоть сколь-нибудь нормальный результат получить. Получилось аж 27 секунд. Кстати значение счетчика получилось около 4*10^7 (а не 1*10^7, как у автора) для 7-ого порядка и 3,9*10*8 — для 8-ого.

[@Archangel]

А нет, это я идиот. Забыл убрать умножение на 4, когда итерации выводил.

[@INCWADRA]

Я тоже запускал на продакшене, там тоже чего только не крутится
Вообще в Oracle лучше большие математические операции писать на java или С и дергать их из пакетов

[@szKarlen]

есть мнение, что для таких вот задач и встроили собственные CLR внутрь SQL Server и JVM в Oracle.

[@Damaskus]

Интересно, а каким образом количество процессоров может влиять?
Линия вычисления одна, разветвиться и распараллелиться негде.
Как можно использовать несколько ядер?

[@Nike01]

Спасибо, повеселили :)
Анонимный блок для Оракл (проверял, выполняется приблизительно одинаково с хранимой процедурой):

declare
  U number:=1;
  S number:=1;
  I pls_integer:=3;
begin
  WHILE (abs(U) >= 0.0000001) loop
    U:= -U*1*1*(I-2)/I;
    S:= S + U;
    I:= I + 2;
  END loop;
  dbms_output.put_line(4*S);
end;

Время выполнения около 4.5 сек.
Конечно, нужно на одинаковых машинах скорость замерять.

[@INCWADRA]

у меня 7.36, правда i я делал просто integer
pls_integer — вроде должен ускорять
ваш код все равно у меня дал 7.37

[@Nike01]

Ну, скажем откровенно, роль приходящаяся на pls_integer в данном случае столь мала, что оно не повлияет сколь-нибудь существенно :)
Таким образом мы с вами вывели разницу в производительности Оракла в зависимости от машины (я запускал на сервере Intel Xeon 2 ядра по 3Ghz, 4 Gb RAM), который в тот момент был ничем не загружен.

У меня когда-то на ноутбуке Оракл стоял для домашних целей (AMD Turion 2 Ghz и 512 RAM), так ничего, работал, правда грузился долго. Но вот когда вместе с ним запустить NetBeans, например, то все жутко тормозило из-за нехватки памяти.

Пока писал, вспомнил, что у меня есть старая машина Athlon 1,41 Ghz, 256 RAM. Запустил запрос на ней, время выполнения 14 сек.

[@INCWADRA]

Моя машина
Celeron 2.67
896 ОЗУ
Сама база продакшн, хотя хз делали в тот момент на ней что нибудь существенное
Но как видно Oracle быстрее чем остальные базы, судя поэтому тесту