Comments 13
>Полученные данные показали, что время выполнения MySQL реализации функции ‘fibonacci’ в 16.5 раз превышает время выполнение аналогичной функции на PHP.
Оргвыводы: использовать процедурное расширение СУБД нужно (мое мнение) для администрировании баз данных, но никак не для реализации бизнес-логики, что часто можно слышать от отдельных товарищей. К.О.
Неправильные оргвыводы. Точнее, не универсальные.
Правильный вывод: не считайте числа фибоначи на стороне БД.
Если логика не считает чисел фибоначи или интегралы, а содержит очень много выборок из БД и вставок туда же, то быстрее будет работать хранимка, а не перегон больших объёмов данных в php и обратно. Ваш К.О.
Перегон больших объемов данных это уже их оперы администрирования баз данных. У тебя запись экземпляра элемента модели данных это 10 000 строк в N таблицах, который извлекается одним запросом, либо одна строка в тех же N таблицах?
Есть выборка табличных данных, но для тех же табличных данных людям придумали LIMIT со смещением и количеством выбираемых строк. Никто не будет делать выборку всей таблице, чтобы потом перегонять ее в логику приложения, лишь для того, чтобы там обработать и показать 100 строк.
Ваш К.О.
Есть выборка табличных данных, но для тех же табличных данных людям придумали LIMIT со смещением и количеством выбираемых строк. Никто не будет делать выборку всей таблице, чтобы потом перегонять ее в логику приложения, лишь для того, чтобы там обработать и показать 100 строк.
Ваш К.О.
Обычно, бизнес-логика — это не только выборка.
А при администрировании БД даже страшно представить, зачем надо перекачивать много данных. Это же работа на уровне DDL / настроек сервера. А много данных качаются бэкапом или репликацией, тут уже прерогатива движка сервера БД, и хранимки/PHP тут совершенно непричём.
А при администрировании БД даже страшно представить, зачем надо перекачивать много данных. Это же работа на уровне DDL / настроек сервера. А много данных качаются бэкапом или репликацией, тут уже прерогатива движка сервера БД, и хранимки/PHP тут совершенно непричём.
UFO just landed and posted this here
Этот вывод абсолютно не следует из бессмысленного бенчмарка.
А вот почему не следует пихать логику в БД очень хорошо описано тут: habrahabr.ru/blogs/refactoring/65432/
А вот почему не следует пихать логику в БД очень хорошо описано тут: habrahabr.ru/blogs/refactoring/65432/
[trollmode]
а вот в номальной СУБД можно было бы написать хранимку на java/c/c#/…
[/trollmode]
:)
а вот в номальной СУБД можно было бы написать хранимку на java/c/c#/…
[/trollmode]
:)
Хранимки в БД необходимы только для работы с хранимыми в БД данными, но ни с чем другим, если нужен высокая производительность используйте соответствующие языки программирования, можно написать на c/c++ библиотеку для PHP, довольно просто делается.
Просто для констатации факта…
2000 запусков
PHP: 0.45 секунд
PostgreSQL pl/pgsql: 0.018 секунд
1 запуск
PHP: 0.2 миллисекунды
PostgreSQL pl/pgsql: 0.027 миллисекунды
PS Да, рекурсия в PostgreSQL поддерживается и опять да — функция IMMUTABLE.
2000 запусков
PHP: 0.45 секунд
PostgreSQL pl/pgsql: 0.018 секунд
1 запуск
PHP: 0.2 миллисекунды
PostgreSQL pl/pgsql: 0.027 миллисекунды
PS Да, рекурсия в PostgreSQL поддерживается и опять да — функция IMMUTABLE.
return fibonacci(n -1) + fibonacci(n -2)
Хрестоматийный пример неправильного подхода к рекурсии.
И, да: почему всего 11? Слишком мало, развернуться негде.
Если брать больше число, то нужно изменять значение параметра @@thread_stack. Я решил не дергать mysql сервер и остановился на этом числе.
В чем же заключается неправильный подход, позвольте поинтересоваться?
В чем же заключается неправильный подход, позвольте поинтересоваться?
Число вызовов функции растёт показательно (2 ^ n) по мере роста глубины рекурсии.
Небольшой пример на Perl:
То есть, вы в корне неправильно поступаете, измеряя производительность двумя разными алгоритмами.
Небольшой пример на Perl:
$ time perl -e 'sub fib1 {my $n = shift; return 1 if $n == 1 || $n == 2; return fib1($n - 2) + fib1($n - 1)} my $r; $r = fib1(11) for 1..2000; print "$r\n"'
89
real 0m0.575s
...
$ time perl -e 'sub fib2{my $n = shift; return 1 if $n == 1 || $n == 2; my ($a, $b) = (1, 1); for my $i (3..$n) {($a, $b) = ($b, $a+$b)} return $b} my $r; $r = fib2(11) for 1..2000; print "$r\n";'
89
real 0m0.039s
...
То есть, вы в корне неправильно поступаете, измеряя производительность двумя разными алгоритмами.
Sign up to leave a comment.
Меня удивляют эти поцреоты