Bye-Bye, Movable Type

lexa - 17/Ноя/2009 11:56

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

_tsukasa (not verified) - 17/Ноя/2009 09:13

друпал беее

lexa - 17/Ноя/2009 10:17

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

_tsukasa (not verified) - 17/Ноя/2009 10:21

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

lexa - 17/Ноя/2009 10:33

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

stifff (not verified) - 17/Ноя/2009 11:18

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

lexa - 17/Ноя/2009 11:40

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

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

stifff (not verified) - 17/Ноя/2009 11:21

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

lexa - 17/Ноя/2009 11:36

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

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

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

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

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

polyestr (not verified) - 17/Ноя/2009 18:12

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

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

lexa - 17/Ноя/2009 18:28

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

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

polyestr (not verified) - 17/Ноя/2009 20:53

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

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

lexa - 17/Ноя/2009 21:09

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

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

polyestr (not verified) - 18/Ноя/2009 02:03

> join - inner

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

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

saahov.ru (not verified) - 17/Ноя/2009 15:52

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

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

lexa - 17/Ноя/2009 16:17

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

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

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

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

saahov.ru (not verified) - 17/Ноя/2009 16:50

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

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

saahov.ru (not verified) - 17/Ноя/2009 21:30

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

lexa - 17/Ноя/2009 21:40

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

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

lexa - 17/Ноя/2009 21:43

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

saahov.ru (not verified) - 18/Ноя/2009 13:39

Проверим ))

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

lexa - 18/Ноя/2009 13:44

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

saahov.ru (not verified) - 18/Ноя/2009 16:16

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

bugabuga (not verified) - 17/Ноя/2009 14:49

А 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... )

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

alex (not verified) - 18/Ноя/2009 03:35

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

lexa - 18/Ноя/2009 10:19

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

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

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

polyestr (not verified) - 19/Ноя/2009 01:11

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

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

lexa - 18/Ноя/2009 09:58

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

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

lexa - 18/Ноя/2009 10:03

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

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

polyestr (not verified) - 19/Ноя/2009 01:08

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

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

lexa - 19/Ноя/2009 07:36

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

Konstantin Sorokin (not verified) - 18/Ноя/2009 14:35

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

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

sergeignatkin.ru (not verified) - 28/Ноя/2009 19:55

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

lexa - 28/Ноя/2009 20:08

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

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

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

sergeignatkin.ru (not verified) - 29/Ноя/2009 19:53

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

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

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

lexa - 29/Ноя/2009 20:09

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

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

Anonymous (not verified) - 30/Янв/2010 15:18

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

lexa - 30/Янв/2010 15:23

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

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

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

loa (not verified) - 16/Фев/2010 04:45

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

lexa - 16/Фев/2010 07:31

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

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

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

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

loa (not verified) - 16/Фев/2010 08:41

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

странно вас обижают такие высказывания в ваш адрес, почему тогда других так называете? Может у ребят просто ушел разработчик, который отвечал за поддержку 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...

lexa - 16/Фев/2010 08:46

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

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