Ну, вроде б мой побыстрее должен быть. Вопрос только в том, существенно или нет. Релиз на носу, экспериментировать немного боязно. Я проверю ваш способ при первой возможности.
Отличная идея, спасибо!
Но в моем случае это менее предпочтительно, т.к. скрипт инсертит за каждый свой запуск довольно много строк (и предполагается увеличение), так что придется делать так, как я описал в статье. Ну, для полной автоматизации, можно также скрипт, который таблицы создает, в крон засунуть:)
По constraint_exclusion = ON вы правы. У меня так и есть, но вот забыл об этом упомянуть. Сейчас подредактирую.
У меня как раз версия 9.0.4 (в статье это указано). Это просто была цитата из книги.
Спасибо за ссылки, обязательно изучу этот материал. На данный момент скрость работы БД меня вполне устраивает, но как только появится необходимость, буду тюнить дальше. Тогда, возможно, появится вторая часть статьи.
Руководствовался следующими соображениями: если индексы и логи пропадут в случае поломки, ну ладно:) — это не критично для данных. Индексы можно завести вновь. А вот поломка дисков с разделами, где система с постгре и таблицы с данными — это критично, поэтому их на разделы с зеркалированием.
А вот логи и постгре на одном разделе хранить, мне кажется не айс, т.к. диску придется по очереди читать то одно, то другое.
Конечно, если подходить к вопросу более педантично, нужно было бы замерять. Но совершенно точно могу сказать, что ускорение производительности очень существенное. Статистика за сутки строится секунд за 5 максимум (и тормозится уже прострением графика, а не выборкой из БД), при том что размер мастер-таблицы перешагнул за 100млн записей. До произведенных действий по разгону скрипт работал минут 20 и выходил по таймауту.
Первоначально эти рекомендации и мне принесли неплохое ускорение. Но на больших запросах постгре захлебывался, оперативки под один процесс понадобилось больше, чем 1/8 от всего объема.
А это и есть книга Алексея Васильева «Работа с Postgresql. Настройка, масштабирование», которая упоминается в моей статье. Также я написал, почему не согласен с некоторыми параметрами.
Рад был оказаться полезным.
Несмотря на то, что с MySQL знаком намного дольше, чем с PostgreSQL, пока не приходилось сталкиваться с проблемой высокой нагрузки. Могу лишь сказать, что партицирование для нее будет организовать удобнее, т.к. механизм партицирования реализован на уровне БД.
К сожалению, не могу похвастаться, что разбираюсь. Только начинаю вникать во все это. Именно поэтому собираюсь посетить конференцию HighLoad++ по проблемам высконагруженных систем, которая пройдет в октябре в Москве. Надеюсь, постгресятников там будет поболее, чем двое:)
Но в моем случае это менее предпочтительно, т.к. скрипт инсертит за каждый свой запуск довольно много строк (и предполагается увеличение), так что придется делать так, как я описал в статье. Ну, для полной автоматизации, можно также скрипт, который таблицы создает, в крон засунуть:)
По constraint_exclusion = ON вы правы. У меня так и есть, но вот забыл об этом упомянуть. Сейчас подредактирую.
Спасибо за ссылки, обязательно изучу этот материал. На данный момент скрость работы БД меня вполне устраивает, но как только появится необходимость, буду тюнить дальше. Тогда, возможно, появится вторая часть статьи.
Спасибо за мнение. Мне так даже удобнее — дописать пару строчек в конфиг, чем ядро компилить.
А вот логи и постгре на одном разделе хранить, мне кажется не айс, т.к. диску придется по очереди читать то одно, то другое.
P.S. А если перспектива с обновлением не грозит, тогда какой вариант изменения параметров предпочтете вы?
Коллеги, которые наплюсовали к данному посту, не стесняемся, высказываем свое мнение;)
Несмотря на то, что с MySQL знаком намного дольше, чем с PostgreSQL, пока не приходилось сталкиваться с проблемой высокой нагрузки. Могу лишь сказать, что партицирование для нее будет организовать удобнее, т.к. механизм партицирования реализован на уровне БД.