Состоялся (http://www.postgresql.org/about/news/1662/) релиз СУБД Postgres-XL 9.5 R1 (http://www.postgres-xl.org/), основанной на технологиях PostgreSQL и предназначенной для создания кластерных систем, хорошо подходящих как для обработки транзакций в реальном времени (OLTP), так и для создания крупных баз для анализа больших наборов данных (решения для бизнес-аналитики). Код СУБД Postgres-XL распространяется под свободной лицензией Mozilla Public License 2.0.
Кодовая база нового выпуска Postgres-XL полностью синхронизирована с PostgreSQL 9.5.2 (https://www.opennet.me/opennews/art.shtml?num=43639). Новая версия также примечательна улучшением средств обеспечения высокой доступности и полной поддержкой таких расширенных возможностей, как индексы BRIN и сжатие индексов JSONB и GIN. Предоставляемые в Postgres-XL средства массивной параллельной обработки данных (MPP, Massively Parallel Processing) позволяют добиться почти линейного увеличения масштабируемости при выполнении многих видов запросов.
Например, при решении задач бизнес-аналитики 16-узловой кластер на базе Postgres-XL демонстрирует в 16 раз более высокую производительность по сравнению с отдельным сервером PostgreSQL и при этом успешно проходит BI-тесты TPC-H. При оценке производительности обработки транзакций в реальном времени (OLTP) при помощи теста pgBench 4-узловая конфигурация Postgres-XL по сравнению с одним сервером на базе PostgreSQL продемонстрировала рост обработки транзакций в секунду на 230% при увеличении задержек в 70% для типовых запросов SELECT. Для запросов UPDATE скорость обработки возросла на 130% при росте задержек на 56%.
Некоторые особенности СУБД Postgres-XL:
- Соответствие требованиям ACID (атомарность, согласованность, изолированность, надежность) на уровне всего кластера;
- Поддержка механизма многоверсионности для обеспечения одновременного конкурентного доступа к БД (MVCC);
- Распределённая модель хранения, при которой каждый узел хранит и обрабатывает отдельную порцию данных. При записи данные равномерно распределяются по разным узлам хранения, что позволяет более эффективно использовать кэширование и распределять нагрузку при чтении;
- Расширенная модель разграничения доступа, позволяющая организовать в рамках одного кластера несколько виртуальных СУБД, закреплённых за разными арендаторами (Multi-tenant);
- Поддержка большинства штатных возможностей PostgreSQL, в том числе средств работы с данными в формате JSON и hstore;
- Высокая масштабируемость - при необходимости наращивания размера базы или при увеличении нагрузки достаточно подключить новые узлы в кластер;
- Оптимизация кластера как для приложений с большой интенсивностью записи, так и для программ, в которых преобладают операции чтения;
- Средства обеспечения отказоустойчивости через развёртывание запасных узлов (slave), которые примут нагрузку в случае выхода из строя основного узла.
URL: http://www.postgresql.org/about/news/1662/
Новость: http://www.opennet.me/opennews/art.shtml?num=44278
И все так же под BSDL? круто
>Код СУБД Postgres-XL распространяется под свободной лицензией Mozilla Public License 2.0.Copyleft
интересно сравнить с галерой
Тролль!
Лучше с CitusDB сравнить...
Тогда уж с greenplum
Сравнительные характеристики как то не проливают свет на плюсы разработки. Хорошо бы, конечно,при таких сравнениях показатели делить на производительность машины.
Интересно, когда 1С научится с такой БД работать? И поможет ли ей это...
Хм... а чему тут "учиться"? Клиентская либа есть, бери, да соединяйся! Если только с дури они процедур не понаписякали.
Именно "с дури написякали"...
Постгре "из коробки" не работает с 1С... Только специально собранный с сайта 1С.
В продакшене с версии 9.2, больше года. 4-х узловой кластер в связке с CEPH. Полет нормальный. Несколько раз ложился GTM. Ничего при этом не разваливалось. Производитльность не линейная, КПД ноды в пределах 60-70 процентов.
Слушай, дай мануал по настройке такого кластера. А то у нас одмин только оффтопик знает.
https://habrahabr.ru/post/253017/
Ждем хотябы патчи для Postgres…Хотя что от Анонима можно ждать…
То ли дело балабол-регистрант без постгреса, но с нечеловеческим гонором.
> То ли дело балабол-регистрант без постгреса, но с нечеловеческим гонором.Вообще замечаю интересную вещь, анонимы весьма самокритичны, раз за разом себя описывают :)
ПыСы. Уже, наверное, года 2-3 SQL 1C крутиться полностью под FreeBSD, причем не разу не падая. Heimdal аутентификация и авторизация из OpenLDAP.
Пару раз останавливали для обновления.
1С ведь не использует силу логики SQL?! Они БД используют просто как пространство для хранения, а не связывания и обработки данных ...
Промахнулся веткой
Ага... А всякие отчеты рисуют индусы карандашами. И обработка данных происходит специально обученными неграми...эээ...то есть афроамериканцами...
Какие то глупости говорите. Рисует отчёты только обёртка 1с. В БД хранится мусор из метаданных. Приведите пример sql select'а для выбора документов созданных пользователем Иван. Гуглящие по данному вопросу будут вам благодарны в будущем.
Ух ты, отчеты обертка рисует.. а данные она откуда берет? из воздуха? В общем - не разбираетесь - не лезьте. Я мануал просил по настройке кластера.
И да - запрос будет выглядить примерно так "SELECT Док.Ссылка FROM ДокументСсылка.<ТипДокумента> КАК Док ГДЕ Док.Пользователь=&Пользователь";
И этот запрос 1С транслирует в SQL. Детский сад, ей богу... Или ты думаешь в SAP R3 все по другому?
> 1С ведь не использует силу логики SQL?! Они БД используют просто как
> пространство для хранения, а не связывания и обработки данных ...чем трынеть заглянул бы в созданную одинесом базу в постгресе.
Самое ужасное, что глядел. Там нет логики sql, там тупо одномерная связь безликих таблиц с матаданными. Т.е. невозможно оптимизировать скорость за счёт планирования sql запросов и структур.
Поддерживаю. Посему, платить за лицензию M$SQL/DB2 не вижу смысла... СУБД для 1Ски - этто всего лишь хранилище...
А CEPH зачем?
Ну CEPH то и выполняет задачи кластеризации. А поверх него тупо, торчат "ослиные уши" 4 обычных PostgreSQL. И этот колхоз, данный гражданин, кластером БД называет.
Детский сад.
а серп-то ему каким боком нужен вдруг? или ты дату на скрпе хранишь?
Господа, а в сравнении с Монго как?
Плохо. Очень плохо. Ужасно. Невыносимо.Невыносимо плохо и ужасно читать такие комментарии, как тот, на который я сейчас ответил.
Монго разваливается и не собирается, при первом удобном случае. Не кластер, а головная боль админа.
Господин, может ты четное количество нод поднял? 8)
Какой красивый риторический вопрос. Только не четное количество нод, а так да все верное.
Причем здесь я? Это общий момент администрирования Mongo кластеров и ее стресс-тестов.У суровых кластерных практиков Mongo как вариант вообще не обсуждается:
http://highscalability.com/all-posts/
Из FAQа PG XL:In terms of automatic failover, it is currently not part of the core project, but Corosync/Pacemaker has been used for this purpose.
Интересный расклад. С трудом верится, что оно может быть лучше Монго.
С трудом верится, что оно может быть лучше ОДНОПОТОЧНОЙ Монго? ))
У меня регулярно ест 800%
> Из FAQа PG XL:
> In terms of automatic failover, it is currently not part of the
> core project, but Corosync/Pacemaker has been used for this purpose.
> Интересный расклад. С трудом верится, что оно может быть лучше Монго.Получается что на равных. Проблемы развала при шардинге данных одинаково можно поиметь и там и там. Только в случае постгреса кроме JSON документов имеем еще и true SQL.
"true SQL" это конечно же ругательное слово? Тут в одном проекте в СУБД надо было дампить каталог в одного сайта, проникся schemaless-ностью NoSQL-ей. И скоростью (150-200 килоинсертов в сек при количестве записей за миллиард).
Господа все в париже
ещё в брюсель много прибывает
Нужно с MsSQL Server сравнивать
и как оно понимает как данные распределять? по каким то ключам которые ей задавать? что происходит при добавлении сервера в кластер? при удалении сервера из кластера? перераспределение данных? данные доступны в это время?
коннектится можно к любому серверу из кластера или только к какому то центральному?
http://files.postgres-xl.org/documentation/tutorial-createcl...
Оч сложно не осилил, картинки и бабы с bobs нужны на youtube.
Насчет кластеризации которую обеспечивает CEPH это смешно даже как то и непонятно что вы под этим имеете ввиду. В моей ситуации 4 узла данных, к которым подключены блочные устройтсва из ceph по 10Тб. 3 координатора , 2 менеджера транзакций и 2 прокси. Отказоустойчивость обеспечивается наличием резервных виртуальных машин и конфигурацией pacemaker/corosync которая в случае выпадения одного узла перемонтирует блочное устройтсво. С координаторами все проще задачу балансировки выполняет haproxy в tcp режиме. для резервирования Gtm используется тот же pacemaker с собсвенным скриптов котороый делает промойшен о новом гтм. Система планировалась с учетом 5000 транзакций в секунду и годовым ростом данных до 100Тб. Для разворачивания всего этого хозяйства есть стейты для saltstack. По типу распределения таблиц можно посмотреть официальный мануал. Если есть вопросы с удовольствием отвечу.
Чувствуется стиль хабра - "пришел, похвастался и ушол".. Люди, мануал дайте по поднятию такого чуда... Мануал, а не краткое описание того что сделано...
Вполне нормально расписано. Или вы хотите покопипастить в консольку для достижения счастья? Потом такая база пойдёт в продашен, а через год организация будет искать нормальных специалистов за кучу бабла чтобы починить "копипаст"-кластер...
Так а какой мануал, по официальной доке я все делал. на вопросы могу по скайпу или в почте ответить. + есть репозиторий с.deb пакетом с кастомным инит скриптом для запуска gtm proxy