Комментарии 54
ps: Кстати, вот еще — Oracle готовится «наложить лапу» на Java
«Судите сами — компания EnterpriseDB предлагает аналогичную СУБД...»
Мне кажется на этом перевод можно было закончить.
Мне кажется на этом перевод можно было закончить.
Несправедливо минусуете.
«Кроме привлекательной цены, EnterpiseDB предлагает своим пользователям непревзойденное качество, отличную производительность, масштабируемость, надежность и безопасность. А с новой Postgres Plus Cloud Database компания готова выйти на рынок облачных вычислений.»
Вот это очень рекламная фраза, да. А можно детелей побольше? Например, примеры тестовых баз данных и запросов, которые работают в полтора раза быстрее, чем на оракле? Качество выше чем у оракла, которые на 11 релиз что-то вроде 20 миллионов человеко-дней потратили?
Я отлично понимаю, что это перевод, а не ваш пост. И я не собираюсь рекламировать тут оракл, конечно. Но хотелось бы найти ссылки на какие-то подтверждения таким словам, да.
«Кроме привлекательной цены, EnterpiseDB предлагает своим пользователям непревзойденное качество, отличную производительность, масштабируемость, надежность и безопасность. А с новой Postgres Plus Cloud Database компания готова выйти на рынок облачных вычислений.»
Вот это очень рекламная фраза, да. А можно детелей побольше? Например, примеры тестовых баз данных и запросов, которые работают в полтора раза быстрее, чем на оракле? Качество выше чем у оракла, которые на 11 релиз что-то вроде 20 миллионов человеко-дней потратили?
Я отлично понимаю, что это перевод, а не ваш пост. И я не собираюсь рекламировать тут оракл, конечно. Но хотелось бы найти ссылки на какие-то подтверждения таким словам, да.
Миллионы человеко-дней ничего не значат, когда делают такое:
vnaum.livejournal.com/9731.html
vnaum.livejournal.com/9731.html
И вы верите в 20 миллионов человеко-дней? Даже если будет 1000 человек участвовать в проекте, это займет 54 года, это при том, что я не учитывал выходные и праздники. Да это чистейший бред.
В оракле по данным с педивикии работает 108 тысяч человек. Между 10-м и 11-м релизом четыре года разницы. Я не пытаюсь что-то доказать или опровергнуть, но видно, что при таких условиях это может быть правдой.
Ну да, львиная доля это тех. поддержка, внедрение и юр. отдел. Ну да, если тупо взять всех сотрудников компании. А если взять только тех, кто реально участвовал в разработке. Я так понимаю, что не стоит считать тех, кто косвенно участвовал в проекте, тогда придется добавить тех кто строил здание, кто ремонтировал канализацию, тех кто делает еду и все такое.
Я даже не верю в то, что 1000 работает над продуктом. И то, если 1000 человек работает над ораклом, то их пора разогнать, т.к. они лентяи.
Я даже не верю в то, что 1000 работает над продуктом. И то, если 1000 человек работает над ораклом, то их пора разогнать, т.к. они лентяи.
Вот это очень рекламная фраза, да.Вы как-будто первый раз видите маркетинговую бла-бла-бла. Этот материал рассчитан на не-техническую аудиторию, если вам нужна дополнительная информация — запросите её у EntDB.
Качество выше чем у оракла, которые на 11 релиз что-то вроде 20 миллионов человеко-дней потратили?А сколько потрачено человеко-дней на PostgreSQL?
Эх, картинка замечательно подобрана!
а что это вообще такое на картинке ??
16 июня 2011 года во время тренировки опрокинулся катамаран команды Oracle Racing.
Видео на youtube
Видео на youtube
Катамаран кувыркнул пр сильном ветре. Неприятное, но достаточно обычное дело для гоночных катамаранов-тримаранов.
НЛО прилетело и опубликовало эту надпись здесь
Катамаран на какой-то регате, спонсированный оракулом.
Катамаран завален, но завалить катамаран надо очень постараться. Это, наверное, символизирует
Катамаран завален, но завалить катамаран надо очень постараться. Это, наверное, символизирует
Это пример того что происходит с парусом если в оверштаг слишком резко войти :)
Да еще и на порывистом ветре.
Да еще и на порывистом ветре.
Статья чуть более чем полностью состоит из маркетинговой водички, причём направленная на инвестора. Дали бы подробностей насчёт загадочной Postgres Plus Cloud Database. С удовольствием бы почитал на русском языке.
Дали бы подробностей насчёт загадочной Postgres Plus Cloud Database.Так это, судя по описанию, обычный PostgreSQL, заточенный под работу в cloud. Ну, может быть еще с oracle-совместимостью, т.к. эта главная фишка enterprisedb.
А на каком уровне обеспечивается эта совместимость и легкость миграции, кстати? Вот у меня есть 300 хранимых процедур, написанных и оптимизированных под PL/SQL в 11gR2. Что мне надо сделать чтобы перенести это все под EntDB?
Статья чуть более чем полностью состоит из маркетинговой водички, причём направленная на инвестора.Да. Это перевод с forbes.com и статья рассчитана на соответствующую аудиторию.
Как минимум в России, многим руководителям, не особо разбирающимся в IT достаточно услышать красивое и распиареное слово «Oracle», чтобы принять решение о внедрении продукта, не зависимо от качества системы, которая этот Oracle использует. «Нужно автоматизировать %department%!» «Давайте поставим X» «Нет, давайте поставим Y» «Что использует X?» «Mysql» «Нет, говно! Давай-те ка что-нибудщь на Oracle» и плевать что Х-система, развивающаяся десять лет и на практике доказавшая своё превосходство, а Y — использует Oracle, но написан студентами за пол-года и толком не оттестирован. Это же ведь Oracle!!!
Теоретически да — по базе судить о всей системе неправильно, но на практике студенты выбирают как раз Mysql, так что у озвученной Вами позиции есть определенные причины.
Люто плюсую! Мы производим прекрасный и весьма популярный продукт в своей отрасли. Но есть ряд клиентов, которые говорят «А какая у вас СУБД? Firebird?? Что за говно! До свидания.» Поэтому теперь новый продукт делается кросс-СУБДшным, исключительно в маркетинговых целях.
В двух конторах вообще печальный опыт был. Биллинг у телефонистов на paradox ещё, синие окошки и прочие прелести. Работал как часы, ни у кого и вопросов не возникало — всем нравился, вопросов ни у кого не было. Прислало управление свою программу — Oracle, клиент-сервер, Delphi… пол года ума дать не могли, и в конце просто забили уже, автоматизацию в Excel довершали. А в другой (жкх) — на XBase++ и dbf, с консольной графикой — тоже считало всю область, старовато, но работало и математика была вся — комар носа не подточит. Год назад пришли «маркетологи „Oracle, Windows, On-line“… до сих пор раком стоим.
НЛО прилетело и опубликовало эту надпись здесь
Один 'бессменный высокий начальник', в одной бюджетной организации, повздорил с начальником рангом пониже небольшого отдела информатизации (который на протяжении 10 лет успешно апгрейдил и поддерживал автоматизацию документооборота и воспитывал вполне себе IT специалистов, даже в условиях низких зарплат), причина была банальна — в следствии глупости этого начальника, обсуждения и решения о внедрении очередных задач просто шли мимо него на более высокий уровень…
Так вот среди перлов этого обиженного начальника были, кстати безуспешные, попытки 'внедрения' абсолютно не подходящих решений, разработанных на стороне и не адаптированных под реалии организации (как и с любыми САП системами, их нужно пилить под заказчика), тем более при успешной живой и развивающейся системе, уже решающей необходимые задачи… как результат конфликта — разбежавшийся отдел информатизации, полное прекращение разработок чего-либо, и медленная деградация автоматизации во всей организации и возврат к бумажкам… SAP R3 кстати так же 'пытались внедрить', все действия что были предприняты — это тупо пропилены бабки.
Oracle закупался на миллионные контракты так, что сервера стояли по 4-5 лет (думаю до сих пор стоят) ничем не занятые и уже морально устаревшие. Параллельно закупили IBM DB (вдумайтесь в смысл), так же думаю никем не тронутый,… при этом задачи вполне себе легко ложатся на PostgreSQL, не те нагрузки и не те задачи, что уже предлагаются решенными у Oracle.
p.s. это я к тому, что решения о выборе того или иного продукта в России принимаются даже не из маркетинговых соображений, а тупо по объемам попила… на mysql несколько десятков миллионов не по пилишь — шибко дешево, а вот на Oracle можно, там и простынки для отчетов уже маркетологами написаны.
Так вот среди перлов этого обиженного начальника были, кстати безуспешные, попытки 'внедрения' абсолютно не подходящих решений, разработанных на стороне и не адаптированных под реалии организации (как и с любыми САП системами, их нужно пилить под заказчика), тем более при успешной живой и развивающейся системе, уже решающей необходимые задачи… как результат конфликта — разбежавшийся отдел информатизации, полное прекращение разработок чего-либо, и медленная деградация автоматизации во всей организации и возврат к бумажкам… SAP R3 кстати так же 'пытались внедрить', все действия что были предприняты — это тупо пропилены бабки.
Oracle закупался на миллионные контракты так, что сервера стояли по 4-5 лет (думаю до сих пор стоят) ничем не занятые и уже морально устаревшие. Параллельно закупили IBM DB (вдумайтесь в смысл), так же думаю никем не тронутый,… при этом задачи вполне себе легко ложатся на PostgreSQL, не те нагрузки и не те задачи, что уже предлагаются решенными у Oracle.
p.s. это я к тому, что решения о выборе того или иного продукта в России принимаются даже не из маркетинговых соображений, а тупо по объемам попила… на mysql несколько десятков миллионов не по пилишь — шибко дешево, а вот на Oracle можно, там и простынки для отчетов уже маркетологами написаны.
Нет повести печальнее на свете, чем маркетолог в интернете.
Полез проверить есть ли что-то реализующее масштабируемость по принципу N-masters кластера. Т.е. прямой аналог Oracle RAC/GRID.
Вообще говоря, юзабили сайта (www.enterprisedb.com, я туда попал, правильно?) ужасное, потыкавшись на разные разделы я так и не попал куда-нибудь, где бы мне адекватно, по главам, представили документацию хотя бы в плане отличий от Postgresql.
Отчаявшись я ввел в гугл свой вопрос и все таки получил ответ на него.
2.4.5 Synchronous Multi-Master Replication
…
Postgres Plus Advanced Server does not offer this type of replication, though Postgres Plus Advanced Server two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.
Это ваши слова, «Судите сами — компания EnterpriseDB предлагает аналогичную СУБД.»
Что вы в самом деле, фигню втираете. Да ладно бы где, здесь то зачем. Стыдно должно быть.
Полез проверить есть ли что-то реализующее масштабируемость по принципу N-masters кластера. Т.е. прямой аналог Oracle RAC/GRID.
Вообще говоря, юзабили сайта (www.enterprisedb.com, я туда попал, правильно?) ужасное, потыкавшись на разные разделы я так и не попал куда-нибудь, где бы мне адекватно, по главам, представили документацию хотя бы в плане отличий от Postgresql.
Отчаявшись я ввел в гугл свой вопрос и все таки получил ответ на него.
2.4.5 Synchronous Multi-Master Replication
…
Postgres Plus Advanced Server does not offer this type of replication, though Postgres Plus Advanced Server two-phase commit (PREPARE TRANSACTION and COMMIT PREPARED) can be used to implement this in application code or middleware.
Это ваши слова, «Судите сами — компания EnterpriseDB предлагает аналогичную СУБД.»
Что вы в самом деле, фигню втираете. Да ладно бы где, здесь то зачем. Стыдно должно быть.
PostgreSQL имеет встроенные языки для написания процедур, в том числе совместимый (с оговорками) с PL/SQL
PostgreSQL имеет архитектуру сходную (с оговорками) с архитектурой Oracle
Нет речи про большую зелёную кнопку «Сделать хорошо». Речь о том, что переход с Oracle на EnterpriseDB будет значительно дешевле чем на, скажем, DB2 или MS SQL. Не понадобится всё переписывать с нуля.
PostgreSQL имеет архитектуру сходную (с оговорками) с архитектурой Oracle
Нет речи про большую зелёную кнопку «Сделать хорошо». Речь о том, что переход с Oracle на EnterpriseDB будет значительно дешевле чем на, скажем, DB2 или MS SQL. Не понадобится всё переписывать с нуля.
Речь о том, что переход с Oracle на EnterpriseDB будет невозможен, либо очень дорог из-за того, что многие годами работающие вещи придется переписывать на коленке на стороне приложения, либо делать middleware, а это еще одна точка отказа, которая в свою очередь потребует резервирования и цепочка потянулась.
Основная проблема состоит в непонимании ситуации. Под простые задачи, которые в состоянии выполнять
опенсорсные субд никто и не будет использовать Oracle, потому что это просто _очень_ дорого. А задачи, под которые объективно был выбран Оракл, требуют возможностей, которые предоставляет Оракл. И спрыгивать на что-то другое, пока это другое до дотянется до требуемой функциональности просто идиотизм.
Основная проблема состоит в непонимании ситуации. Под простые задачи, которые в состоянии выполнять
опенсорсные субд никто и не будет использовать Oracle, потому что это просто _очень_ дорого. А задачи, под которые объективно был выбран Оракл, требуют возможностей, которые предоставляет Оракл. И спрыгивать на что-то другое, пока это другое до дотянется до требуемой функциональности просто идиотизм.
А задачи, под которые объективно был выбран ОраклА если Oracle был выбран не объективно? ;-)
Ну тогда, значит, он был выбран за откат реселлеру или по какой другой необъективной причине.
Конечно, в очень многих случаях тот же мускул отработает ничуть не хуже. В тех N % случаев, где он не отработает (обычно это сложная аналитика и HAC) надо внимательно посмотреть на то, что предлагает Postgres. Пока что, из цитаты ваше, предложение самому реализовать мульти-мастер репликацию на уровне приложения, звучит не очень заманчиво.
Конечно, в очень многих случаях тот же мускул отработает ничуть не хуже. В тех N % случаев, где он не отработает (обычно это сложная аналитика и HAC) надо внимательно посмотреть на то, что предлагает Postgres. Пока что, из цитаты ваше, предложение самому реализовать мульти-мастер репликацию на уровне приложения, звучит не очень заманчиво.
Если не сложно, не ради холивара, можете описать под какие задачи разрабатывался Oracle?
Сразу оговорюсь — я вебразработчик и некоторые вещи мне довольно сложно понять. Вроде как репликация есть и в мускале, и в грескэле, и в оракле.
select\update\insert\delete тоже везде есть (ну может чего-то нету в оракле — не пользовался им)
разновидности движков для таблиц — тут вроде тоже проблем нет.
Спрошу даже по другому, для каких типов данных предназначен оракл, и почему он чем он так ценен?
Заранее спасибо за ответ
Сразу оговорюсь — я вебразработчик и некоторые вещи мне довольно сложно понять. Вроде как репликация есть и в мускале, и в грескэле, и в оракле.
select\update\insert\delete тоже везде есть (ну может чего-то нету в оракле — не пользовался им)
разновидности движков для таблиц — тут вроде тоже проблем нет.
Спрошу даже по другому, для каких типов данных предназначен оракл, и почему он чем он так ценен?
Заранее спасибо за ответ
Сразу оговорюсь, что даю вам не ответ, а лишь свои размышления.
Вы когда-нибудь слышали об крупных DWH, успешно реализованными под управлением MySQL? PG? Я лично — не особо. В новостной ленте постоянно всплывает информация об Oracle, MS SQL и DB2, а вот хранилища на PG,MySQL — не особо на слуху. Только сейчас, погуглив, я выяснил, что есть люди, которые задаются этим же вопросом, и что даже есть люди, которые им что-то отвечают.
Вы бы сами не побоялись под управлением этих СУБД консолидировать данные, скажем о продажах в пятиста крупных розничных магазинов в течении пяти последних лет, с целью получения аналитики вроде динамики изменения средней суммы чека, какой товар с каким чаще берут вместе, влияние сезонности на спрос по товару и многого, многого другого. Я, лично — очень струхнул бы. Предпочел бы проконсультироваться с вендором, поискать прецеденты. В случае с ораклом есть и именитый вендор, чье слово не стыдно «пришить к делу», на чье слово можно опереться, есть и множество прецедентов, которыми можно блеснуть в презентации перед акционерами. А в случае с тем же ПГ? На кого именитого сослаться, подкрепляя собственное решение?
Потому и получается, что когда мы говорим об DWH, выбор может пасть только на Оракл, MS, IBM и без всяких там откатов. Сеть изобилует сравнением решений для этих субд, на разных железных платформах, оставляя ощущение, что другие СУБД для этих целей просто никто не использует.
А дальше лишь вопрос лицензирования. Если уж мы приобретаем лицензию оракла для DWH, то зачем использовать что либо другое для всего прочего? Тонкостей лицензирования я не знаю, но у нас в конторе никто особо не напрягается разворачивая новую БД под oracle database для новых решений в продакшн. Вроде как тем самым мы лицензионное соглашение не нарушаем.
Вы когда-нибудь слышали об крупных DWH, успешно реализованными под управлением MySQL? PG? Я лично — не особо. В новостной ленте постоянно всплывает информация об Oracle, MS SQL и DB2, а вот хранилища на PG,MySQL — не особо на слуху. Только сейчас, погуглив, я выяснил, что есть люди, которые задаются этим же вопросом, и что даже есть люди, которые им что-то отвечают.
Вы бы сами не побоялись под управлением этих СУБД консолидировать данные, скажем о продажах в пятиста крупных розничных магазинов в течении пяти последних лет, с целью получения аналитики вроде динамики изменения средней суммы чека, какой товар с каким чаще берут вместе, влияние сезонности на спрос по товару и многого, многого другого. Я, лично — очень струхнул бы. Предпочел бы проконсультироваться с вендором, поискать прецеденты. В случае с ораклом есть и именитый вендор, чье слово не стыдно «пришить к делу», на чье слово можно опереться, есть и множество прецедентов, которыми можно блеснуть в презентации перед акционерами. А в случае с тем же ПГ? На кого именитого сослаться, подкрепляя собственное решение?
Потому и получается, что когда мы говорим об DWH, выбор может пасть только на Оракл, MS, IBM и без всяких там откатов. Сеть изобилует сравнением решений для этих субд, на разных железных платформах, оставляя ощущение, что другие СУБД для этих целей просто никто не использует.
А дальше лишь вопрос лицензирования. Если уж мы приобретаем лицензию оракла для DWH, то зачем использовать что либо другое для всего прочего? Тонкостей лицензирования я не знаю, но у нас в конторе никто особо не напрягается разворачивая новую БД под oracle database для новых решений в продакшн. Вроде как тем самым мы лицензионное соглашение не нарушаем.
Я бы подписался делать такой масштаб на Postgre. Заказав поддержку у какой-нибудь Postgre-поддерживающей конторы.
— То что Oracle — распиаренный бренд не дает гарантии оперативного закрытия багов
— Не дает гарантии что этих багов нет
— Неизвестно, может быть секономленные бабки лучше вложить в железо?
— И, достаточно наивно надеятся, что раз Oracle, значит не навернется. Лучше не молиться на такие верования, а придумывать стратегию бэкапа данных.
— То что Oracle — распиаренный бренд не дает гарантии оперативного закрытия багов
— Не дает гарантии что этих багов нет
— Неизвестно, может быть секономленные бабки лучше вложить в железо?
— И, достаточно наивно надеятся, что раз Oracle, значит не навернется. Лучше не молиться на такие верования, а придумывать стратегию бэкапа данных.
Вот про архитекттуру, сходную с архитектурой Oracle, это надо очень осторожно говорить. Потому что Лада Калина, в общем-то, имеет принципы работы очень похожие на Порше.
Если вы думаете, что только в этом отличия, то готов вас разочаровать. PostgreSQL отличная СУБД, но до возможностей DB2 и Oracle ей далеко еще. Хотя с другой стороны, вообще не факт, что они уж так прямо нужны.
Насколько я понимаю, наиболее близким аналогом Oracle RAC для PostgreSQL является Postgres-XC, но он пока ещё далек от 1.0.
> В конце декабря компания Oracle сообщила о падении своих акций на 9%.
В свете того, как за прошедший год упал Доу-Джонс, падение на 9% следует считать довольно неплохим ростом.
Я уж не говорю о том, что падение акций может быть вызвано совсем не качеством работы компании, а, например, покупками, или прочими непрямыми причинами, и делать вывод только из одной цифры «упала на 9%» бессмыслено.
В свете того, как за прошедший год упал Доу-Джонс, падение на 9% следует считать довольно неплохим ростом.
Я уж не говорю о том, что падение акций может быть вызвано совсем не качеством работы компании, а, например, покупками, или прочими непрямыми причинами, и делать вывод только из одной цифры «упала на 9%» бессмыслено.
мне кажется сейчас большая часть рынка оракл это комплексные решения, а не голая СУБД, так что предложить аналогичную или лучшую СУБД недостаточно
да, нужен стек решений, типа «лампы», но без «л».
пусть с борманом договорятся. хотя… наверное именно с ним не стоит
пусть с борманом договорятся. хотя… наверное именно с ним не стоит
Да, но у тех компаний, которые захотят делать аналогичные комплексные решения или перенести свои существующие с СУБД Oracle есть возможность использовать Postgres с нормальной поддержкой и т.п. по в разы меньшей цене.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
EnterpriseDB: мы заберём «свой кусок пирога» рынка СУБД у Oracle!