innodb. myisam. прозводительность. ку-ку.

а как конвертировал? может есть смысл создать новую бд и просто импортнуть туда данные? что-то я не помню, чтоб была такая разница в размере.

что только не делают чтобы postgresql не использовать :-)

>а как конвертировал?

alter table posts engine = innodb;

может есть смысл создать новую бд и просто импортнуть туда данные?

Не-а, столько же выйдет. На более мелких базах проверял. Всё равно там всё время занимает составление индексов, а они-то одни и те же и там, и там. А размер данных в myisam реально получается в несколько раз больше. Уж не знаю почему:

Данные   8,233.0    МБ
Индекс   894.3    МБ
Всего   9,127.3    МБ

ну так и postgres myisam сливает, разве нет?

ALTER TABLE t1 ENGINE = InnoDB;

>что только не делают чтобы postgresql не использовать :-)

Когда я, наконец, осилю его установить и оптимально настроить (насколько я помню, на всех форумах всегда говорят, что с дефолтовыми настройками он представляет собой редкого тормоза и чтобы он работал быстрее, чем mysql, его надо настраивать, и то не факт, что на простых запросах он будет быстрее, а сложных у меня и нет ;)), то свой-то форум, может, и переведу, если результаты будут радужные. А вот что делать с клиентами с дешёвыми хостингами, где только mysql? ;)

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

>а то при переходе на новую версию базы надо пересоздавать

Хм.

но это наверное только для bleeding-edge дистров всяких.

Ну, я предпочитаю в Gentoo arch-версии. Постгре сейчас там 8.1.11

что то я с таким не встречался, может старые воспоминаяния как о горячих атлончиках?

http://www.postgresql.org/docs/8.1/interactive/install-upgrading.html

наслаждайся. это конечно не только к 8.1 относится.

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

второй раз - на машинах с debian etch при попытке заюзать поисковой движок sphinx, он требовал более новых версий постгреса ( в etch afair 7.x древнючий ).

не страшно, но все равно осадочек остается, stable-api-nonsense и все такое.

в нормальных дистрибутивах базы лежат в каталогах имя которых состоит из версии postgresql и соответственно никак не пересекаются.

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

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

> Простые, типа отсортировать 4500 постингов под двум ключам и выдать 100 записей, начиная с 4000-й (разбивка по страницам) на myisam в 20-80 раз быстрее

Не должно быть такой разницы. Либо запросы кривые, либо мускул неправильно настроен, либо сервер, либо все вместе сразу :) .

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

По той же разбивке на страницы могу предположить, что написан select * вместо выборки ID по coverage index и добору заголовков по списку ID.

Логи медленных запросов и запросов без индексов позволяют увидеть почти все косяки на таких простых проектах.

>вместо выборки ID по coverage index и добору заголовков по списку ID

Ещё раз и по-русски :)

Логи медленных запросов и запросов без индексов

Индексов там, как бы, на все случаи жизни :) Собственно, уже по тому, что на innodb индексов получилось без малого гигабайт можно выводы делать.

Естественно, что в логах запросов без индексов - пусто. Естественно, что explain я смотрел.

>но чтобы так часто - подзадалбывает.

ну не просто так же меняют, быстрый vacuum например сделали.
по мне так лучше пусть меняют ради увеличения производительности.

Так на каком сейчас лучше сидеть-то? :)

> Ну, я предпочитаю в Gentoo arch-версии. Постгре сейчас там 8.1.11

в 8.3 очень пооптимизировали многое, в том числе работу с индексами...

http://www.postgresql.org/
последний 8.4.2

Я в курсе, какой последний :) Я имею в виду, на каком сейчас лучше сидеть, чтобы иметь меньше приключений на будущее.

В 8.4 много полезного по сравнению с 8.3?

> Так на каком сейчас лучше сидеть-то? :)

Последнем стабильном, который сумеешь по-простому поставить в своем дистрибутиве.

Кстати, в последних версиях Postgres еще и сделали, чтобы настройки многие делались автоматом, так что его еще и администрировать становиться проще (кроме скорости работы).

> Ещё раз и по-русски :)

Вона, медитируй :) http://habrahabr.ru/blogs/mysql/44608/

Смысл в том, что если ты выбираешь только те данные, которые в индексе, то обращения к базе вообще не происходит. А если ты пишешь select * со всякими limit и group, то могут случиться аццкие сортировки.

Поэтому для больших топиков актуально сначала выбрать и отсортировать ID тем, со всеми ограничениями, и только потом по ним выбрать заголовки топиков (или содержимое постов)

Насчет innodb - оно вообще иначе память использует. Там не только индексы всасываются, но и таблицы. Поэтому памяти надо давать намного больше. А еще лучше - не колбасить все сразу.

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

http://www.postgresql.org/docs/current/static/release-8-4.html

Just use TJ7!

>Вона, медитируй :)

А, понял. Видел эту статью и знаю этот метод. Мне не подходит, т.к. одна база на массу форумов, ID перемешаны, разрежены и, вообще, сортировка идёт не по ним :) Например, позже могут вставляться сообщения, идущие в начале темы и т.п.

Поэтому для больших топиков актуально сначала выбрать и отсортировать ID тем

На практике же я у себя решил задачу тупо. Ввёл у каждого топика параметр страницы (число сообщений на страницу, понятно, фиксировано): http://www.linux.org.ru/view-message.jsp?msgid=3881616

Там не только индексы всасываются, но и таблицы. Поэтому памяти надо давать намного больше.

Ну, девяти гигов всё равно нет :) А так - 900Мб RSS + 1600Мб VIRT сейчас за mysql числится.

Я очень настойчиво не рекомендую раньше времени развлекаться с типами стораджей

Так пока то, что есть я переносить ни на что другое и не собираюсь :) Но на будущее всегда полезно изучить «как оно на других фронтах». InnoDB же интересует внешними ключами.

>Just use TJ7!

Почему-то на первых трёх страницах не нашёл ничего про КОРОВАНЫ. Поэтому дальше листать не стал.

>http://www.postgresql.org/docs/current/static/release-8-4.html

Откуда мне знать, никогда не работавшему с Постгре, что из этого полезно, а что - рюшечки? :)

select id from posts where topic_id = 52776 ORDER BY id LIMIT 4000, 25;

Index(topic_id,id) точно есть? Именно такой.

>select id from posts where topic_id = 52776 ORDER BY id LIMIT 4000, 25;

select id from posts where topic_id=52776 order by `order`, posted limit 4100,100;

id у меня не фигурирует в этом виде запроса. Но в Греции всё есть (у меня есть похожие запросы в других местах):

KEY `index_for_joins` (`topic_id`,`id`),

Index(topic_id,id) точно есть? Именно такой.

Есть также и под мой запрос... Хм, нет. Я же order вводил уже после разбивки на страницы, так что только (topic_id, posted) есть. Но это не принципиально, учитывая, что нет этого индекса и на myisam-базе, а работает она всё равно шустрее.

...

Для спортивного интереса введу сейчас индекс (topic_id, order, posted) в тестовую innodb базу, но в рабочую myisam не буду :)

Почитай, что такое coverage index. Возможно, ты просто сочинил себе лишних проблем на ровном месте. На твоем проекте база должна быть простой как дверь и прямой как рельса.

Пока нет очевидных индексов, сравнивать производительности баз бесполезно. Получится оценка кеширования в памяти кривых запросов - это эзотерика.

Лучше создай заново тему в девевлопменте и кинь туда структуру таблицы, индексы, запросы. Посмотрим. В старую уже не ответить.

>Почитай, что такое coverage index.

Я же говорил, что данную тобой статью читал :) Мне с неё пользы мало.

На твоем проекте база должна быть простой как дверь и прямой как рельса.

Угу. Вот и сделал прибитые гвоздями номера страниц в базе. Куда уж проще-то? :)

Пока нет очевидных индексов, сравнивать производительности баз бесполезно

Видишь ли, с текущей структурой (и статическим кешированием) справится хоть тот же sqlite, наверное. У меня сейчас и 10млн. запросов в сутки нет, пожалуй.

Так что тут на производительность, отданную за те же внешние ключи я бы глаза закрыл. Но то, что система уходит в себя на несколько часов при изменении индексов - вот это в первую очередь ставит на базе крест. Добавил новое поле - несколько часов простоя. Изменил формат поля - ещё несколько часов простоя. Или создание индексов тоже как-то настраивать особо нужно? :)

Не вали в кучу разные сущности. Начато было с того, что запросы с разной скоростью бегают, а закончилось тормозами на изменении схемы. Я ж не телепат.

Когда схему меняешь, юзерам доступ к сайту закрываешь?

>Начато было с того, что запросы с разной скоростью бегают, а закончилось тормозами на изменении схемы

Мне БД, как бы, не для одних только select'ов нужна :)

Когда схему меняешь, юзерам доступ к сайту закрываешь?

Нет, естественно. На несколько часов вырубать боевой сервер для тестов, как бы, не очень кошерно.

в Postgresql индексы можно создавать без блокирования записи в эту же таблицу

CONCURRENTLY

When this option is used, PostgreSQL will build the index without taking any locks that prevent concurrent inserts, updates, or deletes on the table;

В быстром добавлении полей не уверен.

>в Postgresql индексы можно создавать без блокирования записи в эту же таблицу

Вот это очень гут :)

В быстром добавлении полей не уверен.

В mysql при добавлении поля само оно добавляется мгновенно, но потом следует пересчёт всех индексов таблицы.

> Нет, естественно. На несколько часов вырубать боевой сервер для тестов, как бы, не очень кошерно.

Если выключать - разница в несколько раз. Не вижу причин, почему на данном конкретном проекте такое нельзя проделыть ночью, раз в пол года.

Рано утром добавлял индекс на таблицу постов, где миллион с хвостиком записей, заняло пару минут. Без выключения. Долго могут делаться индексы по текстовым полям, и некоторые изменения структуры.

IMHO, пока нет конкретных таблиц и запросов - разговоры в пользу бедных.

>Не вижу причин, почему на данном конкретном проекте такое нельзя проделыть ночью, раз в пол года.

1. Потому что иногда расширений таблицы приходится проводить несколько раз в месяц.

2. Всё равно не понимаю, как может влиять выключение сайта на скорость создания индексов неиспользуемой таблицы.

IMHO, пока нет конкретных таблиц и запросов

Структуру таблицы я приводил. Основной запрос - тоже.