ps: я не ставлю под сомнение рекомендацию. но подача.. написал бы хоть чуть больше - что где когда. чтоб хоть было что почитать. а то ведь кому и корова невеста.
Вся обычная функциональность PostgreSQL плюс возможности кластеризации, репликации и разделения нагрузки.. Для тех, кто в курсе, описывать особенно нечего, для тех же, кто не в теме, это, в любом случае, интереса представлять не будет.. Сайт проэкта, со всей необходимой информацией тут - http://www.postgresql.at/english/pr_cybercluster_e.html
Немного лучше.. Всё вышеперечисленное тобой плюс достаточно проработанная реализация Multi-master replication.. Что-то подобное проекту Postgres-R. Не Oracle RAC конечно, но тоже неплохо.
> Вся обычная функциональность PostgreSQL плюс возможности кластеризации, репликации и разделения нагрузки.. Для тех, кто в курсе, описывать особенно нечего, для тех же, кто не в теме, это, в любом случае, интереса представлять не будет..
ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?
>ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?
Сообщение это было помещено для заинтересованных в данном вопросе людей, если таковые, вообще, найдутся.. Новостное оформление, с целью информативного представления , не являлось целью данного сообщения. Теперь немного понятнее?
PS. Всегда пожалуйста и помните, что вам никто и ничем не обязан.
вполне. я лишь думал, что автор найдёт время и желание раскрыть тему. при грамотном подходе это было бы небесполезно читателям. но по каким то причинам этого не случилось. ну и ладно. в конце концов, как было верно замечено, никто ничем никому не обязан.
>>ну спасибо, дорогой, уважил. зачем тогда вообще писал не понимаю :-?
> Сообщение это было помещено для заинтересованных в данном вопросе людей, если таковые, вообще, найдутся.. Новостное оформление, с целью информативного представления , не являлось целью данного сообщения. Теперь немного понятнее?
полный бред все равно. "оформление не являлось целью сообщения", шиза какая-то. можно подумать что часто бывают сообщения, цель которых - оформление.
Впрочем, и на сайте продукта не лучше - обещают "synchrone mulitmaser replication" (sic!). Продукт настолько крут что попробовавшие его лишаются дара речи? :-))
краткий пробег по исходникам составил впечатление что
- они реплицируют INSERT/SELECT/UPDATE'ы (а как с недетерминированными штуками?)
- есть сомнения что этот агрегат будет себя хорошо вести на больших БД.
вообще репликация какая-то в mysql-стиле... с кучей ограничений и граблей.
Вот и делов то всего.. Всего лишь не лениться и немного изучить тему..
>- базируется на 8.3.0
Последняя версия, да..
>- каждая нода имеет копию всего, похоже предусмотрен какой-то процесс перезаливки всей бд тому кто отстал и умер
Именно так.. В документации о том говорится.
>- load balancer (неясной степени продвинутости) поставляется в комплекте но вообще необязателен - можно и напрямую к нодам коннектиться.
Точно.. Там, вообщем то, довольно мало обязательных вещей.
>- производится синхронная репликация (не понятно только, действительно ли нужно ждать *всех* или какой-то кворум)
Что-то вроде того.. Никого ждать не надо.
>- если обнаруживается конфликт, то одного из конфликтеров выкидывают из кластера
В зависимости от того, что понимается под конфликтом..
>- неясно что реплицируется. оно использует термин "операции записи", логические это и или физические - не понять.
Реплицируется, практически, вся структура в совокупности с данными.
>вообще репликация какая-то в mysql-стиле... с кучей ограничений и граблей.
Так и есть.. Но, учитывая, довольно неважное состояние в данных областях у PostgreSQL даже подобная функциональность, будучи довольно грамотно реализованной, представляет собой неплохое такое достижение..
Возможно, ты можешь привести, в качестве примера, более грамотные альтернативы для PostgreSQL?
в данный момент на postgresql.org 8.3.6 предлагают.
>>- производится синхронная репликация (не понятно только, действительно ли нужно ждать *всех* или какой-то кворум)
>Что-то вроде того.. Никого ждать не надо.
посмотри флешки с главной страницы. Синхронность тут в том и заключается что когда мы на одном узле завершили транзакцию, мы можем быть уверены что она принята и другими узлами (а не образовала конфликт с какой-то другой транзакцией). Иногда требование ожидания остальных нодов можно ослабить, если каким-то образом гарантировать отсутствие конфликтов (например, билеты на четные места продает только узел А, на нечетные - узел Б), но эта техника подходит только для простых транзакций и главное, ее в этом киберкластире не видно.
>>- неясно что реплицируется. оно использует термин "операции записи", логические это и или физические - не понять.
> Реплицируется, практически, вся структура в совокупности с данными.
я имел ввиду не "реплику чего поддерживают" а "какие объекты пересылают" - целые SQL-команды (и тогда вызов хранимой процедуры будет повторяться всеми узлами, здравствуйте баги с недетерминированным выполнением), элементарные операции над записями (что-то вроде потока команд INSERT/UPDATE/DELETE ... WHERE primary_key=... , наверно разумный компромисс), или команды блоковых устройств (на странице номер N поменять байты M1...M2 на [0x1354245....], объем гоняемых данных превысит самые смелые ожидания:)
> Возможно, ты можешь привести, в качестве примера, более грамотные альтернативы для PostgreSQL?
увы нет, я сам с *кластерами* на PG не возился. самому было бы интересно услышать сравнение этой системы со Slony (вроде так она называется), и тем чем пользуются в skype (они вроде хвастались что у них что-то распределенное на постгресе).