Pull to refresh

Comments 32

Отличная новость, только - блин! Почему 14?
Жаль, но мне жена не простит если я пойду :(
Приходите на 1 час, потом к жене :) моя тоже будет недовольна, но PostgreSQL — это ведь святое!
А имеет смысл идти?
У меня академический интерес: эта субд мне нравится, но опыта работы с ней нет.
В основном - mysql и немного mssql, oracle, sybase.
Просто хочу присмотреться к postgresql повнимательней :)
ну в принципе присмотреться за час получится :) но максимальная польза от встречи будет все же у людей, которые уже используют postgresql, потому что общаться с живыми гуру — безумно интересно
Спасибо за ответ :)
UFO just landed and posted this here
Почему опять в Москве?)))
Но новость, тем не менее, очень хорошая.
Движуха это всегда хорошо (относительно сообществ). Надеюсь что-нибудь интересное родится (тьфу-тьфу-тьфу, я не про детей после пьянки!)
Коммьюнити здесь все же более плотное, чем в других регионах, согласитесь. Разработчики PostgreSQL и другие интересные люди под боком, так все и выходит. Но все будут только рады, если подобная инициатива зародится где-то еще.
Понимаю, это так, лёгкая зависть :)
А планируется ли где-то выкладывать видео с данной встречи? Людям из регионов было бы полезно.
UFO just landed and posted this here
для всех интересующихся постгресом, в т.ч. и для влюбленных в него :)
UFO just landed and posted this here
это канал про аниме?
Очень много всего слышу про постгре.
Как-то задался целью найти в интернете хороший обзор-сравнение постгре с mysql, но ничего толкового не нашёл.
Если кто-нибудь поделится ссылками на объективные ресурсы, буду очень благодарен и даже плюсик поставлю!
Совсем-совсем объективного сравнения не существует. Хорошие решения можно делать на обоих системах, так что выбор конкретной СУБД — это дело принципов, которые вы выбираете для себя, а не бенчмарков.
Да я понимаю, что работать с СУБД всё равно через адаптер придётся. Ну просто прикольно было бы почитать про те или иные особенности, которые в рамках конкретного проекта могли бы себя проявить.
Хотя с другой стороны, какие блин эти проекты, мы же не строим супер-пупер распределительную-распределённую-меганагруженную систему, в которой каждая доля секунды дорога -)
А для общего развития знать наверняка полезно.
Есть одна особенность, которая рано или поздно проявляет себя во всех проектах, кроме самых маленьких: это чудо фактически невозможно обновлять. Потому что переход с версии x.y на версию x.y+1 требует конвертации базы (с x.y.z на x.y.z+1 не требует - но вы же не собираетесь вечно сидеть на одной и той же версии?) - что занимает немало времени и выпивает кучу урови.

Как происходит переход с одного суперформата на другой в нормальных базах (MySQL, MSSQL, Oracle, etc) ? Ставится новая версия, проверяется работоспособность, через какое-то время таблички по одной перетягиваются с одного формата (без поддержки определённых рюшечек) на другой (поддерживающий оные рюшечки). В случае чего - остановить новую версию и запустить старую, проверенную - дело минуты-двух (пока новые возможности не использованы, конечно). Как происходит переход в PostgreSQL ? Выходит новая версия с турбофичами. Поставить её на существующую базу нельзя в принципе - базу нужно конвертировать. Если база большая - это часы и дни. Если что-то пошло наперекосяк (скажем всё работаете, но какой-нибудь модуль выписки отчётов глючит) - вы не можете вернуться "взад": нужно либо конвертировать базу обратно (снова часы и дни ожиданий), либо в авральном режиме разбираться почему у вас этот компонент отвалился. Причём если раньше вы получали это удовольствие раз в год, то теперь разработчики обещают вам эти чудеса два-три раза в год.

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

P.S. Поразительно упорство с которым разработчики сами себе какают в карман: проблемы с устновкой новых версий изгнали PostgreSQL из куда большего числа проектов чем любые другие вещи. Однако из года в год повторяется одна и та же история...
Забавно-пессимистический у вас взгляд на вещи — видно, по незнанию вы натерпелись много горя от PostgreSQL. Мне очень жаль, но связано это только с вами — видно, документацию вы читать не любите, а тестированием миграции пренебрегаете. Теперь по фактам:

1. Формально, смена major-версии требует дамп-рестора, да. Это единственное, в чем вы правы. В реальности же новую версию СУБД можно поставить даже в старую директорию с данными безо всяких проблем. Совместимость дампов (то есть данных) между версиями PostgreSQL соблюдает максимально строго, не обманывайте аудиторию. Проблемы возникают только с приложениями, которые написаны не прямыми руками, а с большими ошибками (вроде неявных ужасных приведений типов, которые раз в пару лет разработчики PostgreSQL действительно прибивают).
2. В 95% случаев не нужно ничего конвертить. Все будет работать само. Через неделю после выхода 8.2 я переводил на нее с 8.1 1ГБ базу первого российского вебдваноль стартапа :) Заняло это не более 5 минут и геморроем не сопровождалось. На следующей неделе я перевожу на 8.3 2ГБ базу еще одного очень популярного вебдваноля — проблем опять не предвидится: pg_dump|gzip, rpm -Uvh, zcat|psql. Если вы не верите, могу написать публичный отчет о том, как все прошло, если время позволит.
3. Major-версии всегда выпускаются раз в год, а не 3 раза в год, не искажайте информацию.
4. Популярность PostgreSQL после версии 8.0 (в которой появилась поддержка Windows) неуклонно растет, это факт. Так что если какие-то непутевые ДБА изгоняют его из проектов, они представляют собой меньшинство пользователей.
1. Сейчас не вспомню точно, но то ли 8.0, то ли 8.1, с каждым изменением третьей (minor) версии требовал утомительного застирывания выгрузки-восстановления. Настолько интенсивно менялся движок.

2. Отчёт был бы интересен, если хотя бы вкратце были описаны характеристики сервера(ов) и структуры БД. А gzip-то в описанной ситуации лишний оверхед.

3. -> п.1

4. Имхо, дело не в поддержке Windows. Всё-таки PostgreSQL - это действительно enterprise class database. Просто время пришло.
1. Смена minor-версии никогда не требовала ничего такого, вы путаете.

2. Gzip в описанной ситуации не оверхед. Hint: когда дампите большую базу, всегда смотрите, во что упирается сервер: в ЦПУ или в диск. Если большой iowait и есть свободный ЦПУ, значит bottleneck в диске и поджав объем базы гзипом мы повысим скорость дампа, перекинув нагрузку с диска на проц. Если совсем медленный диск, то имеет смысл даже бзипить, так как все равно будете упираться не в процессор, а в IO.
Что касается отчета о миграции, то может вам еще и схему базы данных нарисовать? :) А если серьезно, то это все не способствует пониманию процесса, так как он действительно прост. Схема базы была достаточно серьезной, чтобы использовалось очень много фишек Постгреса, которые улучшались в 8.2, не ломая обратную совместимость. Железо — полностью стандартное: 2 x Xeon, 2 диска в мирроре, 4 ГБ памяти, ничего особенного. Дело-то не в характеристиках серверов и БД совсем, как вы не поймете.
1. Да, каюсь. Спутал с этим. Плюс раздражала необходимость обновляться ежемесячно вплоть до 8.1.4. (отсюда у меня и особенное доверие к x.x.4)

2. Видимо, мне повезло, и мне не доводилось сталкиваться с медленной работой дисковой подсистемы (при дампах). Сейчас специально запустил, понаблюдал в systat - и не увидел даже близко описанных Вами явлений. Правда, винты SCSI в 5м массиве.

А gzip только в случаях периодического резервного копирования, для экономии места.
С PostgreSQL я действительно натерпелся в любительских проектах. И там много бывает разного. Формальное тестирование в проекте, который делается двумя энтузиастами в выходные ? Как вы это себе представляете ?

А если говорить о серъёзных проектах - то тут и говорить не о чем: ну не "enterprise class database" PostgreSQL, даже и близко нет.

Теперь по пунктам.
1. Данные - это данные. Они живут в базе (зачем мне иначе СУБД нужна?) и они должны там жить всегда. Дампы - это средство отладки, не более того.
2. 1Гб, 2Гб ? Это у нас уже enterprise ? Ну да, для каких-то проектов это и ничего так. Но вообще enterprise class database должна тянуть уж по меньшей мере десятки терабайт (лучше сотни). Да, разумеется, тут уже нужен sharding и clustering, но это придётся делать с любой базой - хоть с MySQL, хоть с PostgreSQL, хоть с Oracle. Но upgrade должно происходить без остановки деятельности (ибо минута простоя == несколько тысяч долларов убытка), то есть система должна работать, в частности, и тогда, когда на части машин одна версия, на части - другая и, в случае чего, должна быть возможность отката (ибо всего не предусмотришь).
3. Почитайте что разработчики пишут, потом говорите. Я не говорит что они выпускаются три раза в год. Пока нет. Но что их хотят выпускать два-три раза в год - это точно.
4. Популярность других СУБД тоже ведь растёт, так что надо сравнивать тенденции. Я вот совсем не уверен что количнство проектов, разочаровавшихся в PostgreSQL меньше чем количество проектов, которые на него перешли.

PostgreSQL зажат в очень узкую нишу: проекты, которые могут себе позволить тщательную разработку, отладку и тестирование всего кода, но при этом не нуждающиеся в действительно больших объёмах данных. При этом MySQL можно использовать во всех этих случаях, а также для проектов "Васи Пупкина" и для обработки сотен миллионов и миллиардов транзакций в день. Спрашивается: нафига козе баян ?

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

Терабайты и десятки терабайт в Постгресе успешно хранят, и работают с ними.

По поводу пункта №3: да, некоторые разработчики пытаются сократить время одной итерации. Но тут не всё так просто, и раз уж Вы пишите «почитайте, потом говорите», то рекомендую поглубже копнуть проблему. Тогда поймёте, что во-первых, это далеко не идеальная мысль, во-вторых, 8.3 планировали выпустить в конце осени 2007, но в действительности мы получили ситуацию с большим количеством серьёзных патчей, что в принципе-то неплохо. Основное, что там сейчас обсуждается касательно планов 8.4 — как сделать процесс более предсказуемым, чтобы в условиях больших неопределённостей хоть как-то планировать. И главное: никто не хочет 2-3 раза в год выпускать major-версию, не путайте опять-таки народ! Речь идёт о контрольных точках, которые будут проводиться 2-3 раза и которые позволят лучше понимать, как протекает итерация. Это не выпуск новой версии. Именно под этим и подразумевал Dave Page, предлагая ввести commit fests.

Про «PostgreSQL зажат в очень узкую нишу» даже сказать нечего, видимо, Вы совсем мало читаете, слушаете, узнаёте из этого мира :-)
поправка: в конце весны 2007, а не осени, конечно. То есть опоздание очень большое вышло в итоге.
Гхм, по дате встречи может показаться, что у любителей PostgreSQL проблемы в личной жизни. :)
скорее наоборот :) все налаживают свою личную жизнь в этот день, а у постгресоидов никаких проблем нет, поэтому даже в такой день можно спокойно поговорить о постгресе. а вообще для меня стало откровением, что так много айтишников почитает этот праздник. может еще хабр 14-го числа прикрыть, чтобы все успели свою личную жизнь наладить? :)
супер! за это я тебя и "люблю" !!! ;)
сижу ржу...)
UFO just landed and posted this here
а видео со встречи потом будет??? было бы интересно на rutube куда нибудь выложить?
Only those users with full accounts are able to leave comments. Log in, please.

Articles