Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 MySql vs PostgreSql again  [new]
Marina_R
Guest
Многие задают этот вопрос - не буду и я оригинальничать.
Немного другая специфика, как мне кажется: никакого web-приложения.
Linux. Система - около десятка процессов (только они) имееют доступ к базе данных. В базе несколько десятков таблиц и около полумиллиона записей.
Высокая скорость обновления.
В данный момент работаем с Postgre, 24/7 как говорится.
Очень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени.
Вот при таких условиях, когда основная проблема - storage и нет необходимости в stored procedures и других подобных вещах, что лучше - оставить все как есть или попробовать перейти на MySql? (Начальство ограничивает выбор - free & open source)
Посоветуйте, пожалуйста.
Да, и если Postgre - с какими еще оптимизациями стоит поиграться?
(до сих пор трогала только shared_buffers, sort_mem и vacuum_mem)
8 июн 04, 10:43    [727977]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
а firebird не пробовали? вроде по описанию вполне должен подойти
8 июн 04, 10:46    [727991]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Igor Elyas
Member

Откуда: Севастополь
Сообщений: 288
Действительно попробуйте Firebird.

Я переходил с PostgreSQL при создании биллинга для ISP.

Насчет Мускула не все так очевидно. При небольшом количестве подключений и активных пользователях он по скорости будет быстрее всех. А вот когда паралельная нагрузка станет большой, проявится обратный эффект - непропорциональное падение производительности. Хотя опять же в рамках описание задачи оно вам не грозит :).
8 июн 04, 11:14    [728089]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Marina_R
Guest
Спасибо.
Пойду читать документацию "Жар-птицы"...
На нее и не смотрела, так как попадалось мнение будто Firebird практически идентична Postgres?
А там не надо запускать Vacuum? :-)
8 июн 04, 11:27    [728163]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
Marina_R

На нее и не смотрела, так как попадалось мнение будто Firebird практически идентична Postgres?

не думаю так :-)

Marina_R

А там не надо запускать Vacuum? :-)


ну, если ты скажешь нам что такое vacuum то мы скажем нужно его запускать или нет :-)
8 июн 04, 11:41    [728217]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
не... ну я тащщусь от нового цитирования :-)
8 июн 04, 11:42    [728228]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Marina_R

Очень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени.

мало информации.
какая версия сервера?
какой VACUUM (FULL или обычный)?
насколько часто обновляются данные?

общий совет: можно попробовать autovacuum демон.

Marina_R

Да, и если Postgre - с какими еще оптимизациями стоит поиграться?
(до сих пор трогала только shared_buffers, sort_mem и vacuum_mem)

effective_cache_size, max_fsm_relations, max_fsm_pages (!)

не откажу себе в удовольствии пропиарить свою статью
8 июн 04, 11:54    [728285]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Marina_R
Guest
alex_k

ну, если ты скажешь нам что такое vacuum то мы скажем нужно его запускать или нет :-)

Упрощено: при Update, Delete старые записи не уничтожаются физически.
Размер базы только растет до тех пор пока не делают vacuum
8 июн 04, 12:09    [728347]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Igor Elyas
Member

Откуда: Севастополь
Сообщений: 288
В IB/FB есть так называемая фоновая или не совсем фоновая (для классика) сборка таких записей.

Данный процесс при обыкновенной работе размазан во времени. Если применяются rollback то есть сложности со sweep процессом, может в вашем варианте придется принудительно пускать sweep процессы.

Все эти варианты решаемы и выскакивают в случае специфического применения БД (как правило в этом слусае всем версионникам плохо:)).

Консультации - пиши в почту.
8 июн 04, 12:18    [728377]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Marina_R
Guest
Sad Spirit

мало информации.
какая версия сервера?
какой VACUUM (FULL или обычный)?
насколько часто обновляются данные?


Postresql-7.3.2.3
cron.weekly : full vaccum
cron.hourly : vacuum -z

Насчет частоты обновляемых данных - сложнее,
не меряла, но знаю, что постоянно :)
Система ведет запись разных событий - они фиксируются в БД.
Указатели на файлы, время события и прочее...

Sad Spirit

effective_cache_size, max_fsm_relations, max_fsm_pages (!)

не откажу себе в удовольствии пропиарить свою статью

Не откажу себе в удовольствии прочитать :)
Указанные выше параметры там тоже упоминаются?
8 июн 04, 12:29    [728417]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Marina_R
Guest
Про effective_cache_size, max_fsm_relations, max_fsm_pages вопрос снят - прочитала.

P.S. Да, еще я добавила перед vacuum
reindex пары таблиц, чьи индексы все время растут.
Проверила на неком скриптике, который вносит, вносит, вносит и стирает записи.
Так без reindex-а vacuum после 500000 стертых записей занимал от 5 до 10 минут,
а вместе - около 10 секунд. Существенное различие. :)
8 июн 04, 13:28    [728720]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Ну раз растут индексы, то рекомендуется апгрейд до 7.4.x, в котором это поправлено. Естественно, настройка max_fsm_pages. Возможно, использование pg_autovacuum, он будет делать vacuum по мере необходимости (примерно как в FireBird, насколько я понял объяснения).

Если в реальном приложении удаляются 500000 записей, то стоит снести индекс перед удалением и вновь построить (что в общем REINDEX и делает) после.
8 июн 04, 14:20    [728944]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
eddie
Member

Откуда: пенза
Сообщений: 275
сорри за оффтопик, но раз здесь речь об этом зашла:
Sad Spirit
Ну раз растут индексы, то рекомендуется апгрейд до 7.4.x, в котором это поправлено.
у меня vacuum full выдает кучу ругани на индексы служебных таблиц, типа такого:
WARNING:  index "pg_depend_depender_index" contains 3722 row versions, but table contains 3720 row versions
reindex database помогает, но что это, откуда и почему?
версия 7.4.2
8 июн 04, 16:07    [729332]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
eddie
у меня vacuum full выдает кучу ругани на индексы служебных таблиц,

С железом точно всё в порядке? Шнур питания из компьютера регулярно не выдёргивают?

Вообще с такими вопросами лучше в списки рассылки, я не думаю, что кто-то кроме разработчиков внятно на них может ответить.
8 июн 04, 16:37    [729457]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
eddie
Member

Откуда: пенза
Сообщений: 275
питание вообще не выключается :), проявляется на двух компьютерах, с железом вроде все нормально - трабла явно софтовая

я пока на рассылки (кроме pgsql-perfomance) не подписан, да и с английским плоховато... ладно, буду копаться
8 июн 04, 17:26    [729625]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
eddie
с железом вроде все нормально - трабла явно софтовая


хм... у меня проблемы с битыми индексами были один раз, и тогда это решалось обновлением glibc. но это было весьма давно.
8 июн 04, 17:56    [729730]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
А там не надо запускать Vacuum? :-)
Не пойму, зачем нужно сжимать БД? Ведь записи удаляются, а затем другие добавляются. Разве PG не использует повторно это пространство?
В FB нет необходимости в сжатии БД. Ну а способы борьбы с замедлением во время сборки мусора известны.
9 июн 04, 08:10    [730450]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
f_w_p
Ведь записи удаляются, а затем другие добавляются. Разве PG не использует повторно это пространство?


Использует, но только после выполнения VACUUM, при котором удаленные (и обновленные) строки помечаются как пригодные для повторного использования. Команда VACUUM FULL удаляет из файла удаленные (и обновленные) строки, и строки помеченные как пригодные для повторного использования, то есть сжимает файл.
9 июн 04, 10:08    [730657]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
LeXa NalBat
Использует, но только после выполнения VACUUM, при котором удаленные (и обновленные) строки помечаются как пригодные для повторного использования. Команда VACUUM FULL удаляет из файла удаленные (и обновленные) строки, и строки помеченные как пригодные для повторного использования, то есть сжимает файл.

Ну вот и получается, что не использует. Размер файла БД уменьшается, а потом опять начинает расти. FB же повторно использует страницы данных и индексов, к-рые не используются. На этом основан один из методов повышения производительности. Это когда в БД заливают любые данные с целью увеличить размер файла до необходимой величины. Затем данные удаляют. И работают затем с полученным файлом БД. На некоторых файловых системах получается выигрыш в производительности.
9 июн 04, 12:38    [731315]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
eddie
Member

Откуда: пенза
Сообщений: 275
f_w_p
Размер файла БД уменьшается, а потом опять начинает расти
http://detail.phpclub.net/store/html/postgresql/node3.html
VACUUM FULL (VACUUM до 7.2) пытается удалить все старые версии записей и, соответственно, уменьшить размер файла, содержащего таблицу. Этот вариант команды полностью блокирует обрабатываемую таблицу.
VACUUM (начиная с 7.2) помечает место, занимаемое старыми версиями записей, как свободное (см. также пункт 2.3). Использование этого варианта команды, как правило, не уменьшает размер файла, содержащего таблицу, но позволяет не дать ему бесконтрольно расти, зафиксировав на некотором приемлемом уровне. При работе VACUUM возможен параллельный доступ к обрабатываемой таблице.
то есть если не делать vacuum full, то размер файла уменьшаться не будет. autovacuum же делает периодический vacuum (основанный на активности в базе данных), afaik это приблизительно соответствует поведению fb
9 июн 04, 12:59    [731439]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
eddie
Member

Откуда: пенза
Сообщений: 275
f_w_p
Ну а способы борьбы с замедлением во время сборки мусора известны.
интересно, какие?

ps: vacuum (без full) и есть такая сборка мусора.
9 июн 04, 13:01    [731452]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
f_w_p
Ну вот и получается, что не использует. Размер файла БД уменьшается, а потом опять начинает расти.


Такая картина наблюдается, если регулярно вызывается VACUUM FULL.

Именно поэтому в одной из используемых у нас БД (данные в ней обновляются ежедневно целиком) делаем ежедневно VACUUM. При этом база занимает на диске в два раза больше места, чем требуется. Но в скорости процедуры обновления данных имеем выигрыш (за счет того, что INSERT добавляет данные в пустое место в середину db-файла, а не в конец db-файла одновременно с увеличением его размера). Раз в месяц все же делаем VACUUM FULL - возможно для устранения каких-нибудь утечек. :)
9 июн 04, 13:09    [731493]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
P.S.: VACUUM, VACUUM FULL и VACUUM ANALYZE можно, по-моему, считать тремя разными командами.
9 июн 04, 13:13    [731509]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
LeXa NalBat
P.S.: VACUUM, VACUUM FULL и VACUUM ANALYZE можно, по-моему, считать тремя разными командами.

Ну вот теперь разъяснили. Похоже они ведут себя одинаково. Тогда не понятна проблема автора топика. Никакого замедления не д.б.
9 июн 04, 14:08    [731766]     Ответить | Цитировать Сообщить модератору
 Re: MySql vs PostgreSql again  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
f_w_p
Тогда не понятна проблема автора топика. Никакого замедления не д.б.

Проблема-то как раз понятна, до версии 7.4 могли распухать файлы индексов, и время от времени надо было делать REINDEX.
9 июн 04, 14:42    [731960]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить