При поддержке Sun Microsystems подготовлен (http://blogs.ittoolbox.com/database/soup/archives/postgresql...) первый полноценный тестовый комплект (http://www.spec.org/jAppServer2004/results/res2007q3/jAppSer...) для оценки производительности решений на базе СУБД PostgreSQL, соответствующий требованиям современных индустриальных стандартов по измерению производительности.
В результате тестирования (http://www.spec.org/jAppServer2004/results/res2007q3/) решение на базе платформы Oracle лишь на 15% производительнее чем промышленное решение на базе PostgreSQL 8.2, но стоимость решения от Oracle оказалось почти в три раза выше ($65,500 (оборудование для PostgreSQL) против $74,000 (оборудование) + $110,000 (лицензии Oracle)).
URL: http://developers.slashdot.org/article.pl?sid=07/07/09/19362...
Новость: http://www.opennet.me/opennews/art.shtml?num=11360
а чё это само железо для oracle на 12% дороже?
может, потому он и на 15% быстрее?
ссылки надо смотреть :-)
а если серьезно, то ключевое слово "решение на базе", т.е. сравнение не СУБД как таковых, а связки J2EE AppServer и СУБД, и по серверам там 2 сервера под Oracle'ом против 4 под SUN+PostgreSQL, так что SUN решил доказать, что его решения в связке с опенсорсом дешевле в разы, чем общепринятые проприетарные. ИМХО.
И. кстати. поступил абсолютно правильно. Если бы еще и RedHat немного больше внимания уделяла PostgreSQL, все вообще было бы здорово.
ключевые слова "современных индустриальных стандартов"
Хоть какая то хорошая новость за день .... :)
да уж... они еще раз доказали, что сравнение разных программ на разном оборудовании дает разные результаты :-)
"лишь на 15%"
Классно! Здорово! Вот только есть одна проблема. Если мне нужен сапорт для бизнескритичного приложения 7х24, и, при необходимости, выезд специалиста в любое время суток, то варианетов 2 - ORACLE, MS SQL.
Сан работает в правильном направлении, пара лет работы и таких вот фуфлорепортов и заказчики будут готовы cлушать про opensource, появится нормальный коммерческий саппорт, все будет заэ_ись, а потом проект кто-нить купит и изменит условия лицензии... :)))
Полная фигня этот оракловский суппорт 7x24.
Участвовал я в проекте по автоматизации переписи насиления в Украине 2001, купили самый дорогой пакет оракловской поддержки для проекта, все-таки маштабы страны - сотни миллинов записей. Написали запросы, ожидаемое время исполнения 4 месяца, не подходит. Позвали меня, чтобы оптимизировал запросы. Я начал оптимизировать, полезли баги Оракла, запросы реально отрабатывают, но ORACLE не заканчивает запросы, то-есть работу сделал, а уведомить, а том что сделал забыл, висит in busy. Я в суппорт - баги исправьте, наваял баг репорт с примером как вопроизвести, а они мне отвечают - в ORACLE не может быть багов!!!!! мы ничего исправлять не будем, ищите ошибку у себя.Так найденные мной баги были исправлени ТОЛЬКО ЧЕРЕЗ 4 ГОДА, вот вам и 24x7.
Мы продалбались столько времени с багами оракла, что поняли если бы взяли postgresql, то при наличие исходного кода с экономили бы месяц, как мимниум ( даже если в postgresql багов в два раза больше, хотя я думаю меньше).
Мораль: суппорт нужен только тупым жертвам маркетологов, которым в лень читать мануал. В суппорте и так нифига не знают, но там можна найти роджственую душу, такую же тупую как и ты, которая ткнет тебя в нужную строку мануала.
>В суппорте ... можна найти роджственую душу, такую же тупую как и тыРЫДАЛ %)))
+5
Опен Сорс рулит!!!
Есть сырцы - твой проект в _ТВОИХ_ руках!
Шедевральный пост ;) +10
>Полная фигня этот оракловский суппорт 7x24.родной, если вы не смогли переписать свой код (SQL-PL/SQL-Java что у вас было), что бы обойти эти баги (а если вам верить, то это просто CRITICAL) то вы зря потратили деньги на саппорт, лучше бы девелоперов нормальных нашли. "Не Верю" (с) не мое
>>Полная фигня этот оракловский суппорт 7x24.
>
>родной, если вы не смогли переписать свой код (SQL-PL/SQL-Java что у вас
>было), что бы обойти эти баги (а если вам верить, то
>это просто CRITICAL) то вы зря потратили деньги на саппорт, лучше
>бы девелоперов нормальных нашли. "Не Верю" (с) не мое
Т.е. ошибки в SELECTах (как я понял из поста) вы предлагаете решать с помощью фронтенда. Это безусловно глубокое решение. Следующий вопрос в том, а нужна ли СУБД если предлагается все вычисления делать на фронтенде.P.S.: Лучше бы использовали Postgres и заплатили разработчику за поддержку, чем там какие-то 7x24 (но это ИМХО). Живой разработчик всегда лучше живой техподдержки.
Простите, при чем здесь фронтэнд? Вы видимо решили так прочитав слово java, значит оракл вы не видели вовсе, Java Stored Procedures ни о чем не говорит?Я предлагал найти workaraound потому что я не верю в выпуск релизов с критическими/блокирующими ошибками, и если они не смогли его найти -- значит девелоперы хреновые.
ЗЫ С вашим PS я согласен и почти это и написал в своем первом посте.
Но постгрес по удобству администрирования, распределения ресурсов между пользователями, бэкапов и востановления, отказоустойчивости и еще ряду других параметров и рядом не стоял с ораклом....
> и рядом не стоял с ораклом....Да. Но и стоит он сильно дешевле 25 килобаксов за процессор, не считаете? Банкам нет резона внедрять PostgreSQL. Пока, по крайней мере. Всем остальным - проблем нет.
>Банкам нет резона внедрять PostgreSQL.
Есть, на не самые бизнес критичные АС.
главное чтоб кто-либо саппортил.
возможность эскалации проблемы (пусть даже в саппорте народ сильно глупее чем в организации запрашивающей помощь) позволяет перед руководством прикрыть собственный зад ...
> Есть, на не самые бизнес критичные АС.Imho - таки нет резона. Imho Oracle есть смысл держать на SPARC и Solaris, а PostgreSQL - на RHEL и Intel/AMD. Т.е. двойной зоопарк получается - и с железом, и с софтом. Стоимость зоопарков всегда выше стоимости однородной среды.
Сравнение странное :) Слон технологичнее и мощнее MS SQL, но до Оракл он не дорос ещё, и разница в цене с Оракл оправдана, как мне кажется.
Есть сеть на 600+ компов, есть сервак с установленным снортом, который пишет в постгес. Ставим бейз в качестве морды, и через 2 месяца получаем загрузку "много больше единицы" при любом клике на ёб-морде у бейз. Меняем постгрес на оракл и получаем шустрый отклик в ёб-морде вот уже многие месяцы...Комментари?.. :)
А индексировать и партишить не пробовали ? ;-)
>А индексировать и партишить не пробовали ? ;-)хм, а вроде он сказал ставим оракл, а не делаем partitioning %)
Моя плакаль :)
Конечно пробовали! Конечно это давало эффект. Но 10-15% эффекта к времени исполнения запроса на фоне 40+ минут на запрос не делают Вашу жизнь счатливей. Даже на 10% :)
>Моя плакаль :)Моя тоже.. :-)
>Конечно пробовали! Конечно это давало эффект. Но 10-15% эффекта к времени исполнения
>запроса на фоне 40+ минут на запрос не делают Вашу жизнь
>счатливей. Даже на 10% :)Извините, но при всем уважении без листинга EXPLAIN - "не верю" - (с)
Ну или рассказывайте подробно ;-)
ну вообще это не показательный пример, всё же архитектуры существенно различаются и решение хорошо работающее на Слоне может тормозить на Оракл и наоборот
>ну вообще это не показательный пример, всё же архитектуры существенно различаются и
>решение хорошо работающее на Слоне может тормозить на Оракл и наоборот
>
Внимательно ждем показательных примеров.
Я к тому, что очень многое зависит от "оптимизации" приложения к той или иной СУБД. К примеру, существенно отличается механизм блокировок, хотя бы это подразумевает различный подход к проектированию. Но, опять же, разница в подходе между Слоном и Оракл значительно меньше, чем между Оракл и MS SQL (ещё то гауно).
А что есть "показательный пример"? SELECT COUNT(*) FROM empty_table ?
Собственно, не поймите меня правильно, я не против слона. У него есть вкусности, которых в оракле нет и не предвидится. Просто меня завели результаты сравнения теплого с мягким :)
"Показательным" был бы пример выполнения некоторой абстрактной логической операции/операций, оптимизированной и реализованной с учётом особенностей СУБД. А не так, что выполнили синтаксически одинаковый запрос на разных СУБД и пытаются делать выводы на этом основании. Реализации SQL существенно различны для разных СУБД и не учитывать этого значит значительно терять в производительности.
> Комментари?.Прокладку между табуретом и монитором менять не пробовали? Иногда радикально помогает.
Да, бывает. Я как-то раз тестировал промышленную систему с БД PostgreSQL на проце от наладонника 133 МГц и 32 Мб ОЗУ (в девайс Linksys NSLU2 дебиан зашил) и на таблице в 1 миллион записей запрос выполнялся минуту (запрос хитрый был, но после перепроектирования системы он и все остальные запросы летали). И когда я встречаю людей, кто на ксеоне с 2 гигами памяти (а то и больше) добивается подобного эффекта (есть такие, как ни странно) мне даже интересно становится. Хоть бы поделились опытом.P.S. Если таблица много больше - партишен рулит с кластеризацией, плюс построение таблиц функционалов. Как вы это делали в оракле, не интересует, в чужой монастырь...
Расточили цилиндры у девятки и сравнили с Мерседесом - ездит почти так же быстро, но цена в три раза меньше. А что в машине только скорость важна? Ну не смешно ли?
Самый польшой "+" в решениях использующих Oracle в наличии большого количества действительно больших систем, достаточно быстрых, с доступностью 7х24. Поэтому, начиная большой проект, люди и выбирают проверенные временем решения.
MS SQL - поделка, не более.
PostgreSQL - думаю пока еще в стадии именно таких рекламных "сравнений".