В этот раз рано оповестить заинтересованную общественность не получилось, к сожалению. В Москве обязательно будут еще встречи, следите за новостями в этом блоге.
Москалюк, кстати, на РИТе в личном разговоре небезосновательно жаловался на memcached. Все эти 805 серверов у Фейсбука работают на старом memcached и есть планы вообще от него отказаться. После ухода Фитцпатрика коммьюнити мемкеша ну совсем никакое, а сам Фейсбук вопреки заявлениям в презентациях нормально его не развивает.
обычно оставляю дисконтные карты в таких устройствах, пару раз даже забывал ненужные при чекауте :) а еще смешно, что cleaning ladies обычно когда приходят убираться и видят включенное эл-во с ненастоящей карточкой, воткнутой в устройство, всё выключают и аккуратно кладут карточку на столик рядом с кроватью мне всегда было интересно, что они при этом думают :)
В связи с этим возникают следующие вопросы: кто же из российских социальных сетей первым войдет в Social Graph? У кого есть нормальная реализация FOAF (ЖЖ не предлагать)? Где пользователям предлагается выбор, открыть свою страницу и друзей или нет?
Это не экзотический аналог, это вполне разумное средство, с учетом простоты, открытости библиотек и т.п. Настоящим гикам фенечки-рюшечки не нужны :) Я использую OpenSSL и des3 в нем чего и всем советую. VIM совершенно необязателен. Навигация по списку из 100 паролей осуществляется поиском. С мобильного если приспичит можно зайти по ssh на машину с паролями и расшифровать их. Только непонятно, зачем оно нужно: ведь если у айтишника рядом нет лаптопа, значит он в глубоком отдыхе и пароли ему не нужны :)
1. Смена minor-версии никогда не требовала ничего такого, вы путаете.
2. Gzip в описанной ситуации не оверхед. Hint: когда дампите большую базу, всегда смотрите, во что упирается сервер: в ЦПУ или в диск. Если большой iowait и есть свободный ЦПУ, значит bottleneck в диске и поджав объем базы гзипом мы повысим скорость дампа, перекинув нагрузку с диска на проц. Если совсем медленный диск, то имеет смысл даже бзипить, так как все равно будете упираться не в процессор, а в IO.
Что касается отчета о миграции, то может вам еще и схему базы данных нарисовать? :) А если серьезно, то это все не способствует пониманию процесса, так как он действительно прост. Схема базы была достаточно серьезной, чтобы использовалось очень много фишек Постгреса, которые улучшались в 8.2, не ломая обратную совместимость. Железо полностью стандартное: 2 x Xeon, 2 диска в мирроре, 4 ГБ памяти, ничего особенного. Дело-то не в характеристиках серверов и БД совсем, как вы не поймете.
скорее наоборот :) все налаживают свою личную жизнь в этот день, а у постгресоидов никаких проблем нет, поэтому даже в такой день можно спокойно поговорить о постгресе. а вообще для меня стало откровением, что так много айтишников почитает этот праздник. может еще хабр 14-го числа прикрыть, чтобы все успели свою личную жизнь наладить? :)
Забавно-пессимистический у вас взгляд на вещи видно, по незнанию вы натерпелись много горя от 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) неуклонно растет, это факт. Так что если какие-то непутевые ДБА изгоняют его из проектов, они представляют собой меньшинство пользователей.
Совсем-совсем объективного сравнения не существует. Хорошие решения можно делать на обоих системах, так что выбор конкретной СУБД это дело принципов, которые вы выбираете для себя, а не бенчмарков.
ну в принципе присмотреться за час получится :) но максимальная польза от встречи будет все же у людей, которые уже используют postgresql, потому что общаться с живыми гуру безумно интересно
Коммьюнити здесь все же более плотное, чем в других регионах, согласитесь. Разработчики PostgreSQL и другие интересные люди под боком, так все и выходит. Но все будут только рады, если подобная инициатива зародится где-то еще.
Причины: миф о легкости и лучшей производительности MySQL, за которой стоит коммерческая компания с ее рекламными бюджетами, способствует тому, что новички с их нетребовательными приложениями на нее подсаживаются, не подозревая о том, что есть лучшая альтернатива. Вот и юзают 80% малоопытных пользователей MySQL, создавая много шума по этому поводу. Оно может для них и лучше, спорить не буду, но если вы считаете, что попадаете в 20% более продвинутых, то по крайней мере необходимо осознавать, что к чему в мире СУБД. Впрочем, и для новичков, изучающих SQL, лучше начинать не с диалекта MySQL и не ACID-совместимого продукта, а с гораздо более стандартного и ACID-совместимого PostgreSQL.
да, конечно, вы правы.
полно вполне нормальных ситуаций, когда даже и транзакции-то не нужны: например каунтеры li.ru работают на MySQL, потому что ценности в информации об одном из сотен миллионов кликов в сутки нет никакой. но если нужна mission critical запись в БД, с MySQL не все так радужно по общему мнению.
На чем должна быть написана CMS? Сходу назову не CMS, но тоже "движки" на постгресе: MediaWiki (см. wikipedia.org), Serendipity (blog engine), CakePHP (CMF)
В рунете всего этого очень мало пока.
2. Gzip в описанной ситуации не оверхед. Hint: когда дампите большую базу, всегда смотрите, во что упирается сервер: в ЦПУ или в диск. Если большой iowait и есть свободный ЦПУ, значит bottleneck в диске и поджав объем базы гзипом мы повысим скорость дампа, перекинув нагрузку с диска на проц. Если совсем медленный диск, то имеет смысл даже бзипить, так как все равно будете упираться не в процессор, а в IO.
Что касается отчета о миграции, то может вам еще и схему базы данных нарисовать? :) А если серьезно, то это все не способствует пониманию процесса, так как он действительно прост. Схема базы была достаточно серьезной, чтобы использовалось очень много фишек Постгреса, которые улучшались в 8.2, не ломая обратную совместимость. Железо полностью стандартное: 2 x Xeon, 2 диска в мирроре, 4 ГБ памяти, ничего особенного. Дело-то не в характеристиках серверов и БД совсем, как вы не поймете.
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) неуклонно растет, это факт. Так что если какие-то непутевые ДБА изгоняют его из проектов, они представляют собой меньшинство пользователей.
полно вполне нормальных ситуаций, когда даже и транзакции-то не нужны: например каунтеры li.ru работают на MySQL, потому что ценности в информации об одном из сотен миллионов кликов в сутки нет никакой. но если нужна mission critical запись в БД, с MySQL не все так радужно по общему мнению.