ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MySql vs PostgreSql again
30 сообщений из 30, показаны все 2 страниц
  все  
MySql vs PostgreSql again
    #32551894
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
Многие задают этот вопрос - не буду и я оригинальничать.
Немного другая специфика, как мне кажется: никакого web-приложения.
Linux. Система - около десятка процессов (только они) имееют доступ к базе данных. В базе несколько десятков таблиц и около полумиллиона записей.
Высокая скорость обновления.
В данный момент работаем с Postgre, 24/7 как говорится.
Очень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени.
Вот при таких условиях, когда основная проблема - storage и нет необходимости в stored procedures и других подобных вещах, что лучше - оставить все как есть или попробовать перейти на MySql? (Начальство ограничивает выбор - free & open source)
Посоветуйте, пожалуйста.
Да, и если Postgre - с какими еще оптимизациями стоит поиграться?
(до сих пор трогала только shared_buffers, sort_mem и vacuum_mem)
...
Рейтинг: 0 / 0
08.06.2004, 10:43
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32551904
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_k
Участник
а firebird не пробовали? вроде по описанию вполне должен подойти
...
Рейтинг: 0 / 0
08.06.2004, 10:46
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32551969
Igor Elyas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Elyas
Участник
Действительно попробуйте Firebird.

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

Насчет Мускула не все так очевидно. При небольшом количестве подключений и активных пользователях он по скорости будет быстрее всех. А вот когда паралельная нагрузка станет большой, проявится обратный эффект - непропорциональное падение производительности. Хотя опять же в рамках описание задачи оно вам не грозит :).
...
Рейтинг: 0 / 0
08.06.2004, 11:14
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552014
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
Спасибо.
Пойду читать документацию "Жар-птицы"...
На нее и не смотрела, так как попадалось мнение будто Firebird практически идентична Postgres?
А там не надо запускать Vacuum? :-)
...
Рейтинг: 0 / 0
08.06.2004, 11:27
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552044
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_k
Участник
Marina_R
На нее и не смотрела, так как попадалось мнение будто Firebird практически идентична Postgres?

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

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

ну, если ты скажешь нам что такое vacuum то мы скажем нужно его запускать или нет :-)
...
Рейтинг: 0 / 0
08.06.2004, 11:41
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552053
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_k
Участник
не... ну я тащщусь от нового цитирования :-)
...
Рейтинг: 0 / 0
08.06.2004, 11:42
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552090
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Marina_R
Очень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени.

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

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

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

effective_cache_size, max_fsm_relations, max_fsm_pages (!)

не откажу себе в удовольствии пропиарить свою статью
...
Рейтинг: 0 / 0
08.06.2004, 11:54
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552131
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
alex_k
ну, если ты скажешь нам что такое vacuum то мы скажем нужно его запускать или нет :-)
Упрощено: при Update, Delete старые записи не уничтожаются физически.
Размер базы только растет до тех пор пока не делают vacuum
...
Рейтинг: 0 / 0
08.06.2004, 12:09
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552158
Igor Elyas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Igor Elyas
Участник
В IB/FB есть так называемая фоновая или не совсем фоновая (для классика) сборка таких записей.

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

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

Консультации - пиши в почту.
...
Рейтинг: 0 / 0
08.06.2004, 12:18
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552195
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
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 (!)

не откажу себе в удовольствии пропиарить свою статью
Не откажу себе в удовольствии прочитать :)
Указанные выше параметры там тоже упоминаются?
...
Рейтинг: 0 / 0
08.06.2004, 12:29
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552387
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
Про effective_cache_size, max_fsm_relations, max_fsm_pages вопрос снят - прочитала.

P.S. Да, еще я добавила перед vacuum
reindex пары таблиц, чьи индексы все время растут.
Проверила на неком скриптике, который вносит, вносит, вносит и стирает записи.
Так без reindex-а vacuum после 500000 стертых записей занимал от 5 до 10 минут,
а вместе - около 10 секунд. Существенное различие. :)
...
Рейтинг: 0 / 0
08.06.2004, 13:28
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552484
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Ну раз растут индексы, то рекомендуется апгрейд до 7.4.x, в котором это поправлено. Естественно, настройка max_fsm_pages. Возможно, использование pg_autovacuum, он будет делать vacuum по мере необходимости (примерно как в FireBird, насколько я понял объяснения).

Если в реальном приложении удаляются 500000 записей, то стоит снести индекс перед удалением и вновь построить (что в общем REINDEX и делает) после.
...
Рейтинг: 0 / 0
08.06.2004, 14:20
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552733
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
сорри за оффтопик, но раз здесь речь об этом зашла: Sad SpiritНу раз растут индексы, то рекомендуется апгрейд до 7.4.x, в котором это поправлено.у меня vacuum full выдает кучу ругани на индексы служебных таблиц, типа такого:
Код: plaintext
WARNING:  index "pg_depend_depender_index" contains  3722  row versions, but table contains  3720  row versions
reindex database помогает, но что это, откуда и почему?
версия 7.4.2
...
Рейтинг: 0 / 0
08.06.2004, 16:07
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552818
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
eddieу меня vacuum full выдает кучу ругани на индексы служебных таблиц,
С железом точно всё в порядке? Шнур питания из компьютера регулярно не выдёргивают?

Вообще с такими вопросами лучше в списки рассылки, я не думаю, что кто-то кроме разработчиков внятно на них может ответить.
...
Рейтинг: 0 / 0
08.06.2004, 16:37
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552937
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
питание вообще не выключается :), проявляется на двух компьютерах, с железом вроде все нормально - трабла явно софтовая

я пока на рассылки (кроме pgsql-perfomance) не подписан, да и с английским плоховато... ладно, буду копаться
...
Рейтинг: 0 / 0
08.06.2004, 17:26
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32552988
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
eddieс железом вроде все нормально - трабла явно софтовая

хм... у меня проблемы с битыми индексами были один раз, и тогда это решалось обновлением glibc. но это было весьма давно.
...
Рейтинг: 0 / 0
08.06.2004, 17:56
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32553430
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f_w_p
Участник
А там не надо запускать Vacuum? :-)
Не пойму, зачем нужно сжимать БД? Ведь записи удаляются, а затем другие добавляются. Разве PG не использует повторно это пространство?
В FB нет необходимости в сжатии БД. Ну а способы борьбы с замедлением во время сборки мусора известны.
...
Рейтинг: 0 / 0
09.06.2004, 08:10
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32553555
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
f_w_pВедь записи удаляются, а затем другие добавляются. Разве PG не использует повторно это пространство?

Использует, но только после выполнения VACUUM, при котором удаленные (и обновленные) строки помечаются как пригодные для повторного использования. Команда VACUUM FULL удаляет из файла удаленные (и обновленные) строки, и строки помеченные как пригодные для повторного использования, то есть сжимает файл.
...
Рейтинг: 0 / 0
09.06.2004, 10:08
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32553982
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f_w_p
Участник
LeXa NalBatИспользует, но только после выполнения VACUUM, при котором удаленные (и обновленные) строки помечаются как пригодные для повторного использования. Команда VACUUM FULL удаляет из файла удаленные (и обновленные) строки, и строки помеченные как пригодные для повторного использования, то есть сжимает файл.
Ну вот и получается, что не использует. Размер файла БД уменьшается, а потом опять начинает расти. FB же повторно использует страницы данных и индексов, к-рые не используются. На этом основан один из методов повышения производительности. Это когда в БД заливают любые данные с целью увеличить размер файла до необходимой величины. Затем данные удаляют. И работают затем с полученным файлом БД. На некоторых файловых системах получается выигрыш в производительности.
...
Рейтинг: 0 / 0
09.06.2004, 12:38
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554041
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
f_w_pРазмер файла БД уменьшается, а потом опять начинает расти http://detail.phpclub.net/store/html/postgresql/node3.htmlVACUUM FULL (VACUUM до 7.2) пытается удалить все старые версии записей и, соответственно, уменьшить размер файла, содержащего таблицу. Этот вариант команды полностью блокирует обрабатываемую таблицу.
VACUUM (начиная с 7.2) помечает место, занимаемое старыми версиями записей, как свободное (см. также пункт 2.3). Использование этого варианта команды, как правило, не уменьшает размер файла, содержащего таблицу, но позволяет не дать ему бесконтрольно расти, зафиксировав на некотором приемлемом уровне. При работе VACUUM возможен параллельный доступ к обрабатываемой таблице. то есть если не делать vacuum full, то размер файла уменьшаться не будет. autovacuum же делает периодический vacuum (основанный на активности в базе данных), afaik это приблизительно соответствует поведению fb
...
Рейтинг: 0 / 0
09.06.2004, 12:59
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554045
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
f_w_pНу а способы борьбы с замедлением во время сборки мусора известны. интересно, какие?

ps: vacuum (без full) и есть такая сборка мусора.
...
Рейтинг: 0 / 0
09.06.2004, 13:01
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554061
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
f_w_pНу вот и получается, что не использует. Размер файла БД уменьшается, а потом опять начинает расти.

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

Именно поэтому в одной из используемых у нас БД (данные в ней обновляются ежедневно целиком) делаем ежедневно VACUUM. При этом база занимает на диске в два раза больше места, чем требуется. Но в скорости процедуры обновления данных имеем выигрыш (за счет того, что INSERT добавляет данные в пустое место в середину db-файла, а не в конец db-файла одновременно с увеличением его размера). Раз в месяц все же делаем VACUUM FULL - возможно для устранения каких-нибудь утечек. :)
...
Рейтинг: 0 / 0
09.06.2004, 13:09
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554072
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
P.S.: VACUUM, VACUUM FULL и VACUUM ANALYZE можно, по-моему, считать тремя разными командами.
...
Рейтинг: 0 / 0
09.06.2004, 13:13
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554241
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f_w_p
Участник
LeXa NalBatP.S.: VACUUM, VACUUM FULL и VACUUM ANALYZE можно, по-моему, считать тремя разными командами.
Ну вот теперь разъяснили. Похоже они ведут себя одинаково. Тогда не понятна проблема автора топика. Никакого замедления не д.б.
...
Рейтинг: 0 / 0
09.06.2004, 14:08
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554370
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
f_w_pТогда не понятна проблема автора топика. Никакого замедления не д.б.
Проблема-то как раз понятна, до версии 7.4 могли распухать файлы индексов, и время от времени надо было делать REINDEX.
...
Рейтинг: 0 / 0
09.06.2004, 14:42
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554375
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
f_w_pТогда не понятна проблема автора топика. Никакого замедления не д.б.

Я не нашел, чтобы Marina_R жаловалась на замедление.

От раздражающего периодического вызова VACUUM можно попытаться избавиться с помощью появившегося в версии 7.4 autovacuum. От увеличения размера индексов, как посоветовал Sad Spirit - путем переехода с версии 7.3 на 7.4.
...
Рейтинг: 0 / 0
09.06.2004, 14:44
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32554468
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
Marina_RОчень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени. а что конкретно не нравится?
...
Рейтинг: 0 / 0
09.06.2004, 15:11
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32556391
Marina_R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Marina_R
Гость
eddie Marina_RОчень раздражает необходимость запускать VACUUM - сначала делали это раз в день, потом перешли на раз в час - все равно занимает много времени. а что конкретно не нравится?
Время, ресурсы...
И порой нестабильность самой системы во время этого процесса.

По мне - запихать скрипт в крон и пусть себе бежит - никакой проблемы.
...
Рейтинг: 0 / 0
10.06.2004, 15:11
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32556937
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
время - так эта же фоновая операция

ресурсы - по мне делать vacuum analyze каждый час это слишком... врдяли данные так часто кардинально меняются, чтобы надо было пересобирать статистику. имхо лучший вариант - каждый час (или в зависимости от нагрузки даже чаще) просто vacuum и раз в сутки vacuum full analyze
...
Рейтинг: 0 / 0
10.06.2004, 18:17
| Ответить | Цитировать | Написать  
MySql vs PostgreSql again
    #32556940
eddie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
eddie
Участник
насчет стабильности - надо разбираться, вполне возможно железо не выдерживает повышенной нагрузки
...
Рейтинг: 0 / 0
10.06.2004, 18:18
| Ответить | Цитировать | Написать  
30 сообщений из 30, показаны все 2 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / MySql vs PostgreSql again
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]