Компания EnterpriseDB, выпускающая коммерческую версию свободной базы данных Postgres, объявила (http://www.reuters.com/article/pressRelease/idUS129327+27-Oc...) о заключении партнерских отношений с мировым лидером в области Linux решений – Red Hat. Последняя намеревается инвестировать в EnterpriseDB значительные средства с целью еще глубже внедрить открытые технологии в IT инфраструктуру современных корпораций.«Совершенно очевидно, что EnterpriseDB – это ведущий разработчик Postgres для крупных предприятий. Вот почему Red Hat решил сотрудничать с этой компанией» - заявил президент Red Hat Jim Whitehurst. Помимо передовых позиций в области предоставления SQL решений, EnterpriseDB имеет сходную с Red Hat модель работы с клиентами, когда необходимые услуги предоставляются в соответствии с оформленной подпиской. Это также должно способствовать сближению взглядов двух крупнейших вендоров на совместную работу.
Основное направление деятельности Ente...
URL: http://lwn.net/Articles/358911/rss
Новость: http://www.opennet.me/opennews/art.shtml?num=24004
Это ответ Ораклу на попытку отделиться и создать собственный дистр.
> Это ответ Ораклу на попытку отделиться и создать собственный дистру оракла уже который год "свой" дистр, примерно со времен RHEL 4.5
мысли:
1) Шум оракл-mysql инспирирован ораклом, чтобы придать mysql хоть какую-то ценность в скв
2) считаю redhat в целом достаточно умными, чтобы они купили такое Г, как mysql
забавно, кто-бы и что-бы не писал, а мускуль по-прежнему основная субд для веб.
и вот таких проектов:
>Компания Amazon в рамках нового сервиса Amazon RDS начала предоставление в аренду облачных окружений с MySQL 5.1 (используется хранилище InnoDB).http://www.opennet.me/opennews/art.shtml?num=24000
что-то не видно и не слышно ни на оракле, ни на постгискл...зы:
хм... мускуль - субд одного уровня с мсскл, сайбэйз, информикс и т.д.
но добится вразумительных комментов, почему же оно г... - не представляется возможным.
>хм... мускуль - субд одного уровня с мсскл, сайбэйз, информикс и т.д.
>но добится вразумительных комментов, почему же оно г... - не представляется
>возможным.На вскидку:
InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.
Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеет
PS: по мне, так для веба в любом случае нужны дополнительные звенья в архитектуре хранения данных. Нужно активно использовать кеширование (memcache) либо специфичные для задачи решения (например часть данных хранить в tokyo tyrant или memcachedb)
>InnoDB слишком долго модифицирует большие таблицы (механизм копирования во временную таблицу). В постгресе проблемы нет.а зачем её модифицировать?
>Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.и тем не менее, запросы в мускуле выполняются быстрее. :-D
не говоря уж о требуемых ресурсах.
>Скорость работы Mysql'я на простых операциях (и под нагрузкой) не намного (или совсем не) выше чем в современном постгресе. Сложные mysql выполнять просто не умеетсмотря как настроить... в подавляющем большинстве случаев мускуль быстрее... и меньше жрёт. про амазон выше ссылку давал - один (а по-всему видать - решающий) повод в выборе именно мускуля.
зы:
видывал (и к сожалению очень часто) я такое г..., сделанное и на постргри, и на оракле, и т.д. ..... как правило перцами, кричащими, что что-то там г..., а что-то там круть.
но также видел и на мускуле практически гениальные решения.
> а зачем её модифицировать?проект растет и развивается => меняются задачи => меняется структура БД
>>Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.
>и тем не менее, запросы в мускуле выполняются быстрее. :-D не говоря уж о требуемых ресурсах.как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.
PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта?
>проект растет и развивается => меняются задачи => меняется структура БДв любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.
как следствие - в большинстве случаев данные строки должны находится рядом, а не по всему рэйду тонким слоем... а если нет, то можно и доп. таблице подумать (master - detail). или просто построить новую (что чаще всего и происходит)
>как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.почему странный? никакой план выполнения не заменит здравый смысл... и факты.
мускуль занял место основной субд для инета по-праву. аргументы я уже приводил. не вижу смысла повторяться.
ах, да.
>алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.и что? проектируйте б/д и пишите запросы правильно.
да и хинты даже в оракле никто не отменял.
и никаких хаков!!!:-D
>PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта?не скромный вопрос, но.... dba, системный архитектор, начальник ит. как-то так.
> в любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.с таким подходом рынок интернет-сервисов еще в каменном веке бы был. сейчас решает скорость внедрения новых фич, гибкость. Так что это вполне нормально - добавлять поля в таблицу не проводя особо никаких расчетов (конечно, в определенных условиях). Если все это делать - уйдет слишком много времени и денег (которых скоро просто не останется, т.к. конкуренты обойдут) Именно поэтому так же существуют ORM и web-фреймворки (Django, RoR, ...)
Кстати, вот что-то более менее вменяемое нашел их бенчмарков mysql vs. postgres: http://www.randombugs.com/linux/mysql-postgresql-benchmarks....
И примеры крупных интернет-проектов на постгресе по памяти: skype, myyearbook, .org, .info.
>Так что это вполне нормально - добавлять поля в таблицу не проводя особо никаких расчетов (конечно, в определенных условиях). Если все это делать - уйдет слишком много времени и денег (которых скоро просто не останется, т.к. конкуренты обойдут) Именно поэтому так же существуют ORM и web-фреймворки (Django, RoR, ...)глупости. для профи по времени делать что так, что так - один хрен.
к примеру (напомню, речь идёт о больших таблицах) нужно сделать некий отчёт (с введением новых полей) с приемлемым для заказчика сроком его выполнения...
так вот, сделать сразу правильно как правило если не проще и быстрее, то уж точно не сложнее. про мастер-детэйл - вообще без проигрышный вариант - не надо переделывать существующие приложения... по-крайней мере точно уверен, что ничего не отвалится.
и создание вьюх на их основе - хоть сто порций.
для пачки студентов, которым надо по-быстрому - да. такой подход встречал неоднократно..... но и результат их работы либо долго не живёт, либо существенно переделывается
по-поводу бенчей - в реальной работе приложения критичны ко времени выполнения выборки, инсерты, апдэйты, мерджи, их различные варианты с bulk.... короче dml.
ddl - на продуктивной прерогатива админа (даже не программиста). не скажу, чтобы скорость совсем уж не важна, но...
похоже вы не совсем понимаете темпы и условия в которых делаются веб-стартапы. резултат нужен каждые две-три недели, огромное кол-во мертворожденных идей, крайне низкое время жизни кода, нехватка времени и денег. dba - это вообще непозволительная роскошь.вообще спор ни о чен. попросили привести в чем лажает мускуль - я привел. дальше вы пытаетесь доказать, что это вовсе не проблемы. на самом деле это очень большие проблемы.
кстати, последнее утверждение про ddl/dml только доказывает, что вы не совсем понимаете реалий веб-разработки.
и много у Вас подобных стартапов? и вот это:
>резултат нужен каждые две-три недели, огромное кол-во мертворожденных идей, крайне низкое время жизни кода, нехватка времени и денег.так и будет продолжаться.... неужели я не понятно выразился? времени в любом случае уходит одинаково. а чаще и гораздо меньше.
элементарное планирование - признак более/менее серьёзной конторы.
>dba - это вообще непозволительная роскошь.забавно. и кто же обслуживает Ваших клиентов? кто устанавливает ОС? виртуалуи (если есть)?
веб-сервера? субд? патчит их наконец?
а ведь это нужно даже при виртуальном хостинге.....
>вообще спор ни о чен. попросили привести в чем лажает мускуль - я привел. дальше вы пытаетесь доказать, что это вовсе не проблемы. на самом деле это очень большие проблемы.с таким же успехом можно сказать, что Вы привели недостатки постгри и т.д.
(см. Вашу ссылу и обращаем внимание на dml-операции)
а ведь это всё вытекает потом в количество клиентов на одном серваке....
недостатки ddl - проблема админа. недостатки dml - проблема всех.
>кстати, последнее утверждение про ddl/dml только доказывает, что вы не совсем понимаете реалий веб-разработки.ну конечно?!!!!! :-D
если программеру нужно думать не только о dml, а ещё и о ddl, а дальше - куда кривая выведет - это круто! :-DDDDDDDDDDDDDDDDDDDDD
+1. хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDB
>хорошо если RedHat сами купят MySQL у Oracle или EnterpriseDBНу я понимаю они могут купить мускуль у оракла, но у EnterpriseDB как?
Как -как, как обычно!А вот PostgreSQL - да купить невозможно :)
пЫсЫ: Долгих лет процветания слону! Самя Ъ-db :)
Готов сделать денежную ставку за то, что в ближайший год Red Hat купит бизнес EnterpriseDB. Сейчас оптимальной сделке мешает волна поднятая из-за Oracle/MySQL. Но вот когда страсти улягутся, готов поспорить Red Hat купит EnterpriseDB, все ведет к этому.
В смысле мешает, думаете они на этой волне себе цену набивают? В любом случае интерес налицо.
EnterpriseDB сидит сверху на бренде постгреса, от них давно нет стоящих патчей, даже коды на исполнение параленых селекты не отдают в постгрес... вобщем богатые станут еще богаче :(
Насколько я помню они замечатальным образом оплачивают работу нескольких разработчиков постгрес. Так что нормально.
не просто "оплачивают", а Bruce Momjian и вовсе там работает :)
добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)
>добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-)а мне вот больше нужен стэндбай....
хотя моё личное счастье от этого не зависит.
А использовать список полей в select вместо *, чтоб обеспечить нужный порядок выборки? :)