Java vs PL/SQL - исследование производительности

В принципе предсказуемо.

>Итог исследования таков - перенос логики связанной с обработкой данных из RDBMS на прикладной уровень дает значительный прирост скорости и это стоит учитывать.

Исследование отличное, выводы - ни к черту.

Что мешало написать ХП на Java и проверить скорость работы? Или это очередной из "тестов", рекламирующих вынос бизнес-логики на прикладной уровень?

А при чём тут прикладной уровень? Процедуры на Java прекрасно работают внутри базы данных Oracle и вызываются так же как и PL/SQL процедуры.

>на прикладной уровень дает значительный прирост скорости и это стоит учитывать.

тока орацле умеет коллить жабные классы из сторед процедур, на сколько я знаю

>тока орацле умеет коллить жабные классы из сторед процедур, на сколько я знаю

А в PostgreSQL есть PL/Python.

>А в PostgreSQL есть PL/Python.

А также - PL/Java

А если переписать с Java на C, то будет ещё быстрее, а если на ассемблере, то вообще на луну улетит.

>А при чём тут прикладной уровень? Процедуры на Java прекрасно работают внутри базы данных Oracle и вызываются так же как и PL/SQL процедуры.

Исходя из контекста. Если посмотреть всю статью+ответы на возражения то станет ясно что всё исполнялось вне БД.

В частности такие утверждения как:

>Focus on that, and put other kinds of large analytical and ETL processes outside the RDBMS.

>Since then, my position has been that nothing -- nothing -- goes in the RDBMS but data. All processing (by all, I mean "all", as in "all") belongs in proper programming language class definitions which are part of a proper application software architecture that is outside the RDBMS

и еще парочка, но этих достаточно :)

>А в PostgreSQL есть PL/Python.

Для Python использовался SQLAlchemy и всё тот же Oracle 10 XE

Хм, может ещё проблема в XE версии? А если бы использовалась полная версия?

Очередная рекламка явы.

>Очередная рекламка явы. Тогда и питона уж тоже. Google c Sun скинулись и проплатили, ага :)

>Что мешало написать ХП на Java и проверить скорость работы?

Расшифруй "ХП" плиз.

Ммм, там как раз антиреклама питона.

>Ммм, там как раз антиреклама питона.

Python показал в 2 раза лучший результат чем PL/SQL - более чем удачное выступление :) То что Python медленнее Java никто и не спорит.

> my position has been that nothing -- nothing -- goes in the RDBMS but data

Золотые слова! Всем писать себе на лбу и минимум три раза в день смотреть в зеркало.

О да, показали конкретно, что ассемблер рулит, а С активно догоняет. Ну и жабка - привычно сосёт и страшно тормозит.

ага, гиганты индустрии tpc гоняют на сторед процедурах и глупые не подозревают об открытии местечкового гения :) хоть бы Кайта почитал что-ли ...

PS. а где pl/sql код то ???

Minotauros.

>Расшифруй "ХП" плиз.

ХП - хранимая процедура.

Странный тест. Судя по коментам в нем каждый увидел то, что хотел ))

>ага, гиганты индустрии tpc гоняют на сторед процедурах и глупые не >подозревают об открытии местечкового гения :) хоть бы Кайта почитал >что-ли ...

Ну, судя по его резюме - http://homepage.mac.com/s_lott/steve/resume.html местечковым гением скорее можно назвать Вас, ув. анонимус.

А Кайт на то и сотрудник Оракла чтоб ПЛ/СКЛ продвигать ...

А вообще я заметил что оракл настолько сложная вещь, что постигшие его специальные люди-ораклоиды ничего более осилить не в состоянии, и потому обьявляют его панацеей от всего, и заколачивают pl/sql-ем любые видимые ими гвозди. В это время лучше держаться от них подалее, поскольку аргументация на уровне доводов к ним в большинстве случаев неприменима ...

А если и начальство их поддерживает, то лучше начать подыскивать другую работу.

>А Кайт на то и сотрудник Оракла чтоб...

Он по телевизору не выступает с речами "получи все от нового лицензионного Оракла". Он скорее не продвигает, а развивает. И ваши проблемы с базами данных не решатся простой сменой языка, нужно правильно спланировать базу, знать как работает Оракл, правильно составить алгоритм, а уже потом приступать к реализации на каком-либо языке.

>В это время лучше держаться от них подалее, поскольку аргументация на уровне доводов к ним в большинстве случаев неприменима ...

Хоть к ораклоидам не отношусь, но все равно спрошу : а что, если вместо советов на практике доказать, что ваше решение будет лучше?

>А Кайт на то и сотрудник Оракла чтоб ПЛ/СКЛ продвигать ...

ОК, Кайт по заказу оракла подтасовывает цифирьки в своих тестах (при этом в отличии от новоявленого гения, не забывает выкладывать весь код) с ним ясно, а MSDN то кто платит (если надо ткну в линк где МС рекомендует t-sql для тяжелых oltp)?

Minotauros.

ЗЫ. а "гений" даже не OCP

>И ваши проблемы с базами данных не решатся простой сменой языка, нужно правильно спланировать базу, знать как работает Оракл, правильно составить алгоритм, а уже потом приступать к реализации на каком-либо языке.

Так ведь с этим никто и не спорит, более того, автор сам это и утверждает в следующем посте - http://homepage.mac.com/s_lott/iblog/architecture/C465799452/E20070323112108/...

Проблема не в том что Oracle медленный, проблема в том что медленный pl/sql ...

>DB physical tuning helps both Java and PL/SQL. Since Java is already faster than PL/SQL, physical design is still important and still helps.

>Doing more work in SQL's DML helps both Java and PL/SQL, also. Knowing SQL, and making use of the DML features is still important and still helps.

>PL/SQL is slow, and I find it painful to manage, since it is relatively inflexible. I don't have classpath, working directories, environment variables, command-line parameters in my PL/SQL environment. I do have a kind of symbolic link as my only control mechanism for introducing flexibility.

>Since PL/SQL is slower and less flexible than Java, I'm forced to to conclude that PL/SQL isn't an effective way to implement anything.

и еще раз - ГДЕ PL/SQL КОД ? я не вижу, что в этом чудо тесте сравнивалось ?
понятно что бывают задачи где трафик между RDBMS и апликухой не сильно сказывается, но в задачках типа tpc-c/tpc-e/tpc-h у такого дизайна нет щансов.

Minotauros.

>ОК, Кайт по заказу оракла подтасовывает цифирьки в своих тестах (при этом в отличии от новоявленого гения, не забывает выкладывать весь код) с ним ясно, а MSDN то кто платит (если надо ткну в линк где МС рекомендует t-sql для тяжелых oltp)?

Код pl/sql кстати есть тут - http://homepage.mac.com/s_lott/iblog/architecture/C465799452/E20070323112108/...

Относительно Кайта - никто не говорит, что он что либо подтасовывает или нечестно себя ведет, наоборот я лично (как, думаю и автор), дядюшку Тома всемерно уважаю за его фундаментальные книжки и огромное кол-во моих трудодней, спасенных его ресурсом asktom :) Просто его точка зрения в том, где нужно размещать определенного рода бизнес-логику, как человека работающего в основном с БД, несколько расходится с моей точкой зрения как Java разработчика.

Относительно тяжелых oltp - про это ничего не скажу, отмечу только что автор ведет речь лишь об определенном типе запросов, для которых pl\sql неоптимален, а именно выборок со сложными where условиями -

>3. Closely-related families of queries with multiple WHERE-clause alternatives. These are dismayingly common because the data model hasn't kept up with actual use cases. We have to use complex conditions to work around some limitations of the data.

>These third class of queries are the interesting ones. These are the queries where you have to use CASE, DECODE and NVL constructs. These are the kinds of queries where you have a number of variants, and you have to resort to "Cursor Variables" in PL/SQL.

Я, честно говоря, в oltp не силен, но подозреваю что такие запросы к этой области не относятся ...

Всё ж таки PL/SQL не предназначен для программирования, это должно быть ясно в процессе его изучения мгновенно, он предназначен для составления хранимых процедур, которые выполняют какую-то простую логику. Страшно неудобный язык, довольно простые вещи там часто приходится сложно писать, поэтому результат теста не удивителен ни сколько. Но и фанатствовать особо нечего, если какие-то запросы можно эффективно обработать на стороне сервере, то это лучше сделать именно через хранимую процедуру, и использовать это можно не вместо, а вместе с логикой приложения. Т.е. что-то писать на жаве, что-то в хранимых процедурах.

Скажем, есть 2 варианта сделать некую функциональность -

1) Реализовать ее в БД с помощью триггеров, процедур и нативных подключаемых библиотек на C; разумеется, все это будет работать только на определенной версии оракла, определенной ОС, будет абсолютно нетестируемо и понятно одному лишь оракл-гуру, который это напишет.

2) Реализовать функциональность на уровне сервера приложений, с помощью POJO/JDBC и стандартных Java API, снабдить все это достаточным кол-вом юнит-тестов. Производительность примерно сравнимая с первым случаем, код понятен обычному, не являющемуся спецом в оракле, Java разработчику, коих на проекте абсолютное большинство.

Какой из 2х вариантов выберете Вы ?

ЗЫ Вышеупомянутый оракл-гуру - программер с большим стажем, работает в компании со дня основания, лучший друг директора и ПМа. Обьяснять, какой вариант был в конце концов выбран ?

сейчас лень разбиратся в коде - но сходу видно что гений не потянул даже oracle concepts и про pl/sql native compilation не слыхал. завтра посмотрим еще на код повнимательней ...

чтоб было понятно насколько натив может быть быстрей:

ALTER SESSION SET plsql_compiler_flags = 'INTERPRETED';

CREATE OR REPLACE PROCEDURE test_speed AS
v_number NUMBER;
BEGIN
FOR i IN 1 .. 1000000 LOOP
v_number := i / 1000;
END LOOP;
END;
/

SET TIMING ON
EXEC test_speed;

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.00

ALTER SESSION SET plsql_compiler_flags = 'NATIVE';
ALTER PROCEDURE test_speed COMPILE;

EXEC test_speed;

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.05

Minotauros.

>сейчас лень разбиратся в коде - но сходу видно что гений не потянул даже oracle concepts и про pl/sql native compilation не слыхал. завтра посмотрим еще на код повнимательней ...

О, это было бы интересно :) Можно будет даже автору в каментах задать вопросы, если будут какие-либо результаты

2anonymous_IV

пля, ну почитайте Кайта. спецально ж для таких он и написал effective by design.
вы ничерта не выйграете "с помощью POJO/JDBC и стандартных Java API," - на mssql ваш JDBC вам не поможет запустить апликуху, а вот за счет гоняния данных по JDBC можете сильно проиграть. единственный внятный вариант - юзать какой-то ORM типа hibernate, который в курсе различий разных субд, но перфоменс будет с ним ниже плинтуса ...

Minotauros.

Я прочитал подробности. Блин. 4000 записей -- при чём тут оракл? Такие объёмы идеально работают в текстовых файлах, блин. Тест хотя и интересный, но real world куда как больше размером, чтобы все документы помещались в памяти в хеш. Кстати, подобные конструкции я делал и в PL/SQL, и не исключено, что они там отвратительно работают, по сравнению с питоном или жавой, но это ничего не говорит о проблемах the real world. И вообще, интересно посмотреть на результаты жавы вызванной из хранимой процедуры. А так же, на приложение, которому надо не просто один near miss запрос, а лопатить большие объёмы данных, и как оно будет работать из хранимой процедуры и из жавы на стороне клиента.

>Проблема не в том что Oracle медленный, проблема в том что медленный pl/sql ...

Oracle медленный не спорю. Когда база на пару десятков Mb, то mysql работает куда лучше. Но когда размер базы превышает разумные пределы, а пользователи так и ломятся, чтобы получить оттуда данные, что-то добавить, что-то удалить, при этом стремительно растет журнал, то Oracle в сравнении оказывается куда более быстрым и работает стабильно.

Не зря ведь этот продукт с его далеко не малой стоимостью живет на рынке.

В книге Тома Кайта была фраза что-то вроде "тестируйте все в реальных условиях или максимально близких к ним."

>на mssql ваш JDBC вам не поможет запустить апликуху, а вот за счет гоняния данных по JDBC можете сильно проиграть

Не совсем понятно насчет mssql - вроде бы как речь пока шла только об Оракле, а обсуждаемый проект именно на Оракле и сьезжать с него не будет никогда.

>Oracle медленный не спорю. Когда база на пару десятков Mb, то mysql работает куда лучше. Но когда размер базы превышает разумные пределы, а пользователи так и ломятся, чтобы получить оттуда данные, что-то добавить, что-то удалить, при этом стремительно растет журнал, то Oracle в сравнении оказывается куда более быстрым и работает стабильно.

>Не зря ведь этот продукт с его далеко не малой стоимостью живет на рынке.

Я имел в виду, что Oracle именно как БД достаточно быстрый, но его реализация PL/SQL, по мнению автора, имет с быстродействием ряд проблем

>А так же, на приложение, которому надо не просто один near miss запрос, а лопатить большие объёмы данных, и как оно будет работать из хранимой процедуры и из жавы на стороне клиента.

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

Minotauros.

Кстати да, и ведь ничего не сказано про обьем памяти, который Java решение пожирает :) С другой стороны, если все же нужно очень быстро, Java аппсерверов с кучей памяти можно поставить десяток, а сервер БД обычно один, есть конечно RAC, но это уже совсем другая песня ...

>в такой задачке в реальном мире все будет решать трафик между апп сервером и субд.

Да, тут я пожалуй соглашусь :)

>Не совсем понятно насчет mssql - вроде бы как речь пока шла только об Оракле, а обсуждаемый проект именно на Оракле и сьезжать с него не будет никогда.

потому что те претензии типа "разумеется, все это будет работать только на определенной версии оракла, определенной ОС" я неосилил. я еще не встречал pl/sql который бы был непереносим :) если это поклеп в сторону PROC то я не сталкивался с задачами где не хватало обычного pl/sql но уверен что скомпилируется на любой платформе.

Minotauros.

> Я имел в виду, что Oracle именно как БД достаточно быстрый, но его реализация PL/SQL, по мнению автора, имет с быстродействием ряд проблем

Обычно самые критические участки -- совсем не в PL/SQL. Чаще приходится заниматься оптимизацией чистого SQL, а там своих заморочек хватает...

Это да ...

На самом деле, чем больше я об этом думаю, тем больше мне кажется что автор взял все же слишком частную проблему. Она, в некоторых случаях, лучше решается на Java, но, с другой стороны, такое решение имеет ряд недостатков, о которых товарищи уже высказались выше :) Все же сложно отрицать, что хранение части бизнес-логики на сервере зачастую очень полезно, и в этом контексте фразы автора вроде

>Years ago, at a Siebel conference, I heard a heretical comment. Specifically, they use the RDBMS as simple, flat storage: tables and indexes, nothing more. I was shocked and dismayed that they had just knocked the idea of stored procedures and triggers right on its ear.

и

>All processing (by all, I mean "all", as in "all") belongs in proper programming language class definitions which are part of a proper application software architecture that is outside the RDBMS

вызывают легкое недоумение (и желание не связываться с Siebel :) ) Догматизм никогда к добру не приводил.

Хотя, как ЯП PL/SQL я не люблю ... Эх, если б в оракле можно было писать процедуры на Ruby :)

во первых непонятно что сравнивалось в этих тестах, скорость выполнения алгоритмов или все таки обработки данных,
одна из причин почему был придуман PL/SQL так ето для того чтобы сэкономить на трафике между ВД и АпСервером,
надо было провести 2 вида тестов один с поключением БД и АпСервера по Ethernet 100mbit/sec а другой по какому нибудь ADSL 512kbit/set посмотрели бы тогда что будет быстрее,

у нас например соединение между БД и АпСервером 1-10gigabit/sec и
всеравно получается bottleneck в соединении и количествах запросов к базе данных, это social welfare system с миллионами записей в которую входят пенсии,стипендии, пособия по безработице, кредиты на учебу, пенсии по инвалидности,участникам войн и т,д,вообщем каждый житель страны находится в этой БД,проходил через нее или пользуется услугами этого ведомства регулярно,
каждый раз когда например клиент звонит и спрашивает что то или ему чтото поменять , оператору нужна вся информация по клиенту от дня рождения до того где воевал, сколько получает,сколько должен и т,д,
количество запросов к базе данных в часы пик доходит до 500-1000 запросов в секунду только от одной программы, так только PL/SQL и спасает в таких ситуациях и постоянно приходится оптимизировать ети запросы, все время пытаемся сократить количество обращений к базе данных,

оба языка предназначены для выполнения определенной задачи и при умелом распределении нагрузки между ними можно добиться наилучшего результата ,
а данный тест это скорее всего тест- какой язык быстрее печатает "Hello World"

питон - the best. остальное говно.

давайте сформируем конкретный список вопросов к автору и запостим ему. Он вроде вменяемый и идет на контакт.

Скажем, есть 2 варианта сделать некую функциональность -

>1) Реализовать ее в БД с помощью триггеров, процедур и нативных подключаемых библиотек на C; разумеется, все это будет работать только на определенной версии оракла, определенной ОС, будет абсолютно нетестируемо и понятно одному лишь оракл-гуру, который это напишет.

Вранье и полное непонимание вопроса. Oracle API не менялось с седьмой версии; какой это год - в Google. Хранимая процедура, написанная на plsql или Java будет работать на любой ОС и на любой разумной версии Oraclе, а именно на любой, начиная с седьмой.

>Производительность примерно сравнимая с первым случаем, код понятен обычному, не являющемуся спецом в оракле, Java разработчику, коих на проекте абсолютное большинство.

На больших одъемах данных производительность первого и второго вариантов несравнима. Простой пример - выполнить процедуру FOR EACH ROW для UPDATE по таблице с несколькими миллиардами записей.

>На больших одъемах данных производительность первого и второго вариантов несравнима. Простой пример - выполнить процедуру FOR EACH ROW для UPDATE по таблице с несколькими миллиардами записей.

А разве такая процедура должна проводиться регулярно? Понимаю разово при апгрейде версии софта(схемы), но что б в повседневной работе перебирать все записи и их обновлять...

Автор читал лицензионное соглашение при закачке Oracle XE? В частности раздел о бенчмарках.

Автору явно нужно почитать Кайта для начала. Код на PL/SQL написан сознательно или несознательно неоптимально. Для циклов предпочтительно использовать BULK COLLECT, да и бежать по двум вложенным циклам, это нечто ... Обычно такие вещи выносятся в один разумный запрос, с использованием аналатики, например. Так что тесту - низачот. PS А юнит-тесты для PL/SQL тоже пишутся на УРА