Комментарии 32
Когда вам понадобится обновить данные в материализованном представлении с хранимым результатом, это можно будет сделать по требованию с помощью команды REFRESH.
К сожалению, отсутствие поддержки инкрементных обновлений сильно сужает область применения материализованных представлений в Postgres. На эту тему встретил разве что упоминание от Джоша Беркуса в одном из комментариев:
I believe that Kevin is still working on “incremental update” of Matviews. That’s not in the cards for 9.5, though, sadly.
Эх, ни слова о шардировании/партиционировании/федерализации :(
Вот презентация с последнего хайлоада на тему шардинга в постгресе. Вроде чета пилят, но пока это нескоро всё будет.
Мне бы на самом деле подошло какое-нибудь изкоробочное решение хотя бы для HA-кластера, а то все эти танцы с pgpool-II, пока что не внушают доверия
Мне бы на самом деле подошло какое-нибудь изкоробочное решение хотя бы для HA-кластера, а то все эти танцы с pgpool-II, пока что не внушают доверия
А о (полу)мертвых — или хорошо, или ничего. К сожалению, постгрес в этом плане относится к "типичному опнсорсу" — всё работает отлично, пока ты не пытаешься собрать кластер. Вот пара приколов из нашего опыта (мастер, один слейв, синхронная репликация):
- репликация синхронная, но чтение со слейва не всегда возвращает данные, которые только что были записаны на мастер
- хост со слейвом упал, мастер при попытке вставки строки возвращает ошибку, но строку вставляет и транзакцию коммитит.
Хотя может мы его готовим неправильно — настройка и администрирование кластера постгреса — это отдельная песня.
1) А она и не должна, репликация «отпускает» коммит когда логи доехали, а не когда они были применены, в 9,6 для этого появится remote apply michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-remote-apply
2) Есть такое, но для синхронной репликации крайне не рекомендуется иметь всего 1 машину, т.к. в случае её выпадения мастер «встанет колом»
При условии что у вас всего 2-е машины (мастер-слейв) и пункта 1 вопрос: вам точно нужна синхроная репликация?
2) Есть такое, но для синхронной репликации крайне не рекомендуется иметь всего 1 машину, т.к. в случае её выпадения мастер «встанет колом»
При условии что у вас всего 2-е машины (мастер-слейв) и пункта 1 вопрос: вам точно нужна синхроная репликация?
Нам нужно избежать потери данных, если НЛО внезапно похитит мастер-ноду. Мы рассчитывали, что синхронная репликация мастер-слейв с автоматическим переключением на слейв в read-only mode нам обеспечит целостность, отсутствие даунтайма и возможность выполнять часть запросов на слейве. А вы тут рассказываете, что это невозможно в принципе...
Замечу, что я не рассказываю что это невозможно, я обращаю ваше внимание на то, что работает репликация именно так. Если вы можете часть своих запросов выполнять на данных которые могут отставать — выполняйте, это частый сценарий.
На сколько сильно у вас отстает мастер при асинхронной репликации и зачем вы «связались» с синхронной при 2-х машинах?
На сколько сильно у вас отстает мастер при асинхронной репликации и зачем вы «связались» с синхронной при 2-х машинах?
Практически не отстает, но мы не хотим терять данные, вообще не хотим терять данные. Что хотелось бы иметь:
- после окончания коммита транзакции на мастере, она сразу видна на слейве. Т.е. можно балансировать селекты между обоими нодами
- при падении мастера слейв берет на себя нагрузку в read-only mode с нулевым даунтаймом и актуальными данными
- при падении слейва мастер продолжает работать
- при поднятии мастера обратно с актуальными данными репликация восстанавливается и нагрузка переключается на мастер.
- почему два хоста? потому, что нужен-то мастер-слейв и потому, что три хоста дороже, чем два.
Если это возможно сделать, пожалуйста посоветуйте как или ткните куда читать.
Все хотят чтоб «без разрыва», но, увы, пока в природе чуда которое сответствует вашим требованиям не существует.
Можно попробовать разобраться в проблеме.
1. «Балансировать селекты между нодами»
Постгрес, как и любая современная РСУБД, способен спокойно держать пару десятков тысяч OLTP-транзакций в секунду с достаточно среднего железа. Вам «селекты» нужно балансировать чтоб железо не простаивало или действительно есть потребность?
2. «почему два хоста? потому, что нужен-то мастер-слейв и потому, что три хоста дороже, чем два.»
«Мастер-слейв» не спасают вас от потери данных, truncate cascade в данном случае может превратить не 1, а 2-е машины в «тыкву» (синхронно или асинхронно он это сделает выбирать вам) посмотрите в сорону создания бекапов (PITR). Поэтому и ваше желание «вообще не терять данные» и «не дорого» — это взаимоисключающие понятия
По фейловеру можете посмотреть исходники Patroni, Stolon чтоб понять что там и как или попробовать использовать одно из решений
Можно попробовать разобраться в проблеме.
1. «Балансировать селекты между нодами»
Постгрес, как и любая современная РСУБД, способен спокойно держать пару десятков тысяч OLTP-транзакций в секунду с достаточно среднего железа. Вам «селекты» нужно балансировать чтоб железо не простаивало или действительно есть потребность?
2. «почему два хоста? потому, что нужен-то мастер-слейв и потому, что три хоста дороже, чем два.»
«Мастер-слейв» не спасают вас от потери данных, truncate cascade в данном случае может превратить не 1, а 2-е машины в «тыкву» (синхронно или асинхронно он это сделает выбирать вам) посмотрите в сорону создания бекапов (PITR). Поэтому и ваше желание «вообще не терять данные» и «не дорого» — это взаимоисключающие понятия
По фейловеру можете посмотреть исходники Patroni, Stolon чтоб понять что там и как или попробовать использовать одно из решений
инкрементальные бэкапы — это всё замечательнои у нас они есть, но обязательное требование — автоматическая доступность базы при отказе одного хоста. И крайне желательно, чтобы при отказе мастера не пришлось потом руками медленно и печально восстанавливать недореплицированные данные. Неужели писать координатор самому — единственное решение?
Координатор при 2-х машинах достаточно ненужное решение.
При живом архиве на слейве можно/нужно указать restore_command на слейве,
в случае падения просто rsync'нуть недостающие wal'ы на слейв с мастера и сделать ему promote, если отставание не большое, как вы пишите, то это достаточно шустро, при синхронной rsync'аться не надо, но если данные важны то перепровериться стоит и, опять же, promote.
В любом случае вам нужно будет время на определение того что мастер «ушел» чтоб не переключаться на «каждый чих», а это даунтайм если ваше приложение не способно уходить в «RO» на слейв
PS: посмотрите еще repmgr, в последние дни его как ругают так и хвалят )
При живом архиве на слейве можно/нужно указать restore_command на слейве,
в случае падения просто rsync'нуть недостающие wal'ы на слейв с мастера и сделать ему promote, если отставание не большое, как вы пишите, то это достаточно шустро, при синхронной rsync'аться не надо, но если данные важны то перепровериться стоит и, опять же, promote.
В любом случае вам нужно будет время на определение того что мастер «ушел» чтоб не переключаться на «каждый чих», а это даунтайм если ваше приложение не способно уходить в «RO» на слейв
PS: посмотрите еще repmgr, в последние дни его как ругают так и хвалят )
Пусть меня закидают гнилыми помидорами, но не могу не сказать, что вижу много статей типа «Чем PostgreSQL лучше MySQL», но не видел, чтобы было наоброт… Видимо нет необходимости рекламировать то, что просто работает…
Может быть просто крыть нечем? Я работал и с той базой и с той, и могу сказать что практически нечем.
Читайте комментарии выше про кластеризацию. У меня из коробки стоит перконовский кластер и я даже в какой-то момент забыл, что он у меня есть, он просто работает, в то время как решение на pgpool (самое адекватное решение под постргрю) у нас так нормально и не заработало, всё что-то надо допиливать… За время работы с постгрёй я не увидел ни одного реального преимущество перед муськой, т.е. того, что в бою, при нормальной архитекруте, будет давать преимущества в скорости работы, разработке и т.п.
У нас тоже перконовский кластер мастер-мастер в работе, и я да я скажу что это круто — когда тебе не приходится пересоздавать мастер заново когда произошел свитч на слейв. Это плюс бесспорный из немногих.
На счет pgpool2 он у нас тоже не заработал, но зато заработал https://github.com/2ndQuadrant/repmgr, и прекрасно себя чувствует, там хоть что то автоматизировано в сравнении с голым постгрес. И все танцы с бубном вокруг фэйловинга и репликации как по мне покрываются Point In Time Recovery. Когда после сбоя потеря данных после восстановления минимальна, вплоть до нескольких секунд. Главное данные, а админы переживут. Один раз настроил и все работает.
Да конечно постгрес не для личного бложика на вордпрес, а для действительно серьезных проектов и относительно больших нагрузок. А там уже нет таких вопросов как — «Тут даже нет ничего из коробки?!!!»
На счет pgpool2 он у нас тоже не заработал, но зато заработал https://github.com/2ndQuadrant/repmgr, и прекрасно себя чувствует, там хоть что то автоматизировано в сравнении с голым постгрес. И все танцы с бубном вокруг фэйловинга и репликации как по мне покрываются Point In Time Recovery. Когда после сбоя потеря данных после восстановления минимальна, вплоть до нескольких секунд. Главное данные, а админы переживут. Один раз настроил и все работает.
Да конечно постгрес не для личного бложика на вордпрес, а для действительно серьезных проектов и относительно больших нагрузок. А там уже нет таких вопросов как — «Тут даже нет ничего из коробки?!!!»
Многи крупные проекты используют MySQL, тот же badoo, mamba, это очень большие проекты. Решает общая архитектура проекта, а не конкретный инструмент… Кстати, по скорости работы, залил геобазу maxmind в постгрю, поиск по IP-адресу около 40 мс против 2 мс на одной машинке, обе базы из коробки. Конечно, проводить такое сравнение не совсем корректно, но вот таких мелочей почему-то возникает много, когда с постгрёй реально приходиться бороться, а не просто использовать хороший, быстрый и функциональный инстурмент, о котором пишут в подобных статьях…
Я так понял 40мс — поиск в постгре, 2мс — поиск в мускуле? Это интересно, какое кол-во строк, индексы создавали? Если можете покажите план выполнения, пожалуйста (для постгрес добавьте опцию ANALYZE).
Строк было под 4М. Таблица была простая — ip_from, ip_to, location_id. В начале использовалось поле inet, потом cidr, потом переделал под целое число, но скорость выросла незначительно. В MySQL использовались целые числа. Индекс использовался составной по полям ip_from и ip_to. План не могу дать, база с данными не сохранилась.
Честно говоря, не знаю откуда у вас такие цифры по поводу времени выполнения запроса вообще. Создал базу с тремя полями, два BIGINT, одно VARCHAR. Заполнил числами от 111111111111 до 111121111111, и того 10М. Создал составной индекс. Итого:
1. При запросе с выборкой небольшого диапазона, где планер использует индекс: постгрес — avg 0.2 ms, мускуль — avg 0.3 ms. на 10 запросах.
2. При запросе очень большого диапазона, где планер решает использовать последовательное сканирование вместо индекса: постгрес — примерно 2 секунды, мускуль — 19 секунд.
Тесты конечно же чисто для примера. И в запросах где используется индекс разницы практически нет, но при Seq Scan, разница огромная и я честно говоря не знаю с чем это связано.
Все тесты проводились с настройками из коробки и ничего не подкручено.
1. При запросе с выборкой небольшого диапазона, где планер использует индекс: постгрес — avg 0.2 ms, мускуль — avg 0.3 ms. на 10 запросах.
2. При запросе очень большого диапазона, где планер решает использовать последовательное сканирование вместо индекса: постгрес — примерно 2 секунды, мускуль — 19 секунд.
Тесты конечно же чисто для примера. И в запросах где используется индекс разницы практически нет, но при Seq Scan, разница огромная и я честно говоря не знаю с чем это связано.
Все тесты проводились с настройками из коробки и ничего не подкручено.
Возможно я где-то допустил ошибку, сейчас нет возможности повторить эксперимент. Помню, что достаточно долго копался.
При Seq Scan, очевидно, что последовательное сканирование на больших диапазонах будет быстрее, так как не требует обращения к индексу и последовательное чтение данных из файла быстрее рандомного. Даже если индекс в памяти и планировщик пытается оптимизировать доступ к данным, чтобы он был максимально последовательным, всё равно последовательное чтение может давать существенный выигрыш. Зависит от распределения данных и их типа…
При Seq Scan, очевидно, что последовательное сканирование на больших диапазонах будет быстрее, так как не требует обращения к индексу и последовательное чтение данных из файла быстрее рандомного. Даже если индекс в памяти и планировщик пытается оптимизировать доступ к данным, чтобы он был максимально последовательным, всё равно последовательное чтение может давать существенный выигрыш. Зависит от распределения данных и их типа…
В подобных ситуациях проблема постгреса не в отсутствии кластера, а в настройках по умолчанию )
У нас тоже перконовский кластер мастер-мастер в работе, и я да я скажу что это круто — когда тебе не приходится пересоздавать мастер заново когда произошел свитч на слейв. Это плюс бесспорный из немногих.
С момента появления pg_rewind в постгресе тоже не обязательно пересоздавать мастер заново когда произошел свитч на слейв.
Если честно, то самое реальное преимущество PostgreSQL которое даст «скорость работы, разработке и т.п» — это отдавать большую часть работы на сторону СУБД за счет большей поддержки SQL и, конечно, PL/pgSQL, но это, по разным причинам, не для всех. Плюсом ко всему в современном многоядерном/многопроцессорном мире Postgres со своей «процессной моделью» гораздо лучше масштабируется по ядрам/физическим процессорам. Я вас не призываю к использованию Postgres, кто-то испытывает боль при работе с ним, кто-то с другим решением, но сравнивать Postgres и MySQL достаточно тупиковое решение — они очень разные
Вот например наоборот
habrahabr.ru/post/268949
Спойлер: всё равно получилось «Чем PostgreSQL лучше MySQL»
habrahabr.ru/post/268949
Спойлер: всё равно получилось «Чем PostgreSQL лучше MySQL»
Да PostgreSQL против MySQL — это как MAC против Windows или Desktop Linux. Но вот когда нужна большая горизонтальная мастабирумость то адекватного решения для создания кластера просто не существует. Единственное, что более менее похоже на зачатки нормальной кластеризации это PostgreSQL BDR. Но в ней нет самого необходимого, тех же последовательностей в масштабах кластера. Хотя MySQL Galera Cluster работает по принципу поставил и забыл (почти). Надеемся разработчики наконец-то допилят кластеризации, а то как большая столовая ложка дегтя в стакане меда.
вопрос — если это перевод, то где ссылка на оригинал? (в т.ч. на оригинал первой части)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 2