https://opennet.ru/openforum/vsluhforumID3/114033.html Компания Citus Data опубликовала (https://www.postgresql.org/about/news/1845/) выпуск открытой распределённой СУБД CitusDB 7.3, которая поставляется в форме расширения к PostgreSQL, работающего поверх штатных выпусков PostgreSQL 9.6 и 10. CitusDB обеспечивает горизонтальное масштабирование PostgreSQL в кластере на базе типового оборудования, с разнесением данных по узлам при помощи партицирования и репликации. Для приложений кластер CitusDB выглядит как один большой сервер PostgreSQL, обладающий производительностью образующих его узлов. Код распространяется (https://github.com/citusdata/citus) под лицензией AGPLv3.<br><br><br><br><br>Партицирование даёт возможность организовать хранение очень большого объема данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера, а реплицирование на несколько узлов обеспечивает отказоустойчивость и позволяет сохранить работоспособность при выходе узлов из строя. Входящие запросы распараллеливаются по имеющимся серверам, позволяя добиться п https://opennet.ru/openforum/vsluhforumID3/114033.html#12 Fri, 27 Jul 2018 07:51:17 GMT Зачем было разносить базы по портам если они уже разнесены по адресам.<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#11 Mon, 09 Apr 2018 09:46:51 GMT Верно, но пока цены у них слишком высокие, надо торговаться. Стоит это дело дорого - 800$ в месяц за ноду, то есть 800 * 18 = 14400 долларов в месяц, с учетом 2-х координаторов, такую цену объявили после переписок, потом спросили сколько нас устроит, видимо поняв что дороговато, мы пока не отвечали. Например про купить разово лицензии речи не идет пока и потом платить например по 100$ в месяц за ноду.<br><br>За эти деньги проще сразу купить серверов и поставить на колокейшн допустим не 4, а 8 или 16 и развернуть на них *4 нод с данными, то есть 8x4 = 32 ноды на старте и потом их выносить как железо будет докупаться, или даже 16*4 = 64 ноды на старте. Но мы прикинули впринципе 16 серверов и 16 нод для всего проекта в будущем хватит с лихвой, чтобы вести детальную статистику и потом ежемесячно делать RENAME и создание новой таблицы, который как раз они реализовали для распределенных таблиц, по сути складывать как в архивные таблицы предыдущие данные. Так сами таблицы не будут раздуваться и SELECT будут быстрые, что https://opennet.ru/openforum/vsluhforumID3/114033.html#10 Mon, 09 Apr 2018 06:19:34 GMT Правильно я понимаю, что когда дорастёте до 16-ти серверов, можно уже и за коммерческий суппорт заплатить будет?<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#9 Mon, 09 Apr 2018 06:15:17 GMT спасибо за комментарий, но лучше бы вы его статьёй оформили (тут так можно), комментарий тяжело будет найти со временем<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#8 Sun, 08 Apr 2018 13:06:14 GMT Добавлю к примеру выше. Когда создаете распределенную таблицу запросом SELECT create_distributed_table('pgbench_history', 'aid') то 'aid' это имя столбца в таблице по которому и будет происходить шардирование данных, естесственно он должен быть уникальным. Он может быть по типам напрмиер bigint, uuid и еще каких-то типов, в документации описано, мы используем uuid.<br><br>Так же рекомендую почитать про reference_table в Citus - по сути это создание просто одинаковой таблицы на всех нодах с одинаковыми данными во всех нодах, то есть она реплицируется всегда на все ноды с данными. Может использоваться для того чтобы по ней JOIN делать с распределенными таблицами в определенных случаях.<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#7 Sun, 08 Apr 2018 11:49:54 GMT Великолепно. Поделился опытом, рассказал о хитростях. Если в комментариях к новостям хотябы по 1 такому комменту будет, то это просто праздник какой то.<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#6 Sun, 08 Apr 2018 09:03:52 GMT Сорри за очепятки, времени просто не было. Главное заранее создать базу cdr в 1-ом координаторе и на всех нодах с данными руками вначале, подключить extension citus в каждой ноде внутри каждой базы cdr. И только потом уже делать на 1-м координаторе SELECT * from master_add_node('172.21.1.51', 5433); и так далее опять же внутри базы cdr.<br> https://opennet.ru/openforum/vsluhforumID3/114033.html#5 Sun, 08 Apr 2018 08:54:50 GMT Да использую, хорошо работает, даже очень.<br>Основное ограничения Community Edition в том, что нельзя потом ребаланс данных сделать, елси добавляешь новые ноды.<br><br>На одном стартапе сделали так, чтобы обойти ограничение и не брать сразу 16 серверов:<br><br>Повесили по 4 IP адреса и создали по 4 ноды с данными на каждом физ. сервере из 4-х машин заранее. В дальнейшем при добавлении но, просто тушили ноду, снимали IP и копировали ее каталог с данными на другую машину, включали там со старым IP. Профит:<br><br>Пример настройки:<br><br>1 сервер. 4 ноды с данными + координатор (WAL репликация синхронная)<br>2 сервер. 4 ноды с данными + координатор slave (WAL репликация синхронная)<br>3 сервер. 4 ноды с данными<br>4 сервер. 4 ноды с данными<br><br>Итого 16 нод. Использовали встроенную Citus репликацию, а не WAL, так при отсутствии нод Citus продолжает работать. Между координаторами WAL синхронная для метаданных.<br><br>Базовая онфигурация 1-го и 2го сервера, WAL репликацию между координаторами тут не показываю. Для 3-го и 4-го сервера просто https://opennet.ru/openforum/vsluhforumID3/114033.html#4 Sat, 07 Apr 2018 17:32:09 GMT &gt; Кто-нибудь из здешних использует это?<br><br>в комментах к соседней новости про мандавошь-дб отметился пользовавший.<br>