Comments 28
Интересно было бы посмотреть на результат теста с джойном таблиц, целиком расположенных на разных нодах, или с джойном таблиц, размазанных по нескольким нодам.
Добавил пример с объединением размазанных таблиц. А разносить таблицы по разным узлам, чтоб потом их потом сджойнить смысла не вижу.
Собственно, если бы в статье не было утверждения
Так что вопрос остается открытым.
Для клиента, который подключается в базе, нет никакой разницы, работает он с единственным инстансом PostgreSQL или с кластером Postgres-XL, то я бы не так настаивал :)
А разносить таблицы по разным узлам, чтоб потом их потом сджойнить смысла не вижуЭто не совсем корректный тезиз. Вы нормализовывали базу как раз для того, чтобы потом можно было собирать данные любым необходимым образом. Более того, по Вашей логике, вынести на отдельный сервер можно только таблицу, на которую гарантированно никто не ссылается. А это либо странно для реляционной БД, либо это логически самостоятельное хранилище и тогда его спокойно можно подключить из приложения.
Так что вопрос остается открытым.
Завтра попробую — обязательно отпишусь о результатах.
Не могу придумать ситуацию в которой нужно было чтоб логически связанные таблицы находились на разных серверах. Имеет смысл или размазывать все таблицы или часть из них, а часть реплицировать.
Не могу придумать ситуацию в которой нужно было чтоб логически связанные таблицы находились на разных серверах. Имеет смысл или размазывать все таблицы или часть из них, а часть реплицировать.
Результат для джойна таблиц с разных узлов такой же, как и для распределенных. Ожидал несколько худшего результата, может что-то не учел в процессе тестирования
Вы писали, что это горизонтальное масштабирование. Что-то его у вас мало в статье )
Обычной репликацией удивить сложно.
Обычной репликацией удивить сложно.
Больше интересно когда они уже ядро то актуализируют до 9.3 хотябы =) а так отличное решение…
Postgres-XC, GridSQL, Stado, StormDB, Postgres-XL настоящий зверинец!!!)))
Вообще уважаю проект Postgres! Это моя первая БД в коммерческой разработке ПО, гибкость, конфигурируемость, огромное число модулей, технологий и огромное комьюнити
Вообще уважаю проект Postgres! Это моя первая БД в коммерческой разработке ПО, гибкость, конфигурируемость, огромное число модулей, технологий и огромное комьюнити
Вроде бы предком проекта был Postgres-XC
Global Transaction Manager(GTM) and some of coordinator are equipped with Infiniband connection to be used when Gigabit network is not sufficient(стр. 24)
Global Transaction Manager(GTM) and some of coordinator are equipped with Infiniband connection to be used when Gigabit network is not sufficient(стр. 24)
Интересно узнать число запросов в секунду на изменение у автора. По моему опыту, для большинства больших проектов хватает связки: 1 мастер + много слэйвов на чтение (pgbouncer + haproxy + ospf).
Я к тому, что у меня в «хозяйстве» есть кластер, у которого постоянных 6к транзакций в секунду. При этом, примерно 400 туплей в секунду пишется на мастер. Это 4 сервера, по 8 ядер на каждом, 64 ГБ оперативки и хорошие Intel SSD в зеркале (400 ГБ dataset на каждой ноде).
Интересна статистика автора.
Интересна статистика автора.
Мастер + слейв спасают от большой нагрузки, но не от больших данных. Тут и приходит шардинг на Postgres-XL, как я понимаю.
Подскажите, верно ли я понимаю, что у постгреса или какого-то его расширения есть функциональность, которая позволяет выбрать по некоторому условию данных из таблицы, которая «размазана» по разным узлам?
веселье начинается с момента когда отвалилась нода с данными и надо ее вернуть на место.
ноды с данными нужно реплицировать же :)
Про какую репликацию вы говорите? Репликацию таблиц в XL/XC или нативную потоковую репликацию что изначально есть в постгресе?
Если про первое, то имхо это вобще сомнительная идея (с точки зрения производительности) держать копию таблицы на всех узлах кластера. Если про второе (подпирать каждую датаноду своим стендбаем), то тут репликация совсем не гарантирует консистентность (т.к. нет нативного мониторинга отвалов нод и авто-файловеров) особенно при шардинге таблиц.
Если про первое, то имхо это вобще сомнительная идея (с точки зрения производительности) держать копию таблицы на всех узлах кластера. Если про второе (подпирать каждую датаноду своим стендбаем), то тут репликация совсем не гарантирует консистентность (т.к. нет нативного мониторинга отвалов нод и авто-файловеров) особенно при шардинге таблиц.
Автор приводит в пример в качестве балансировщика нагрузки pgpool-II. В связи с этим, у меня возникают сомнения в том, что автор видел большой highload в PostgreSQL. По моему опыту, эта программа (pgpool-ii) перестаёт нормально работать уже на 100 транзакциях в секунду: просто тормозит, жрёт процессор и плохо реагирует на сигналы. Например, при такой нагрузке, рестарт pgpool-ii приходилось делать с помощью kill -9. Уверяю, pgpool-ii был максимально затюнен под нужную производительность.
А Вы давно pgpool пользовали? Спрашиваю потому что, в продакшине используем именно его и никаких нареканий не было (нагрузка 1000 tps). Я так понимаю, что в качестве альтернативы Вы предлагаете pgbouncer и haproxy?
У меня есть базюлька, где он и сейчас раскидывает читающие запросы на слэйвы, а пишущие на мастер. Дистрибутив где-то годовалой свежести.
Разговаривал на конференции по постгресу в яндексе с человеком, который работает в крупном интеграторе (коммитеры в postgres): он тоже говорит, что pgpool — ужасная программа, и они тоже используют pgbouncer + haproxy.
Разговаривал на конференции по постгресу в яндексе с человеком, который работает в крупном интеграторе (коммитеры в postgres): он тоже говорит, что pgpool — ужасная программа, и они тоже используют pgbouncer + haproxy.
Если уж это решение горизонтально масштабируемое, то интересно:
— как оно ведет себя при добавлении узлов (при никуда не пропадающей нагрузке на запись);
— есть ли decommissioning координаторов и узлов с данными;
— есть ли ребалансировка шард при изменении количества узлов (ручная или автоматическая)?
Кроме того, исходя из статьи возможности крутить фактор репликации нет, что выглядит в общем случае странно, если надо масштабироваться на более чем 3 узла.
— как оно ведет себя при добавлении узлов (при никуда не пропадающей нагрузке на запись);
— есть ли decommissioning координаторов и узлов с данными;
— есть ли ребалансировка шард при изменении количества узлов (ручная или автоматическая)?
Кроме того, исходя из статьи возможности крутить фактор репликации нет, что выглядит в общем случае странно, если надо масштабироваться на более чем 3 узла.
Спасибо за пост, очень интересно.
А есть данные как себя ведет Postgres-XL при работе в разных сетях (разных ЦОДах, разных стран) или он обязательно в одной локальной сети должен быть?
У нас например, в проекте (Cackle) используется потоковая репликация в разные дата-центры (http://habrahabr.ru/company/cackle/blog/255013/), но есть проблема слишком быстрого роста данных и в этом варианте Postgres-XL, как раз то, что надо, но интересно как он ведет себя в разных сетях, разных стран.
А есть данные как себя ведет Postgres-XL при работе в разных сетях (разных ЦОДах, разных стран) или он обязательно в одной локальной сети должен быть?
У нас например, в проекте (Cackle) используется потоковая репликация в разные дата-центры (http://habrahabr.ru/company/cackle/blog/255013/), но есть проблема слишком быстрого роста данных и в этом варианте Postgres-XL, как раз то, что надо, но интересно как он ведет себя в разных сетях, разных стран.
Нет, геораспределенные топологии не поддерживаются. Может имеет смысл посмотреть в сторону TransLattice Elastic Database (TED)
Интересно, почему не взлетел такой перспективный проект и давно заброшен?
Sign up to leave a comment.
Очень большой Postgres