The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Red Hat стал инвестором компании EnterpriseDB, развивающей PostgreSQL

28.10.2009 10:52

Компания EnterpriseDB, выпускающая коммерческую версию PostgreSQL и финансирующая большое число разработчиков данной свободной СУБД, объявила о заключении партнерских отношений с мировым лидером в области Linux решений – Red Hat. Последняя намеревается инвестировать в EnterpriseDB значительные средства с целью еще глубже внедрить открытые технологии в IT инфраструктуру современных корпораций.

«Совершенно очевидно, что EnterpriseDB – это ведущий разработчик Postgres для крупных предприятий. Вот почему Red Hat решил сотрудничать с этой компанией» - заявил президент Red Hat Джим Вайтхерст (Jim Whitehurst). Помимо передовых позиций в области предоставления SQL решений, EnterpriseDB имеет сходную с Red Hat модель работы с клиентами, когда необходимые услуги предоставляются в соответствии с оформленной подпиской. Это также должно способствовать сближению взглядов двух крупнейших вендоров на совместную работу.

Основное направление деятельности EnterpriseDB – это помощь организациям, работающим в индустрии IT, в поиске и интеграции решений на базе свободной базы данных PostgreSQL. Выпускаемый компанией продукт - Postgres Plus, является сертифицированным дистрибутивом PostgreSQL, и включает в себя набор дополнительных компонентов вместе с профессиональной документацией. Помимо стоимостного преимущества opensource решений, EnterpriseDB подчеркивает легкую интеграцию своей базы данных с Red Hat Enterprise Linux и сервером приложений JBoss. Компании надеются, что их совместная работа ускорит продвижение открытых решений в качестве альтернативы проприетарным.

  1. Главная ссылка к новости (http://www.reuters.com/article...)
  2. OpenNews: Вышел релиз EnterpriseDB 8.3R2, коммерческой СУБД на базе PostgreSQL
  3. OpenNews: Red Hat и SYNNEX создали альянс для компаний-интеграторов открытого ПО
  4. OpenNews: Исходные тексты GridSQL открыты под лицензией GPL
  5. OpenNews: Анонсированы Postgres Plus и Postgres Plus Advanced Server
Автор новости: blkdog
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/24004-PostgreSQL
Ключевые слова: PostgreSQL, Linux, REHL, redhat
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, bys76ru (?), 11:18, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это ответ Ораклу на попытку отделиться и создать собственный дистр.
     
     
  • 2.7, CAHbKA (?), 14:24, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это ответ Ораклу на попытку отделиться и создать собственный дистр

    у оракла уже который год "свой" дистр, примерно со времен RHEL 4.5

    мысли:
    1) Шум оракл-mysql инспирирован ораклом, чтобы придать mysql хоть какую-то ценность в скв
    2) считаю redhat в целом достаточно умными, чтобы они купили такое Г, как mysql

     
     
  • 3.11, vitek (??), 17:36, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    забавно, кто-бы и что-бы не писал, а мускуль по-прежнему основная субд для веб.
    и вот таких проектов:
    >Компания Amazon в рамках нового сервиса Amazon RDS начала предоставление в аренду облачных окружений с MySQL 5.1 (используется хранилище InnoDB).

    http://www.opennet.me/opennews/art.shtml?num=24000
    что-то не видно и не слышно ни на оракле, ни на постгискл...

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

     
     
  • 4.14, gleb (?), 09:53, 30/10/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >хм... мускуль - субд одного уровня с мсскл, сайбэйз, информикс и т.д.
    >но добится вразумительных комментов, почему же оно г... - не представляется
    >возможным.

    На вскидку:

    InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.

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

    Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеет

    PS: по мне, так для веба в любом случае нужны дополнительные звенья в архитектуре хранения данных. Нужно активно использовать кеширование (memcache) либо специфичные для задачи решения (например часть данных хранить в tokyo tyrant или memcachedb)

     
     
  • 5.18, vitek (??), 05:18, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.

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

    и тем не менее, запросы в мускуле выполняются быстрее. :-D
    не говоря уж о требуемых ресурсах.
    >Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеет

    смотря как настроить... в подавляющем большинстве случаев мускуль быстрее... и меньше жрёт. про амазон выше ссылку давал - один (а по-всему видать - решающий) повод в выборе именно мускуля.
    зы:
    видывал (и к сожалению очень часто) я такое г..., сделанное и на постргри, и на оракле, и т.д. ..... как правило перцами, кричащими, что что-то там г..., а что-то там круть.
    но также видел и на мускуле практически гениальные решения.

     
     
  • 6.23, gleb (?), 15:14, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > а зачем её модифицировать?

    проект растет и развивается => меняются задачи => меняется структура БД

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

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

    PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта?

     
     
  • 7.24, vitek (??), 15:23, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >проект растет и развивается => меняются задачи => меняется структура БД

    в любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.
    как следствие - в большинстве случаев данные строки должны находится рядом, а не по всему рэйду тонким слоем... а если нет, то можно и доп. таблице подумать (master - detail). или просто построить новую (что чаще всего и происходит)
    >как минимум странный аргумент. алгоритмы выборки данных никто не отменял,  и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.

    почему странный? никакой план выполнения не заменит здравый смысл... и факты.
    мускуль занял место основной субд для инета по-праву. аргументы я уже приводил. не вижу смысла повторяться.

     
     
  • 8.25, vitek (??), 15:31, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ах, да и что проектируйте б д и пишите запросы правильно да и хинты даже в ор... текст свёрнут, показать
     
     
  • 9.26, gleb (?), 15:53, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    с таким подходом рынок интернет-сервисов еще в каменном веке бы был сейчас реша... текст свёрнут, показать
     
     
  • 10.27, vitek (??), 17:00, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    глупости для профи по времени делать что так, что так - один хрен к примеру н... текст свёрнут, показать
     
     
  • 11.28, gleb (?), 20:45, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    похоже вы не совсем понимаете темпы и условия в которых делаются веб-стартапы р... текст свёрнут, показать
     
     
  • 12.29, vitek (??), 11:47, 01/11/2009 [^] [^^] [^^^] [ответить]  
  • +/
    и много у Вас подобных стартапов и вот это так и будет продолжаться неужел... текст свёрнут, показать
     

  • 1.2, uZver (??), 11:19, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    +1. хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDB
     
     
  • 2.6, аноним (?), 14:01, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDB

    Ну я понимаю они могут купить мускуль у оракла, но у EnterpriseDB как?

     
     
  • 3.9, Warhead Wardick (?), 16:45, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Как -как, как обычно!

    А вот PostgreSQL - да купить невозможно :)


    пЫсЫ: Долгих лет процветания слону! Самя Ъ-db :)

     

  • 1.3, Антон (??), 11:45, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Готов сделать денежную ставку за то, что в ближайший год Red Hat купит бизнес EnterpriseDB. Сейчас оптимальной сделке мешает волна поднятая из-за Oracle/MySQL. Но вот когда страсти улягутся, готов поспорить  Red Hat купит EnterpriseDB, все ведет к этому.
     
     
  • 2.4, Cobold (??), 12:01, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле мешает, думаете они на этой волне себе цену набивают? В любом случае интерес налицо.
     

  • 1.5, паралельные запросы (?), 13:44, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    EnterpriseDB сидит сверху на бренде постгреса, от них давно нет стоящих патчей, даже коды на исполнение параленых селекты не отдают в постгрес... вобщем богатые станут еще богаче :(
     
     
  • 2.8, Aleksey (??), 15:36, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я помню они замечатальным образом оплачивают работу нескольких разработчиков постгрес. Так что нормально.
     
     
  • 3.10, AlexGor (??), 17:18, 28/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    не просто "оплачивают", а Bruce Momjian и вовсе там работает :)
     

  • 1.15, Аноним (-), 19:45, 30/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)
     
     
  • 2.19, vitek (??), 05:21, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)

    а мне вот больше нужен стэндбай....
    хотя моё личное счастье от этого не зависит.

     
  • 2.21, Vitaly_loki (ok), 13:01, 31/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А использовать список полей в select вместо *, чтоб обеспечить нужный порядок выборки? :)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру