Bye-Bye, Movable Type

No-MT.png Как нам пишут в комментариях, а потом мы и сами читаем:

Q: On http://www.movabletype.jp/documentation/mt5/db/mysql-from-sqlite.html I read: From the Movable Type 5, SQLite and PostgreSQL are no longer supported.
A: Yes, it's true. MT5 will deprecate core support for SQLite and PostgreSQL. But, these databases can still be used with MT if a plugin is written to add support; the Enterprise Pack defines the drivers necessary to use the Oracle database with MT.

Вот и выяснилось, чем придется заниматься на новогодних каникулах, писать тестировать LJ-кросспост для Друпала (оказалось, он уже есть, что же я торможу?)

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

Comments

друпал беее

У меня работает на многих сайтах, каши не просит.

мне показался дико тяжеловесным

Это вы не видели, как себя ведет MT при публикации комментария или записи.

зато как потом под нагрузкой эта публикация себя ведет

Да так же, те же яйца, вид сбоку.
Статика отдается из кэша ФС, неизмененные странички друпала - из его кэша (memcached в моем случае).

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

Не для холливара, а утоления интереса для.
А чем постгре лучше мускула? (в данном применении)

Тем что первый я умею готовить (эта готовка включает накатку моего личного патча, конечно), а от MySQL всегда сплошная изжога.

http://blog.lexa.ru/2008/10/05/vash_mysql___to_esche_g.html

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

Это, понятное дело, мои личные тараканы, но вот Петя Зайцев (Percona), которого я лично спрашивал про свои беды, честно и открыто мне признался, что для счастья нужны MySQL-консультанты, отчего этим консультантам счастье.

Перформанс на запись/апдейты у постгреса повыше, чем у InnoDB, кстати.

> Перформанс на запись/апдейты у постгреса повыше, чем у InnoDB, кстати.

Вот, кстати, вопрос по теме. Есть у меня задача, где примерно 50 процессов время от времени дёргают один мыскуль, изредка апдейтя там табличку-другую. В мыскуль-слоу "медленные" запросы уже искоренил, нужные индексы созданы, записей там всего 300-500 тыс в самой большой, в другой около 30 тыс, в соединении больше двух таблиц не участвует. Так вот, хотя запросы в основном там на выборку, а апдейты 1-2 в секунду всего, мыскуль нагружается на 50-60%% цпу (после оптимизации, до оптимизации было 100-150%%) на восьмипроцессорной машине с 20гб рам. Отсюда вопрос, будет ли постгрес чувствовать себя лучше на такой нагрузке? Отношение выборок к апдейтам примерно 50:1.

Да Х.З., надо брать данные, смотреть query plan. Какие записи, какой join.

Даже для обычного джойна (не outer) все же может приходить к пересечению длинных списков, тогда денормализация прописана. В постгресе, кстати, с его массивами, она легче проходит.

> а Х.З., надо брать данные, смотреть query plan. Какие записи, какой join.

Ну ясно, что "хз", мне не точные данные в данном вопросе нужны были, а скорее просто впечатление, будет ли работать соединение пары таблиц на 300к и 30к, когда есть индекс на форин ки и все данные лежат в кеше, быстрее, чем, скажем 0.01 сек. Т.е. в случае, когда у меня оракл, я о таких мелочах даже не думаю, а вот в мыскуле вылезло. Уоптимизировался с индексами, чтобы все фильтры их учитывали и сокращали количество данных для соединения. И теперь думаю, то ли тачка слабая (не так уж), то ли задача мощная (тьфу, в общем-то), то ли надо всё-таки с мыскуля линять на постгрес... Понятно, что только "живым экспериментом" можно выяснить будет ли кардинально лучше или хуже, но как-то пока есть чем другим заняться, кроме дублирования варианты программы под постгрес, особенно учитывая, что их там комплекс и всё поменять нифига не просто...

join - inner или outer? если мы ничего не выбираем, а просто объединяем две таблицы, сколько строк в результате, 300к, 50к или "15 милиардов"?

(и, настаиваю, постгрес надо уметь готовить, его версионность быстро ведет к распуханию данных на диске, даже если в базе две записи. В 8.4 вроде легче, но вакуум все-равно нужен)

> join - inner

Да, inner, иначе я бы уточнил. Там большинство запросов с order by и limit 1 -- выбирается всего одна запись в итоге, в результате соединения и выбора по условию всего около 30к записей, что их там сортировать? Т.е. explain plan я смотрел, запросы престраивал так, чтобы не фулл скан был. И я не сказал, что постгрес чем-то плох, я просто обдумываю, имеет ли смысл даже пробовать. Я умею готовить оракл, немного понимаю в мыскуле, но постгрес до 8й версии меня не интересовал вообще, пока он не умел быстро работать. Сейчас он, говорят, уже на уровне. Вот мне интересно на каком реально.

У меня, кстати, подобная проблема возникла. Делал один проект, внутри вся база на постгресе. К проекту надо прикрутить форум, взяли IPB, как все рекомендовали. А он только мыскуль умеет (мсскл не считается), а постгрес никак. Задали разработчикам вопрос, в ответ получили: "ну что вам жалко что ли, ставьте мыскуль". Так и сидят две дбмс рядом в итоге. И аккаунты не синхронизированы между сайтом и форумом из-за этого, и время, отведённое на этот проект, у меня уже закончилось.

А зачем вообще смотреть на 5-ку, если 4-я версия Movable Type стабильна, работает со всем необходимым и в ней всё есть?

Алексей, как я понимаю, у вас стандартные шаблоны, в которых дофига включаемых модулей? Если так, то тормоза при публикации вполне понятны. Могу рассказать, как мне удаётся снижать нагрузку при публикации в 10+ раз.

А зачем вообще смотреть на 5-ку, если 4-я версия Movable Type стабильна, работает со всем необходимым и в ней всё есть?

Четверка меня в-общем не устраивает (Друпальские сайты сильно удобнее для меня во многих смыслах). Была надежда на улучшения в пятерке, что в сочетании с надеждой на безгеморойный переезд.

Шаблоны - не стандартные.

Как ускорить в 10 раз - ну напишите текст. А то:
http://saahov.ru/s/mt-ftsearch.cgi?search=%D1%81%D0%BA%D0%BE%D1%80%D0%BE...
Ничего не найдено....

Исправил ссылку в шаблоне, спасибо.
Вот правильная ссылка для этого запроса:
http://movable-type.ru/s/ftsearch?search=%D1%81%D0%BA%D0%BE%D1%80%D0%BE%...

Ok, напишу статью в Wiki, а потом сюда скину ссылку :)

Вот, написал :)
http://movable-type.ru/wiki/Оптимизация_публикации

Ну вот да, архивы (по месяцам, по дням, по рубрикам) - в отложенную публикацию. Вот посмотрим, сколько будет этот комментарий публиковаться.

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

Посмотрел. По ощущениям - быстрее не стало. В жопу.

Проверим ))

А вообще, если нужна скорость, то можно посты сделать динамическими, тогда вообще мгновенно всё будет.

А для динамики все еще нужна PHP-версия плагинов?

Да, нужна. Но только, если теги плагинов будут задействованы в шаблонах.

А movabletype уже переехал на что-то другое? :) Потому что при попытке поискать на их сайте mysql оно падает:
http://www.movabletype.com/cgi-bin/mt/mt-search.cgi?search=mysql&Include...

Movable Type
An error occurred
The search you conducted has timed out. Please simplify your query and try again.

Аналогично по-Японски (http://www.movabletype.jp/cgi-bin/mt4/mt-search.cgi?search=mysql&Templat... )

Куда уж проще запрос :)

Как раз сегодня с шефом говорил на эту тему. У Pg просто "сдувается" комьюнити.
Наша компания была самым крупным пользователем Pg, наверное, в разы больше, чем все другие.
Крупный клиент - крупные задачи, большие запросы. Вот как раз по запросам нашей компании разработчики Pg срочно фиксили баги прямо в самолёте (реальный случай!), делали новый функционал, разрабатывали фичи. Много.
Были даже большие переговоры с Фуджитсу по поводу того, чтобы разработчики Pg сделали active-to-active репликацию. Естественно, за немалые деньги.
Словом, за годы работы нашей компании с Pg комьюнити, скажем так, была направляема, если так можно выразиться :) Более или менее, но конкретные задачи, конкретные направления и конкретные баги были всегда.
А потом было решено, что в долгосрочной перспективе поддержки со стороны Pg... Ну, как любая опенсорса - никакая, в общем-то. Никаких гарантий.
Словом, отказались от этой идеи. И сейчас в процессе очень активного перехода на MS SQL Server 2008.
Быть может - это всё следствия...

Дело же житейское.
Ну весь мир живет на Linux-Apache-MySQL-PHP
А отдельные островки - на FreeBSD-Nginx-Postgresql-Perl - и ничего.

Это, конечно, хождение на грани, да и по перлу - кадровый голод пожестче, чем с PHP, но уже лет 10 так ходим.

Конечно, на использование PostgreSQL вокруг меня повлияло наличие "неподалеку" Олега Бартунова и Федора Сигаева, в частности их игры с GiST начались в Рамблере, под рамблеровские же задачи, отчего проникновение всех этих штучек в ближней округе - гораздо выше, чем в-среднем по палате.

> А отдельные островки - на FreeBSD-Nginx-Postgresql-Perl

У меня Linux-Apache-MySQL-*Perl* в основном :)

30k записей - немного, опять же на сервере с 20Gb мозгов все скорее всего будет в памяти. Но пробовать надо.
Я правильно понял, что запрос вроде такого:
select a.a1,b.b2 from a join b using (id) where b.b2... and a.a2... order by limit ?

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

Это был ответ на этот комментарий: http://blog.lexa.ru/2009/11/17/bye_bye_movable_type.html#comment-10037

Промахнулся мимо reply спросонья.

> Я правильно понял, что запрос вроде такого...

Да. Очень похоже. Я так сильно подозреваю, что дело ещё и в том, что периодически обе таблицы обновляются, поэтому мыскуль просто не может закешировать результат. На оракле в 10мс оно уложилось бы и с миллионами записей, а тут я прямо в задумчивости. Мыскульпефомансблог уже читал, настраивал, запросы соптимизировал так, что скрипт стал меньше нагружать отдельными запросами мыскуль, но при этом стал выполнять больше работы, т.е. общая разница раз в 8, но этого маловато.

Вообще, если Oracle сильно быстрее, то хотелось бы понять за счет чего, чудес то не бывает, индексы примерно одинаково у всех устроены.
Хотя, наверное, если памяти на все хватает, то оракл с ней может разумнее обойтись.

Ну весь мир живет на Linux-Apache-MySQL-PHP
А отдельные островки - на FreeBSD-Nginx-Postgresql-Perl - и ничего.

Я думаю, что nginx'а в первой группе будет сильно побольше.

А вордпресс тебя именно mqsql-ом не устраивает, или еще чем?
И второй вопрос -- а комменты из жж будешь доставать? Тут же у тебя вроде работает.

Ну, mysql-ем тоже. В свое время, три года назад, это была причина WP не рассматривать, с тех пор я про него ничего нового не узнал.

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

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

Везет. А я тут попробовать решил этот WP. Ну вообще работает, хотя в плане связки с ЖЖ все как-то не очень. Т.е. туда попадает, а вот с комментариями оттуда все фигово. Импортилка есть, но работает кривовато -- надо допиливать, видимо. Но у нее и логика мне непонятная -- пишет импортированные записи с свои таблицы и потом они как-то паровозиком цепляются на выводе к записям из таблиц самого ВП. И ID им какие-то левые ставит при этом, вообщем так-сяк как-то. Почему не сразу в таблицы ВП не знаю, но может и нельзя...

А у тебя комментарии туда-обратно ходют, или только все тут собираются, т.е. оттуда сюда -- да, а вот отсюда туда -- нет?

Про урлы только что узнал, курил mod_rewrite, кое-как выкурил нужное количество. Ужас. :) Но вроде работает.

Ну моя импортилка работает примерно так же - заводит таблицы мэппинга между юзерами ЖЖ и локальными (в MT все кто комментировал - получают юзерскую запись). С комментами точно есть такой же мэппинг (чтобы новые отличать от уже известных), а вот храню ли я сами - не помню (может быть и да).

И ходит все в одну сторону, сюда. Я уперся в то, что постить комментарий от чужого имени не могу (что естественно для ЖЖ) и наплевал. Вот сейчас, когда писал, понял, что можно постить от имени OpenID-идентификатора на моем же блоге (типа blog.lexa.ru/authors/Анонимус) и сам же и разрешать такое. Но для MT такого делать уже не буду. Для друпала - может быть (переезду быть).

Обосраться. Какой крутой чел. Знает что такое PgSQL... Это все равно, что говорить будто я был езжу на определенной марке автомобиля только потому что у него крепление двигателя осуществляется с gомощью болта m34/12 а с переходом на крепление pnh14/88 все теряет смысл. Фимоз верхней жопы одним словом

Не, ну зачем все сводить к болтам.

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

Вот и тут та же хрень.

во первых почему тот кто не хочет поддерживать базу данных, которая вам нравиться урод?! второе написали ясно, что будет поддержка в плагинах, думаю энтузиасты найдутся. Как вобще разработчиков опенсорс софта можно называть уродами? читая ваш пост решил, что это вы урод и балабол. случайно наткнулся на этот пост, если вы называете уродами всех через одного, можете на этот пост даже не отвечать.

Как вобще разработчиков опенсорс софта можно называть уродами?

Да вы на Столлмана посмотрите!

читая ваш пост решил, что это вы урод и балабол

Вот и поговорили

>> Вот и поговорили

странно вас обижают такие высказывания в ваш адрес, почему тогда других так называете? Может у ребят просто ушел разработчик, который отвечал за поддержку Postgresql? Советую вам разобраться в данной ситуации. Блог вроде серьезный такие посты вам не идут. Если вы такой ярый сторонник PostgreSQL напишите свой плагин для работы с этой субд.

>> Support for SQLite or PostgreSQL database drivers has been deprecated in MT5, however the plugin architecture allows for database drivers to be created to support these databases.

Миграция очень простая:

http://www.movabletype.org/documentation/mt5/database/migrate-sqlite-pos...

Да не обижает меня ничего, но разговор надо же поддержать?

А миграция, да, оказалась не очень сложной: http://blog.lexa.ru/programmirovanie/web/drupal

Add new comment