а разве нету community edition?

мускулькапец. Теперь постгрес опопсеет.

//дай ссылку на хабр уже, интересно чо в каментах)

Давно пора с мускула сваливать. Есть постгрес для серьезных систем и sqlite для мелких сайтов.

А может вообще стоит начинать смотреть в сторону nosql решений. Всяких там cassandra или hbase.

Что то я думаю оракл угробит и яву тоже. Ну понятно, они хотят бабла. Бизнес.

А может вообще стоит начинать смотреть в сторону nosql решений.

Не стоит. Я считаю, что то, что сейчас модно называть NoSQL, относится к разряду вещей типа «если вы об этом не знаете, то вы в этом не нуждаетесь». В большинстве случаев, для задач, в которых обычно применяются реляционные БД, применять всякие там k-v store и документо-ориентированные БД - никому не нужное извращение.

Нет, попробовать-то можно, конечно, для расширения кругозора, так сказать.

Мыскуль не нужен!

Есть правильный Постгрес.

>Это типа в Классик не входит, но можно скомпилить? Я правильно понял?

Community Edition есть и в бинарном виде.
Более того, Community Edition - это то, чем большинство всегда и пользовалось. Classic Edition - это специальная сборка, которую можно использовать в проприетарщине, раньше её в бесплатном виде вообще не было.

Не стоит. Я считаю, что то, что сейчас модно называть NoSQL, относится к разряду вещей типа «если вы об этом не знаете, то вы в этом не нуждаетесь».

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

В большинстве случаев, для задач, в которых обычно применяются реляционные БД, применять всякие там k-v store и документо-ориентированные БД - никому не нужное извращение.

Блин, ну естественно головой надо думать, прежде чем делать. Я же не предлагаю писать какую-нибудь систему автоматизации бизнес-процесссов (где точно будет куча отчетности со всякими группировками итд.) на nosql.

Ну, в общем, мы с вами друг друга поняли, я считаю. Мой ответ можно свести к вашему «головой надо думать, прежде чем делать», по крайней мере я именно это хотел сказать.

Согласен по всем пунктам.

Черт возьми, почему никто еще не написал nosql нормально? Почему каждое упомнинание об nosql начинается перечислением тонн косяков? Вот sql-и же пишут, и обсуждают у них далеко не косяки..

>Черт возьми, почему никто еще не написал nosql нормально? Почему каждое упомнинание об nosql начинается перечислением тонн косяков?

Наверное потому, что эти решения всего пару лет как начинают выходить в mainstream, в отличии от sql субд, которым уже 20 с хреном лет, и в разработку которых вложено over9k лямов баксов/человекочасов.

Вот sql-и же пишут, и обсуждают у них далеко не косяки..

Да обсуждают их косяки, обсуждают. Поройтесь на sql.ru

А с какими NoSQL-решениями приходилось работать лично вам? И с какими проблемами вы столкнулись в процессе работы?

ты это о каких проблемах nosql? Ты точно понимаешь что это такое?

> Теперь MySQL Classic Edition лишается поддержки InnoDB

Я вам открою небольшой секрет из всех «разработчиков» использующих MySQL:

- 95% никогда не использовали ничего кроме MyISAM;
- 80% - впервые узнали о InnoDB движке, увидев его название в выпадающем списке пыхадмина;
- 50% - прочитали про InnoDB в википедии.
- 5% - использовали InnoDB хотя бы раз.
- 1% использовали «фичи» InnoDB(внешние ключи, каскадное обновление и пр.)
- 0.1% использовали фичи InnoDB образом, не позволяющим тем, кто после них этот софт поддерживал плакать кровавыми слезами.

Отсюда мораль:

1) За точность цифр не ручаюсь, но судя по наблюдениям за кодерами, порядок именно такой.

2) Все, кто осилил работу с внешними ключами, как правило осиливают установку, настройку и администрирование постгреса.

3) MySQL-капец стал ближе на 1%, не более.

ну и хорошо,

use MariaDB , Luke, там все останется )

Странно. Формально ваш ответ, в общем-то, похож на правду. Хотя и правда эта заключается в том, что вам, по-видимому, не приходилось общаться с хорошими разработчиками/DBA.

С другой стороны, перечисляя т.наз. «фичи» innodb, вы сказали про внешние ключи и каскадное удаление/обновление - по большому счету, не такие уж и важные, надо сказать, фичи - при наличии головы на плечах этот функционал можно относительно легко реализовать на уровне приложения. Хотя да, внешние ключи на уровне БД и правда хороши, хоть и реализованы они в mysql просто отвратительно.

Вы почему-то забыли упомянуть о действительно важных фичах innodb, которые делают применение этого движка вместо MyISAM практически однозначным выбором. Я говорю, конечно, о транзакциях (в первую очередь), row-level локах и crash tolerance / crash recovery.

К чему бы это?

> дай ссылку на хабр уже, интересно чо в каментах)
ссылка ведёт на сайт маскуля

[qoute] ну и хорошо,

use MariaDB , Luke, там все останется )

Ну Постгрес же! ЗАчем это всё надо, когда есть такая великолепная СУБД?

> Я вам открою небольшой секрет из всех «разработчиков» использующих MySQL
Откуда дровишки?
Что-то не верится в правдоподобность статистики.

> Странно. Формально ваш ответ, в общем-то, похож на правду. Хотя и правда эта заключается в том, что вам, по-видимому, не приходилось общаться с хорошими разработчиками/DBA.

Думаете, процент «хороших разработчиков» выше цифры в последнем пункте?

Вы почему-то забыли упомянуть о действительно важных фичах innodb, которые делают применение этого движка вместо MyISAM практически однозначным выбором. Я говорю, конечно, о транзакциях (в первую очередь), row-level локах и crash tolerance / crash recovery.

К чему бы это?

К тому, что в InnoDB это не фичи, а костыли. Ибо локи, транзакции и прочее вкусное, учитывая блокировочную сущность мускуля, реализованы просто феерично.

ну не всё пока поддерживает postgresql, хотя разработчикам некоторых проектов стоит подумать, а стоит ли им и дальше поддерживать такую субд в качестве единственной

> Откуда дровишки?

С популярных форумов, вроде sql.ru

Что-то не верится в правдоподобность статистики.

Ну я как бы готов отстаивать порядок цифр, а не проценты погрешности, но общая картина для InnoDB именно такая и она довольно безрадостна.

> Думаете, процент «хороших разработчиков» выше цифры в последнем пункте?

Знаете, хотелось бы на это надеяться, правда. Впрочем, скорее всего, вы тут все-таки правы.

К тому, что в InnoDB это не фичи, а костыли. Ибо локи, транзакции и прочее вкусное, учитывая блокировочную сущность мускуля, реализованы просто феерично.

Собственно, с проблемами реализации определенных фич в mysql я спорить не буду. Тут другой вопрос - реальность такова, что приходится выбирать из двух зол. Что лучше - действительно морально устаревшая технология, которая была актуальна, насколько я понимаю, лет так двадцать назад, и которая не реализует самых, что ни на есть, базовых функций БД (да, я говорю о MyISAM) или движок, имеющий эти самые функции, пусть и реализация их .. ээ, весьма интересна?

вот именно...)

> которая не реализует самых, что ни на есть, базовых функций БД (да, я говорю о MyISAM)
ЕМНИП в InnoDB отсутствует фултекст индекс. Ты наверное не прав

Если это все ваши аргументы, то я, все-таки, прав.

Очевидно, что fulltext-индексы не относятся к «базовым» функциям БД, тогда как ACID-совместимость, предоставляемая innodb (хоть и кривовато), безусловно, относится.

Это даже не учитывая того, что fulltext индексы:

• нужны очень и очень редко. Скорее всего, если вы используете fulltext индексы, вам не помешало бы пересмотреть вашу модель данных.
• в mysql реализованы не просто плохо, а прямо-таки ужасно, - намного хуже чем те же транзакции и, пардон, внешние ключи. Вместо них даже официальные источники рекомендуют использовать сторонние средства.

> нужны очень и очень редко. Скорее всего, если вы используете fulltext индексы, вам не помешало бы пересмотреть вашу модель данных.
fulltext понадобился в самой простой задаче. Точно не помню что там было, но напишу, когда узнаю

суровый оскал GPL

Теперь MySQL Classic Edition лишается поддержки InnoDB, а в след за ним внешних ключей, транзакций и прочих плюшек. Теперь поддержка данных приятностей будет стоить от 2000$ в год и доступна с версии MySQL Standard Edition.

ну вот и приехали. следующий этап - это просто невозможность скомпилять всё это вместе из-за какого то кода который Oracle просто не отдаст.

Я вам открою небольшой секрет из всех «разработчиков» использующих MySQL:

а теперь будем видеть регресии в коде myisam и она станет unsupported а потом вообще исключена из кода как устаревшая.

Как мне кажется, MySQL изначально был какой-то не такой.

У него не было LGPL лицензий на библиотеки для подключения (ну никак - ни родной, ни jdbc). То есть для использования в коммерческом софте надо покупать лицензию. Использовать в LGPL софте нельзя. Было даже лицензионное сражение MySQL против стэка LAMP, закончившееся добавлением специального исключения в лицензию явного разрешения линковать MySQL c PHP.

Требовалось покупать лицензии в случае установки на компьютеры, поставляемые пользователям. Ну и так далее.

В конечном счете я для себя решил - мне с MySQL не по пути.

Из альтернатив имеется postgresql, имеется большое количество коммерческих баз данных с внятными ценами на годовую поддержку, имеются NoSQL базы. Одним словом, есть из чего выбрать.

> Что то я думаю оракл угробит и яву тоже. Ну понятно, они хотят бабла. Бизнес.

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

Соглашусь. Мускуль стал громоздким.

Ну они могут перестать ее развивать, выпускать новые версии и оно само сдохнет. Про openjdk в курсе.

Одно сообщение тут было правильное, но на него никто внимания не обратил...
MySQL Standard Edition - это коммерческий продукт.

Под GPL распространяется MySQL Community Server. Про него _не_ написано. Вроде...

> Ну они могут перестать ее развивать, выпускать новые версии и оно само сдохнет. Про openjdk в курсе.

А зачем?)

пока что написано что Community Edition ( которая как раз в дистрибутивах )
включает InnoDB и про планы выкинуть это оттуда пока не говорилось

>Есть постгрес для серьезных систем

Только мало кто осиливает его настройку и оптимизацию :)

>- 1% использовали «фичи» InnoDB(внешние ключи, каскадное обновление и пр.)

Чёрт! Да я крут! :)

> Чёрт! Да я крут! :)

Ты-то? Ну есть малость.

Большинство из встреченных мною лично или заочно объясняли свой выбор InnoDB примерно так: «ну это же более прогрессивный движок». Чем именно - отвечал каждый 2-й. И каждый 5-й реально юзал эту его «прогрессивность».

Только мало кто осиливает его настройку и оптимизацию :)

Для тех задач где используется мускуль в 90% случаев, не нужно никакой настройки и оптимизации. До ста запросов в секунду на базе в сотню мегов постгрес и на дефолтных настройках замечательно пашет.

Ну разве-что индексы надо построить по тем полям, по которым поик ведется.

>«ну это же более прогрессивный движок»

Это мнение проходит сразу после того, как попытаешься загрузить в него дамп хотя бы на 4-5Гбайт :) - http://www.linux.org.ru/forum/talks/4350880 (кстати, хотя это и сравнение тёплого с мягким, но всё равно, на той же задаче - http://www.linux.org.ru/jump-message.jsp?msgid=5139765&cid=5151943 или http://www.linux.org.ru/jump-message.jsp?msgid=5111473&cid=5131669)

>До ста запросов в секунду на базе в сотню мегов постгрес и на дефолтных настройках замечательно пашет.

А мне нужно несколько тысяч запросов в секунду на базе в три миллиона записей и 6Гб. MySQL на такое оптимизируется автоматическими скриптами (и работает). А вот с Postgre придётся долго и уныло копаться. При чём, судя по традиционной грызне вокруг любых результатов тестов, оптимизация Postgre - это задача, которая под силу очень и очень немногим монстрам :)

3 миллиона записей, 6 гигабайт объем данных... При таких объемах индексы могут вечно в памяти тусоваться. Тормозить-то особо и нечему.

>Тормозить-то особо и нечему.

Вот и я удивляюсь, чего это у народа ненастроенный Postgre тормозит на куда более примитивных тестах :)

...

Вот когда под Postgre будут оптимизаторы уровня tuning-primer или mysqltuner.pl - тогда я рискну его попробовать. А так - увы :) С дефолтовыми параметрами это что-то ужасное, а что и куда крутить для увеличения производительности - непонятно...

А мне нужно несколько тысяч запросов в секунду на базе в три миллиона записей и 6Гб. MySQL на такое оптимизируется автоматическими скриптами (и работает). А вот с Postgre придётся долго и уныло копаться.

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

При чём, судя по традиционной грызне вокруг любых результатов тестов, оптимизация Postgre - это задача, которая под силу очень и очень немногим монстрам :)

Постгря тюнится гораздо проще mssql, не говоря уж про oracle. За день-два вполне можно осилить настройки, как я уже писал выше, главное теорию знать. Ну а после разница в скорости настройки в сравнении с мускулем будет довольно незначительной.

>За день-два вполне можно осилить настройки, как я уже писал выше, главное теорию знать.

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

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

Да набирает он популярность, набирает. Просто в проектах немного другой области, нежели простенький веб. Я тут как-раз работу искал не так давно, так процентов 30 проектов - именно постгря. Еще 40% оракел. А остальное размазано между мусклем и мссклем + есть еще почти исчезающе малая доля db2 и nosql. Но область к web имеющая отношение очень опосредованное. Всякие учетки, платежные системы, биллинги и остальные звери b2b зоопарка.

>Да набирает он популярность, набирает.

http://www.google.com/trends?q=postgresql :)

Просто в проектах немного другой области, нежели простенький веб.

Но мы тут, как раз, про контекст простенького веба и говорим.

...

Кстати, решил сам сейчас побенчить Постгре на реальных данных (те пресловутые 5Гб) - никак не подберу никакой конвертер, чтобы mysql dump в postgre конвертнуть :-/

>Но мы тут, как раз, про контекст простенького веба и говорим.

Эммм. По-моему мы говорим про базы данных вообще. И область их применения простым вебом далеко не ограничивается.

Кстати, решил сам сейчас побенчить Постгре на реальных данных (те пресловутые 5Гб) - никак не подберу никакой конвертер, чтобы mysql dump в postgre конвертнуть :-/

Поройся на enterprisedb.com у них вроде был какой-то migration tool. По крайней мере я точно помню что когда ставил под винду постгрю, их stack builder предлагал его поставить.