Кластер PostgreSQL

юзкейсы, описание, циферки...

// wbr

> юзкейсы, описание, циферки...

ps: я не ставлю под сомнение рекомендацию. но подача.. написал бы хоть чуть больше - что где когда. чтоб хоть было что почитать. а то ведь кому и корова невеста.

// wbr

Вся обычная функциональность PostgreSQL плюс возможности кластеризации, репликации и разделения нагрузки.. Для тех, кто в курсе, описывать особенно нечего, для тех же, кто не в теме, это, в любом случае, интереса представлять не будет.. Сайт проэкта, со всей необходимой информацией тут - http://www.postgresql.at/english/pr_cybercluster_e.html

это что-то вроде PgBouncer, PL/Proxy, Londiste/Slony только из коробки и все вместе ?

Немного лучше.. Всё вышеперечисленное тобой плюс достаточно проработанная реализация Multi-master replication.. Что-то подобное проекту Postgres-R. Не Oracle RAC конечно, но тоже неплохо.

> Вся обычная функциональность PostgreSQL плюс возможности кластеризации, репликации и разделения нагрузки.. Для тех, кто в курсе, описывать особенно нечего, для тех же, кто не в теме, это, в любом случае, интереса представлять не будет..

ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?

> Сайт проэкта, со всей необходимой информацией тут - http://www.postgresql.at/english/pr_cybercluster_e.html

ну хоть на этом спасибо..

// wbr

>ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?

Сообщение это было помещено для заинтересованных в данном вопросе людей, если таковые, вообще, найдутся.. Новостное оформление, с целью информативного представления , не являлось целью данного сообщения. Теперь немного понятнее?

PS. Всегда пожалуйста и помните, что вам никто и ничем не обязан.

> ну спасибо, дорогой, уважил.

Всё в порядке?

> Всё в порядке?

вполне. я лишь думал, что автор найдёт время и желание раскрыть тему. при грамотном подходе это было бы небесполезно читателям. но по каким то причинам этого не случилось. ну и ладно. в конце концов, как было верно замечено, никто ничем никому не обязан.

// wbr

Дедовщина на лоре, хм.

>>ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?

> Сообщение это было помещено для заинтересованных в данном вопросе людей, если таковые, вообще, найдутся.. Новостное оформление, с целью информативного представления , не являлось целью данного сообщения. Теперь немного понятнее?

полный бред все равно. "оформление не являлось целью сообщения", шиза какая-то. можно подумать что часто бывают сообщения, цель которых - оформление.

Впрочем, и на сайте продукта не лучше - обещают "synchrone mulitmaser replication" (sic!). Продукт настолько крут что попробовавшие его лишаются дара речи? :-))

слазал внутрь. Итого, имеем:

- базируется на 8.3.0

- каждая нода имеет копию всего, похоже предусмотрен какой-то процесс перезаливки всей бд тому кто отстал и умер

- load balancer (неясной степени продвинутости) поставляется в комплекте но вообще необязателен - можно и напрямую к нодам коннектиться.

- производится синхронная репликация (не понятно только, действительно ли нужно ждать *всех* или какой-то кворум)

- если обнаруживается конфликт, то одного из конфликтеров выкидывают из кластера

- неясно что реплицируется. оно использует термин "операции записи", логические это и или физические - не понять.

краткий пробег по исходникам составил впечатление что - они реплицируют INSERT/SELECT/UPDATE'ы (а как с недетерминированными штуками?) - есть сомнения что этот агрегат будет себя хорошо вести на больших БД.

вообще репликация какая-то в mysql-стиле... с кучей ограничений и граблей.

Вот и делов то всего.. Всего лишь не лениться и немного изучить тему..

>- базируется на 8.3.0

Последняя версия, да..

>- каждая нода имеет копию всего, похоже предусмотрен какой-то процесс перезаливки всей бд тому кто отстал и умер

Именно так.. В документации о том говорится.

>- load balancer (неясной степени продвинутости) поставляется в комплекте но вообще необязателен - можно и напрямую к нодам коннектиться.

Точно.. Там, вообщем то, довольно мало обязательных вещей.

>- производится синхронная репликация (не понятно только, действительно ли нужно ждать *всех* или какой-то кворум)

Что-то вроде того.. Никого ждать не надо.

>- если обнаруживается конфликт, то одного из конфликтеров выкидывают из кластера

В зависимости от того, что понимается под конфликтом..

>- неясно что реплицируется. оно использует термин "операции записи", логические это и или физические - не понять.

Реплицируется, практически, вся структура в совокупности с данными.

>вообще репликация какая-то в mysql-стиле... с кучей ограничений и граблей.

Так и есть.. Но, учитывая, довольно неважное состояние в данных областях у PostgreSQL даже подобная функциональность, будучи довольно грамотно реализованной, представляет собой неплохое такое достижение..

Возможно, ты можешь привести, в качестве примера, более грамотные альтернативы для PostgreSQL?

>>- базируется на 8.3.0

>Последняя версия, да..

в данный момент на postgresql.org 8.3.6 предлагают.

>>- производится синхронная репликация (не понятно только, действительно ли нужно ждать *всех* или какой-то кворум)

>Что-то вроде того.. Никого ждать не надо.

посмотри флешки с главной страницы. Синхронность тут в том и заключается что когда мы на одном узле завершили транзакцию, мы можем быть уверены что она принята и другими узлами (а не образовала конфликт с какой-то другой транзакцией). Иногда требование ожидания остальных нодов можно ослабить, если каким-то образом гарантировать отсутствие конфликтов (например, билеты на четные места продает только узел А, на нечетные - узел Б), но эта техника подходит только для простых транзакций и главное, ее в этом киберкластире не видно.

>>- неясно что реплицируется. оно использует термин "операции записи", логические это и или физические - не понять.

> Реплицируется, практически, вся структура в совокупности с данными.

я имел ввиду не "реплику чего поддерживают" а "какие объекты пересылают" - целые SQL-команды (и тогда вызов хранимой процедуры будет повторяться всеми узлами, здравствуйте баги с недетерминированным выполнением), элементарные операции над записями (что-то вроде потока команд INSERT/UPDATE/DELETE ... WHERE primary_key=... , наверно разумный компромисс), или команды блоковых устройств (на странице номер N поменять байты M1...M2 на [0x1354245....], объем гоняемых данных превысит самые смелые ожидания:)

> Возможно, ты можешь привести, в качестве примера, более грамотные альтернативы для PostgreSQL?

увы нет, я сам с *кластерами* на PG не возился. самому было бы интересно услышать сравнение этой системы со Slony (вроде так она называется), и тем чем пользуются в skype (они вроде хвастались что у них что-то распределенное на постгресе).