Re: BDR, 9.4 release schedule, PostgreSQL inAzure, pgPool-II

Поиск
Список
Период
Сортировка
От Тарас Савчук
Тема Re: BDR, 9.4 release schedule, PostgreSQL inAzure, pgPool-II
Дата
Msg-id A2530EEBE32D30489F836E3816E9631343E2B6F5@EXCH.o.1adm.ru
обсуждение исходный текст
Ответ на Re: [pgsql-ru-general] BDR, 9.4 release schedule, PostgreSQL in Azure, pgPool-II  (Warstone@list.ru <warstone@list.ru>)
Список pgsql-ru-general

Спасибо!

 

Предполагаемая нагрузка абсолютно не ясна, но есть серьезная вероятность того, что расти нужно будет шустро. Что понятно сейчас – никаких тяжелых/сложных запросов не будет и нагрузка на 95%+ по чтению.

 

По железу смотрим на два варианта на старте:

- пара железяк в Hetzner (Intel Xeon 6 ядер + 2xSSD RAID-1),

- Azure (2 vm под БД, 2 vm под фронты).

Первый вариант дешев, второй дает возможность расти быстро и по мере надобности.

 

Скалиться, как уже сказал, нужно будет в большей степени по чтению, т.е. подошла бы обычная репликация. Но тут беда, что вкусный azure на другом проекте уже несколько раз за последнее время плохо себя вел с отдельно взятыми VM. Т.е. хочешь в azure – имей несколько инстансов в одном availability set, тогда они гарантируют, что ребутать/обновлять/т.п. одновременно железо/софт под инстансами не будут не будут и что разместят разные VM на разных стойках/серверах/коммутаторах/etc. А со стандартной репликацией PostgreSQL разруливать пропадание мастера в произвольный момент времени как-то печально. Т.е. сейчас не столько борьба за производительность идет, сколько борьба за Azure )))

 

1.       Почитаю про Postgres-XC, спасибо.

2.       Ок.

3.       Это ясно, но тут по ситуации.

4.       Может быть одна база для нескольких фронтов. Общий смысл в том, что фронты добавляются по мере надобности и реплики БД тоже.

 

--
Савчук Тарас

 

From: Warstone@list.ru [mailto:warstone@list.ru]
Sent: Sunday, November 9, 2014 3:00 PM
To: Тарас Савчук
Cc: pgsql-ru-general@postgresql.org
Subject: Re: [pgsql-ru-general] BDR, 9.4 release schedule, PostgreSQL in Azure, pgPool-II

 

1) Нет. Лучше посмотрите на https://wiki.postgresql.org/wiki/Postgres-XC но только тогда, когда вам это надо будет.
2) Вот-вот.
3) Ничего не могу сказать кроме того, что Виртуализация для ПГ - это плохо. Никогда не играйтесь в виртуализацию, если можете.
4) pgBouncer и идея одной базы для одного фронта - порочна, ИМХО.

95% что вы занимаетесь преждевременной оптимизацией там, где это делать не надо. Что у вас с планируемой нагрузкой / железом?


Sun, 9 Nov 2014 10:56:18 +0000 от Тарас Савчук <taras@1adm.ru>:

Доброго дня всем!

 

Несколько вопросов от новичка.

 

1.       Использовал ли кто-нибудь BDR в бою (https://wiki.postgresql.org/wiki/BDR_Project)?

2.       Когда ~ ожидается релиз 9.4?

3.       Использовал ли кто-нибудь PostgreSQL в Azure и может ли дать какие-либо рекомендации?

4.       Правильно ли я понимаю, что ближайший аналог mysql-proxy – это pgPool-II (схема предельно проста – каждый фронт с кодом работает со своим экземпляром БД, а к другим идет только в случае проблем с собственным).

 

БД под довольно простое приложение. Желание использовать BDR диктуется возможностью масштабироваться в ширь на удобных по цена/качество инстансах и не морочиться ненадежностью отдельно взятых VM в Azure (т.е. в минимуме имеем две VM с PostgreSQL в одном availability set Azure).

 

Спасибо :)

 

--
Савчук Тарас

 

 

В списке pgsql-ru-general по дате отправления:

Предыдущее
От: Warstone@list.ru
Дата:
Сообщение: Re: [pgsql-ru-general] BDR, 9.4 release schedule, PostgreSQL in Azure, pgPool-II
Следующее
От: "Dmitry E. Oboukhov"
Дата:
Сообщение: Используются ли индексы при построении индексов?