| 1.1, vpn (??), 14:30, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
а чё это само железо для oracle на 12% дороже?
может, потому он и на 15% быстрее? | | |
| |
| 2.5, highTower (?), 17:04, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
ссылки надо смотреть :-)
а если серьезно, то ключевое слово "решение на базе", т.е. сравнение не СУБД как таковых, а связки J2EE AppServer и СУБД, и по серверам там 2 сервера под Oracle'ом против 4 под SUN+PostgreSQL, так что SUN решил доказать, что его решения в связке с опенсорсом дешевле в разы, чем общепринятые проприетарные. ИМХО. | | |
| |
| 3.10, Все тот же аноним (?), 20:57, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
И. кстати. поступил абсолютно правильно. Если бы еще и RedHat немного больше внимания уделяла PostgreSQL, все вообще было бы здорово. | | |
|
|
| 1.4, TTT (?), 16:22, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
да уж... они еще раз доказали, что сравнение разных программ на разном оборудовании дает разные результаты :-) | | |
| 1.6, rakis (?), 18:04, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"лишь на 15%"
Классно! Здорово! Вот только есть одна проблема. Если мне нужен сапорт для бизнескритичного приложения 7х24, и, при необходимости, выезд специалиста в любое время суток, то варианетов 2 - ORACLE, MS SQL. | | |
| |
| 2.7, alteleid (ok), 18:26, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Сан работает в правильном направлении, пара лет работы и таких вот фуфлорепортов и заказчики будут готовы cлушать про opensource, появится нормальный коммерческий саппорт, все будет заэ_ись, а потом проект кто-нить купит и изменит условия лицензии... :))) | | |
| 2.12, Eratosfen (?), 01:06, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
Полная фигня этот оракловский суппорт 7x24.
Участвовал я в проекте по автоматизации переписи насиления в Украине 2001, купили самый дорогой пакет оракловской поддержки для проекта, все-таки маштабы страны - сотни миллинов записей. Написали запросы, ожидаемое время исполнения 4 месяца, не подходит. Позвали меня, чтобы оптимизировал запросы. Я начал оптимизировать, полезли баги Оракла, запросы реально отрабатывают, но ORACLE не заканчивает запросы, то-есть работу сделал, а уведомить, а том что сделал забыл, висит in busy. Я в суппорт - баги исправьте, наваял баг репорт с примером как вопроизвести, а они мне отвечают - в ORACLE не может быть багов!!!!! мы ничего исправлять не будем, ищите ошибку у себя.
Так найденные мной баги были исправлени ТОЛЬКО ЧЕРЕЗ 4 ГОДА, вот вам и 24x7.
Мы продалбались столько времени с багами оракла, что поняли если бы взяли postgresql, то при наличие исходного кода с экономили бы месяц, как мимниум ( даже если в postgresql багов в два раза больше, хотя я думаю меньше).
Мораль: суппорт нужен только тупым жертвам маркетологов, которым в лень читать мануал. В суппорте и так нифига не знают, но там можна найти роджственую душу, такую же тупую как и ты, которая ткнет тебя в нужную строку мануала. | | |
| |
| 3.14, _Nick_ (??), 07:28, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >В суппорте ... можна найти роджственую душу, такую же тупую как и ты
РЫДАЛ %)))
+5
Опен Сорс рулит!!!
Есть сырцы - твой проект в _ТВОИХ_ руках! | | |
| 3.22, alteleid (ok), 16:18, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Полная фигня этот оракловский суппорт 7x24.
родной, если вы не смогли переписать свой код (SQL-PL/SQL-Java что у вас было), что бы обойти эти баги (а если вам верить, то это просто CRITICAL) то вы зря потратили деньги на саппорт, лучше бы девелоперов нормальных нашли. "Не Верю" (с) не мое | | |
| |
| 4.33, Aleksey (??), 11:29, 12/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
>>Полная фигня этот оракловский суппорт 7x24.
>
>родной, если вы не смогли переписать свой код (SQL-PL/SQL-Java что у вас
>было), что бы обойти эти баги (а если вам верить, то
>это просто CRITICAL) то вы зря потратили деньги на саппорт, лучше
>бы девелоперов нормальных нашли. "Не Верю" (с) не мое
Т.е. ошибки в SELECTах (как я понял из поста) вы предлагаете решать с помощью фронтенда. Это безусловно глубокое решение. Следующий вопрос в том, а нужна ли СУБД если предлагается все вычисления делать на фронтенде.
P.S.: Лучше бы использовали Postgres и заплатили разработчику за поддержку, чем там какие-то 7x24 (но это ИМХО). Живой разработчик всегда лучше живой техподдержки. | | |
| |
| 5.34, alteleid (ok), 17:17, 12/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Простите, при чем здесь фронтэнд? Вы видимо решили так прочитав слово java, значит оракл вы не видели вовсе, Java Stored Procedures ни о чем не говорит?
Я предлагал найти workaraound потому что я не верю в выпуск релизов с критическими/блокирующими ошибками, и если они не смогли его найти -- значит девелоперы хреновые.
ЗЫ С вашим PS я согласен и почти это и написал в своем первом посте.
| | |
|
|
|
|
| 1.9, logka (??), 20:17, 10/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Но постгрес по удобству администрирования, распределения ресурсов между пользователями, бэкапов и востановления, отказоустойчивости и еще ряду других параметров и рядом не стоял с ораклом.... | | |
| |
| 2.11, Все тот же аноним (?), 21:03, 10/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> и рядом не стоял с ораклом....
Да. Но и стоит он сильно дешевле 25 килобаксов за процессор, не считаете? Банкам нет резона внедрять PostgreSQL. Пока, по крайней мере. Всем остальным - проблем нет.
| | |
| |
| 3.17, DXT (??), 09:55, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Банкам нет резона внедрять PostgreSQL.
Есть, на не самые бизнес критичные АС.
главное чтоб кто-либо саппортил.
возможность эскалации проблемы (пусть даже в саппорте народ сильно глупее чем в организации запрашивающей помощь) позволяет перед руководством прикрыть собственный зад ... | | |
| |
| 4.19, Все тот же аноним (?), 12:57, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> Есть, на не самые бизнес критичные АС.
Imho - таки нет резона. Imho Oracle есть смысл держать на SPARC и Solaris, а PostgreSQL - на RHEL и Intel/AMD. Т.е. двойной зоопарк получается - и с железом, и с софтом. Стоимость зоопарков всегда выше стоимости однородной среды. | | |
|
|
|
| 1.16, Кирилл (??), 09:37, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Сравнение странное :) Слон технологичнее и мощнее MS SQL, но до Оракл он не дорос ещё, и разница в цене с Оракл оправдана, как мне кажется. | | |
| 1.20, sabitov (??), 14:41, 11/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Есть сеть на 600+ компов, есть сервак с установленным снортом, который пишет в постгес. Ставим бейз в качестве морды, и через 2 месяца получаем загрузку "много больше единицы" при любом клике на ёб-морде у бейз. Меняем постгрес на оракл и получаем шустрый отклик в ёб-морде вот уже многие месяцы...
Комментари?.. :) | | |
| |
| |
| 3.23, alteleid (ok), 16:21, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>А индексировать и партишить не пробовали ? ;-)
хм, а вроде он сказал ставим оракл, а не делаем partitioning %) | | |
| 3.27, sabitov (??), 17:48, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
Моя плакаль :)
Конечно пробовали! Конечно это давало эффект. Но 10-15% эффекта к времени исполнения запроса на фоне 40+ минут на запрос не делают Вашу жизнь счатливей. Даже на 10% :) | | |
| |
| 4.29, Alter (??), 18:45, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Моя плакаль :)
Моя тоже.. :-)
>Конечно пробовали! Конечно это давало эффект. Но 10-15% эффекта к времени исполнения
>запроса на фоне 40+ минут на запрос не делают Вашу жизнь
>счатливей. Даже на 10% :)
Извините, но при всем уважении без листинга EXPLAIN - "не верю" - (с)
Ну или рассказывайте подробно ;-)
| | |
|
|
| 2.24, Кирилл (??), 16:38, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
ну вообще это не показательный пример, всё же архитектуры существенно различаются и решение хорошо работающее на Слоне может тормозить на Оракл и наоборот | | |
| |
| 3.25, bodun (?), 17:01, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
>ну вообще это не показательный пример, всё же архитектуры существенно различаются и
>решение хорошо работающее на Слоне может тормозить на Оракл и наоборот
>
Внимательно ждем показательных примеров.
| | |
| |
| 4.31, Кирилл (??), 10:04, 12/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Я к тому, что очень многое зависит от "оптимизации" приложения к той или иной СУБД. К примеру, существенно отличается механизм блокировок, хотя бы это подразумевает различный подход к проектированию. Но, опять же, разница в подходе между Слоном и Оракл значительно меньше, чем между Оракл и MS SQL (ещё то гауно). | | |
|
| 3.28, sabitov (??), 18:08, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– |
А что есть "показательный пример"? SELECT COUNT(*) FROM empty_table ?
Собственно, не поймите меня правильно, я не против слона. У него есть вкусности, которых в оракле нет и не предвидится. Просто меня завели результаты сравнения теплого с мягким :)
| | |
| |
| 4.32, Кирилл (??), 11:14, 12/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
"Показательным" был бы пример выполнения некоторой абстрактной логической операции/операций, оптимизированной и реализованной с учётом особенностей СУБД. А не так, что выполнили синтаксически одинаковый запрос на разных СУБД и пытаются делать выводы на этом основании. Реализации SQL существенно различны для разных СУБД и не учитывать этого значит значительно терять в производительности. | | |
|
|
| 2.30, Veter (??), 19:04, 11/07/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Да, бывает. Я как-то раз тестировал промышленную систему с БД PostgreSQL на проце от наладонника 133 МГц и 32 Мб ОЗУ (в девайс Linksys NSLU2 дебиан зашил) и на таблице в 1 миллион записей запрос выполнялся минуту (запрос хитрый был, но после перепроектирования системы он и все остальные запросы летали). И когда я встречаю людей, кто на ксеоне с 2 гигами памяти (а то и больше) добивается подобного эффекта (есть такие, как ни странно) мне даже интересно становится. Хоть бы поделились опытом.
P.S. Если таблица много больше - партишен рулит с кластеризацией, плюс построение таблиц функционалов. Как вы это делали в оракле, не интересует, в чужой монастырь... | | |
|
| 1.35, VD (??), 13:02, 17/07/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Расточили цилиндры у девятки и сравнили с Мерседесом - ездит почти так же быстро, но цена в три раза меньше. А что в машине только скорость важна? Ну не смешно ли? | | |
| 1.36, Аноним (-), 16:24, 01/08/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Самый польшой "+" в решениях использующих Oracle в наличии большого количества действительно больших систем, достаточно быстрых, с доступностью 7х24. Поэтому, начиная большой проект, люди и выбирают проверенные временем решения.
MS SQL - поделка, не более.
PostgreSQL - думаю пока еще в стадии именно таких рекламных "сравнений".
| | |
|
