11 октября 2008 в 10:21
Хочется надеяться, что для читателей этого сайта мой опыт будет полезен. Я осилил перенос живого сайта с MySQL на PostgreSQL, что и задокументировал:
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
вай, какие люди на drupal.ru
В закладки. Переход на Postgre висит в задачах. Другой вопрос что с использованием Zend_Db, которая генерит код и работе по спецификациям с SQL - вопрос ребром стоять не будет. но в друпал это важно.
У друпал единственная заморочка - модули пишут под MySQL. Да что там. Сам грешен - если надо быстро - и не заморачиваюсь.
респект
вот если бы на оракл, был бы респект
ну так перепеши
постгре с ораклом схожи.
Спасибо!
А есть увеличение производительности?
По сравнению с MySQL/InnoDB - на "вставке" ускорение раза в полтора (при этом InnoDB давался размер кэша
больший чем размер базы, а других настроек я не знаю). Тестировал заливая 5000 текстов через BlogAPI
(кроме того, на этом тесте один раз MySQL просто встал колом и ни на что не реагировал более).
На чтение - есть изрядное замедление если долбиться по небольшому количеству страниц. Понятно с чем
связано - у постгреса нету query cache и все запросы честно исполняются.
Лечится понятно как - нужно кэшировать не в базе, а в memcached, правда CacheRouter текущей версии (беты)
просто не работает (руки не дошли посмотреть пока), а у предыдущего тоже не все хорошо
Интересный опыт. Друпал чуть ли не с самого начала разработки декларирует совместимость с PostgreSQL, но в реальности при работе модулей не из стандартной поставки нередко вылезают грабли. Мейби некоторая популяризация постгреса в друпаловской среде заставит разработчиков тестировать модули под постгрес также. Хотя наверно полностью избежать проблем можно будет если только убрать SQL из кода модулей, а генерировать его исключительно в ядре друпала.
Ну а как их заставишь? Чувак, который CommentSubscribe, честно пишет - я не в теме, чинить не буду ибо не умею. Ну я ему починил (кроме того, у него была там еще бага в процессе инсталляции, ее тоже починил).
Чудес не бывает - в сложных случаях эффективного кода не получится.
Стоит заметить, что из довольно большого количества моих патчей к друпалу, один тихо всосался в 6.5 (хоть бы реквест закрыли), а вообще я какой-то реакции не вижу. Очень странное дело - такая групповая разработка.
минус дру в этом, начало по поддержке других бд есть, но на этом история закончилась, остался только мускул
Весьма полезная статья, ну хоть кто-то еще озадачивается postgres! Еще бы статеек по настройке postgres...
У самого вертится пока 2 сайта (мультисайт drupal 6 + postgres 8.1) - проблемы только в watchdog (изсестное ограничение на длину varchar), при установке помнится пришлось добавить несколько индексов на таблицы ядра - devel пришлось немного модифицировать, чтобы сохранял запросы. В целом уже несколько месяцев работает без нареканий, функционал простой так что много модулей не топтал.
PS: [module=devel] заплата http://drupal.org/node/262409
Конкретный watchdog можно легко полечить, дописав туда ::varchar(16) в запрос, вставляющий в таблицу в нужное место.
Описание работы с PostgreSQL из нескольких номеров журнала Linux Format:
http://wiki.linuxformat.ru/index.php/LXF85:PostgreSQL
Было бы возможно использовать транзакции - перейти смысл был бы. А так - есть ли смысл переходить на Postgres, ведь Drupal не заморачивается с транзакциями, а без них mysql быстрее и распространённее. Вообще интересно, чем вызвано желание перейти?
В моем случае желание перейти обосновано в статье на которую ссылка
а) про PostgreSQL я знаю много, использую 10 лет и так далее....
б) MySQL с MyISAM разваливается без причины, с InnoDB - работает медленнее (и мне удалось его поставить колом)
А транзакции - ну можно привинтить в обработке постингов (вроде больше нигде не надо), но неужто часто целостность нарушается?
А кто-нибудь проверял? Например, если выкачать весь сайт drupal.ru - некоторые ссылки недействительные, может быть как раз из-за нарушения целостности? Да и как-то спокойней с транзакциями.
Ссылки на drupal.ru битые по разным причинам, чаще всего из-за удаления за ненадобностью или установки нового алиаса на страницу, ну или удаления кем-то из админов. А так просто, ничего у нас не пропадает!
И даже ведутся ревизии материалов...
PS: Пора писать импорт-экспорт и восстанавливать drupal-directory
Транзакции и так есть (и в постгресе и в InnoDB), они правда в рамках одного clause
Да и прикрутить нормальные, по меньшей мере к постингам и к комментированию - несложно. Хотя я не вижу смысла.
В моем случае в существующей инфраструктуре был только postgres и работа с ним была частью задания. Да и поддерживать проще 1 сервер чем чем 2, особенно когда нужен обмен данными между разными базами.
не, я подожду пока кто сделает
нет, сам автор честно заметил, что на чтении работает медленнее. а для вёб-проектов запросы на чтение(по крайней мере у меня на серверах) составляют 70-85%
А для ускорения чтения отлично подходят eaccelerator memcache apc были даже попытки создать кеширование узлов посредством Rules и бэкендов... хз чем закончилось
Крайне не разумно выставлять проект без кеширования или даже проксирования
Это все в огромной степени зависит от сайта. MySQL-версия работает быстрее только за счет query cache.
Я в своих тестах симулировал чистое чтение и по небольшому числу страниц.
Реально у вас любой постинг или комментарий этот кэш выбивает т.к. меняются все значимые таблицы.
Кроме того, включение кэширования в memcached или в файлах (через cache router) всю ситуацию уравнивает.
Вообще, меня не скорость волновала, она в любом случае лечится кэшированием, а моя способность
это хозяйство поддерживать - в случае постгреса она выше.
однако в случае, когда запросов на чтение 70-85% это самое выше выбивание кэша опять-таки большого значения не имеет-слишком много чисто чтения потом.
как вы опять верно заметили, работающего толкового кэширования, кроме как из БД из коробки - пока нет. и, я так понимаю, не будет до тех пор, пока такой способ не будет включен в ядро.
а по поводу того, что каждый выбирает ту субд, с которой больше работал - это да.
я на ты с mysql и oracle. Однако пока никто не оплатил настройку под оракл - всё жду такого заказа
Query cache ведь очень просто работает - поменяли таблицу и все результаты, связанные с этой таблицей из кэша вылетают. В случае друпала это означает, что если написан один комментарий к одной записи, то все про комментарии - вылетит нафиг т.е. отрисовка любой другой страницы будет не из кэша.
Как следствие, чем больше сайт - тем хуже ситуация, а реально кэширование маленьким сайтам и не нужно.
Ну а дальше все просто - с ростом нагрузки эффективность кэширования падает и плохо будет становиться не плавно, а скачком.
неа. совершенно неверно. отрисовка ЧАСТИ любой другой страницы будет не из кэша. так что драматизировать ситуацию не надо. комментарии хранятся в отдельной таблице. кроме того, вы постоянно упускаете про число запросов на чтение - 80%. Это значит, что на 1 ваш комментарий, который приводит к перегенерации ЧАСТИ страницы, приходится, вообще говоря, 4 чтения этой страницы, 2-3 которых отлично берутся из кэша. это весомо.
и вообще, скорость непосредственно вставки для вёб-сайтов мне кажется не очень важной характеристикой(по сравнению с чтением). если это не так - хотелось бы услышать аргументированное мнение.
Все не так :). Изменение таблицы с комментариями приведет к вылету из кэша всех запросов к этой таблице. Т.е. если 4 следующих запроса будут к разным нодам, то запросы по отрисовке их комментариев - все пойдут не из query cache. Если к одной ноде - то из кэша.
С чтением абсолютно понятно что делать - оно параллелится как угодно на любое количество кэшей/slave серверов/итп. Т.е. само по себе не представляет никакой проблемы по перформансу, все уже украдено до нас, хоть query cache, хоть memcached, хоть single writer - many readers. Ну нету проблем, только сервера в стойку таскай.
Запись же - штука куда более сложная и параллелится гораздо сложнее, особенно если присутствуют сложные связи между объектами в базе.
А разве возможна универсальная система кеширования?
[module=cache_router] всего лишь обертка для перенаправления запросов к кешу в нужные разработчику бэки
Ну вот наличие cache_router в поставке прямо из коробки - сильно украсило бы жизнь. А то у меня beta4 просто не работает, а у beta3 - известная проблема с жатым контентом (что именно оно закэширует - зависит от запроса)
Прикладываю мою модификацию кешроутера - она сейчас вертится на нескольких сайтах, в частности на этом
все никак не дойдут руки довести до ума!
Основная проблема это чистка кеша по маске - очень остро стоит в мемкеш, посему приходится ставить вариант shared=false (делать flush для всего кеша, и под каждую таблицу кеша свой инстанс)
ps: по кешроутеру вообще стоит поднять отдельно тему, похоже мэйнтейнер приостановил работы над всеми своими проектами. Так что все мои модификации и диалоги на тему его использования и модификации можно найти в issues на d.o
Ну пока нету отдельной темы - давайте тут.
Проблема с flush/delete в том, что друпаловский интерфейс предполагает cache_clear_all('*') и сам этим пользуется?
В-принципе, есть flush_all(), лично я бы конечно же дохакал memcached до flush_prefix() когда бы всерьез приперло.
я обхожусь самописом на файлах
Вообще ситуация с кешами очень не однозначная.
Простой пример неэффективности - банально есть проект уже более 4000 документов.
приходят яндекс рамблер гугль и ко и начинают лопатить сайт. одновременно журналисты что-то прявят и кеш скидывается.
получается 10-20% срабатываний по кешу максимум.
Если это сайт достаточно активного коммунити - cache_page сбрасывать придется очень часто. и получается что понту с него ноль.
Сам кеширую тяжелые выборки в своих модулях пользуя для этого самопис базирующийся на Zend_Cache из zend framework. пока устраивает.
насчет мемкеша -не нравится мне он.хз почему.
еще. с друпалом 200-500 select на страницу- норма. и логику промежуточного кеширования продумать - почти невозможно. там есть нюансы - ты не всегда знаешь четко, ЧТО надо из хранилища сбросить... увы.
Насчет побить это опупеное число селектов с помощью настроек базы - так шина у сервака тоже не резиновая.
упремся в нее.
пока в проекте действительно сильной нагрузки - не предвидится. целевая аудитория полторя ляма жителей - из них дай бог тысяч 10 будут ходить на сайт - уже будет хорошо. но для реально больших проектов все это несерьезно... увы.
да и еще....
на тему кешей... я свое тихим сапом делаю.
естественно надо минимизировать число выборок.
потому как 200 запросов к базе или 200 треньканий кеша - это уже сравнимо по нагрузке будет
А я вот особой разницы не вижу - чем простой запрос 1й записи из базы по индексу хуже такого же в memcache?
А там где отбор по параметрам или выборка разных порций данных - никуда не деться от рендера.
ЖЖ коменты тоже особо не побороло... это тоже камень в огород mysql (работа с иерархиями... ностальгия по ораклу)
Есть наилучший случай, обычный и наихудший. Наилучший - query cache, разница только в том, что запрос надо попарсить ну и библиотеки клиентские потяжелее.
Обычный - индекс и данные уже в кэше БД - нужно попарсить запрос, сходить по 2-3 уровням индиректа, сформировать ответ.
Наихудший - по базе пронесся какой-то другой запрос, кэши вымыты и мы все берем с диска. Это может оказаться несколько disk read из разных мест т.е. время исполнения будет в сотню(-другую) миллисекунд.
Посмотрите на баннерки - они все отдают из памяти, лучше отдать плохо подобранный баннер сразу, чем хорошо подобранный через 10 секунд. И, кстати, те же баннерки живут на комиссию с показов, что означает что просто сайту в 5-10 раз финансово лучше (в смысле цены железа и прочего).
Ну так единица кэширования - это блок (есть ньюансы с представлением дерева комментариев к статье, а других ньюансов не вижу). Готов допустить, что блок с параметрами (включая туда и юзернейм).
Ну и push-ем их, поменялся блок - пушаем его в кэш сами.
единица кеширования не только блок (он имеет параметры theme:language:role)
Кешируются разные сущности...
Илья, специально для того, чтобы кеш не сбрасывался при каждом посте, коих может быть много и часто - есть настройка "Минимальное время жизни кеша" ставишь пол часа и все твои очистки обламываются - гугл и яша получают как и анонимы из кеша!
Андрей, я за актуальный контент на сайте
Тут есть проблема ровного висения. Т.е. все места на сайте должны бы быть консистентными. Т.е. при новом посте обновляется морда, раздел, блок "новое сегодня", RSS-лента - и все это сразу. Ну и облако тегов и блок "популярно сегодня" - это можно с задержкой.
Везде, где такая задача возникала - мы приходили к тому, что кэши заполняются явно и именно процедурой публикации. Сбивать при этом все кэши в надежде что они сами заполнятся - это 20-й век, ну самое самое начало 21-го.
По поводу чистки по префиксу http://drupal.org/node/224772
Там в 16-17 коменте я пытался раскрыть грабли и привел практически все места в коде, где оно используется
По поводу flush_prefix - просто не представляю, как его хакать и как эти изменения потом включить в поставку.
С другой стороны для этого сейчас используется lookup запись в которую попадают все ID кеша, которые будут требовать ручной очистки. Но как только появляется lookup (индекс) возникает бутылочное горлышко - это запись в него и, возможно, чтение. Этот индекс можно хранить в любом другом месте(бэке), но это оопять же дополнительные накладные расходы на запись.
Далее - использование eaccelerator APC и файловой системы. Там точно такая же песня.
eacc в отличие от всех остальных имеет функции eaccelerator_lock eaccelerator_unlock
файловая система - вообщем-то тоже, но там и с чтением-записью нужно делать самому блокировки.
apc - бомба, в оригинале автор делает цикл и ожидает разблокировки, работает крайне неустойчиво абсолютно не подходит для чистки по маске.
Варианты решения, которые приходили в голову и не только мою:
1 отказаться от чистки по маске, как делается в memcache - чистить всё, если запрос по маске
2 хранить lookup в быстрой памяти eacc (apc) (возникает еще одна настройка для хранения этого выбора и накладные расходы на блокировку этих ресурсов)
3 добавить версионность для lookup (в бэках обычно есть функции inc|dec - мы избегаем блокировки, но возможны расхождения (2 процесса один очистил, второй добавил - кто первый ...)
С файловой системой Илья вроде добился кое-каких результатов, я лично не экспериментировал, но думаю результат будет примерно такой же, хотя много серверов на sata, но есть аргумент в сторону кеширования файловой системы ядром ОС.
В результате для себя выбрал следующие стратегии:
- cache_page (memcache-1)
- cache_filter (memcache-2)
- cache_form (memcache-3)
остальное в акселератор влезает на ура!
все это под 6кой - с 5кой не возился...
Ну, народ его как-то улучшает и результат сабмитит, в nginx-ru такие тусуются.
А хакать просто - там же где-то обязан быть индекс, вот по нему пробежаться и удавить все,
не бог весть какая задача. Когда у меня будет такая проблема - дела максимум на полдня. Пока ее нет.
Проблема в том, что это другое место должно разделяться между процессами, их может быть много. Надо делать на шареной памяти с атомарными локами, только вот я не PHP-шник и такого в жизни не сделаю на этом странном языке.
Но решение с lookup-записью - плохое, если она может дергаться из разных мест.
Категорически нет. У тебя на этом кэше могут жить сотни разных сайтов. Т.е. обязательно нужен
префикс (сайт+таблица).
Нужна версионность для lookup + версионность для самих данных. Тогда проблем вроде бы нету совсем.
А чтобы не залипало навсегда - время хранения в кэше должно быть разумно-небольшим (полчаса)
Память дешевая, можно просто файловую систему на memfs.
Кстати, там у тебя есть проблема с логикой такого вот вида
lock()
считываем lookup
записываем пустой lookup
unlock()
чистим по списку
Вот пока мы чистим по списку - другой процесс может понаписать тех же ключей, а мы их вычистили...
Версионность данных в кеше - считаю излишней, хотя для версионности узлов может быть полезна.
Логика такая сделана умышленно - для скорости! Приоритет за удалением, те если я сотру запись после того, как другой процесс обновит\запишет ничего страшного, ибо следующее обращение запишет или добавит!
Знаешь анекдот про то, что неровное висение - неаккуратненько.
А проблема при стирании лишнего очень простая - если кто-то попрется мимо кэша и таких много - поплохеет. Ну, при реальной большой нагрузке вроде 5000-10000 в секунду с сервера.
Проблемы то я понимаю, но этот lookup серьёзное горлышко - от него нужно уходить!
- вынужденная необходимость.
А текущее решение (очень надеюсь не постоянное
А если рассматривать такую нагрузку - я с таким просто не сталкивался, опыта нет. Могу только предположить, что придется серьезно переписывать front (точнее вывод) и работать не с записями, а с отрендеренными кусками, которые будут где-то собираться. Мне кажется это уже совсем другая архитектура. Например, flex - морда flash а через xml-rpc тянет данные - overhead небольшой, рендер ложится на клиента. Можно попробовать пойти по пути подгрузки кусков страницы через JS - но боюсь что дешевле будет страницы целиком отдавать.
В любом варианте - мы лишаемся прелестей друпала в виде возможности смены тем пользователями, просмотр контента в языкозависимом интерфейсе - они добавляют измерений для кеша и такую систему разом в голове не представить!
Рендер на клиенте - отличная идея, но есть поисковики, которые как-то придется обслуживать. Я же предлагаю рендер на фронтенде: оформление отдается рамкой с #include virtual=/blockname/theme/lang, а эти куски - кэшируются в memcached или там еще где. Так много кто работает
Тут же выше написали - theme/language, которые придется или в куку положить или по-хорошему полукапить на фронтенде же.
flock() никто не отменял. да и расширение PHP для блокировок если припрет пишется за пару дней. я в своих решениях flock() пока отбиваюсь.
Блокировка на файлах - это 19-й век. В 21-м есть atomic cmp and set, 7 ассемблерных инструкций без контекст-свитча
я в курсе. но есть один нюанс.
flock на shared хостинге работает. а свое расширение я там не воткну.
для сайта "визитки" таким кешем превратить 200 запросов к перегруженой базе MySQL в 5 как раз то самое милое дело.
И юзерам удобно - вся моща CMS - и руководство фирмы заказчика радо -- сайт летает
а вы читаете, что я пишу, или только сами пишете? вы же знаете, что друпал состоит не только из таблицы с комментариями. около 50 таблиц, к которым запросы кэшируются. если для построения страницы из кэша были взяты не 50, а 49 таблиц - это очень печальный факт. учитывая, что кэш восстановится после следующего чтения. да я и вообще не понимаю, о чём тут спорить. mysql всяко быстрее с query cache. любой тест покажет. и вы сами с этим соглашались
и опять-таки мыслями по древу, а по существу не ответили.
и вообще, скорость непосредственно вставки для вёб-сайтов мне кажется не очень важной характеристикой(по сравнению с чтением). если это не так - хотелось бы услышать аргументированное мнение.
вы говорите про сложность репликации, а не про то, зачем вообще нужна эта самая производительность вставки для вёб-сайта(которая ему толком не нужна). вёб-сайт это не нагруженный биллинг, куда каждую секунду пишутся данные о трафике с тысячи абонентов. вёб-сайт, даже самый популярный, в-основном читают.
из коробки кэширование хранит старницы для анонимусов и блоки для всех пользователей. возможно, это не универсальность,но хороший шаг к ней.
Да в тестах - конечно быстрее, где вы видели нормальный read-write тест.
Я вообще говорю про другое. Могу разжевать помельче, мне несложно
1) Скорость чтения не является проблемой. Ставьте кэш побольше, кэшируйте получше, собирайте страницы на фронтенде. Кэширование блоков в memcached и сбор их в frontend-nginx даст еще полтора порядка скорости read-only доступа в сравнении с кэшированием таблиц cache_* в query cache
2) Единственное достоинство query-cache в том, что достается он бесплатно. Все остальное (в первую очередь политика очистки) - недостатки.
3) В реальной жизни вы не столкнетесь с серьезными проблемами по чтению (а если столкнетесь, то добро пожаловать в пункт 1: кэши такие-сякие, сборка из редко меняющихся кусочков, пополнение кэшей не on-demand, а насильно - все 100 раз пройдено).
4) Когда же вы столкнетесь с реальными проблемами по записи - будет больно, ибо это легко не лечится (а в конкретном случае друпала будет лечить очень тяжело)
и ещё раз - никаких проблем с производительностью записи _нет_и_не_будет_ для вёб-проектов именно в силу их специфики.
Ага-ага, шардинг придумали т.к. заняться было нечем. Идите, расскажите это Мамбе.
Наткнулся на интересный проект-модуль [module=bitcache] - интересная идея... по сути продвинутый кеш-роутер.
Так же поддерживает разные бэки, но нужно посмотреть как он для кеширования подходит.
PS: еще забавно посмотреть на компанию, которая спонсирует разработку - они очень оперативно создали интеграцию к различным внешним сервисам и достаточно оперативно.
Теперь можно прикрутить к этому сайту например jabber в довесок к irс
Осталось довести социальную составляющую до ума и можно как конструктором пользоваться. API, кстати, сейчас для социалок обсасывается...