The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]



"Доступна распределённая СУБД CitusDB 7.3"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от opennews (??) on 07-Апр-18, 14:08 
Компания 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.


Партицирование даёт возможность организовать хранение очень большого объема данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера, а реплицирование на несколько узлов обеспечивает отказоустойчивость и позволяет сохранить работоспособность при выходе узлов из строя. Входящие запросы распараллеливаются по имеющимся серверам, позволяя добиться предсказуемого времени выполнения запроса к большим массивам данных, пополняемым в режиме реального времени. Предлагается три планировщика выполнения запросов (router, real-time и task-tracker), позволяющих добиться оптимальных показателей при разном характере работы с данными (оперативная обработка  - низкие задержки или аналитика - высокая пропускная способность).


Основные новшества (https://www.citusdata.com/blog/2018/04/05/citus-7-3-broader-.../):


-  Поддержка сложных подзапросов при обработке данных, хранящихся на нескольких узлах кластера. В частности, над распределённым хранилищем теперь можно выполнять операции JOIN для слияния двух и более подзапросов к разным таблицам, добавлена поддержка всех видов подзапросов, допустимых в выражении WHERE, и возможность применения модифицирующих конструкций в выражениях WITH (CTE, Common Table Expression);

-  Расширение списка сложных агрегатных функций, которые допустимо использовать в кластере Citus. Добавлена поддержка json_agg, json_object_agg, jsonb_agg, jsonb_object_agg, bool_or, bool_and, bit_or и bit_and;

-  Возможность переименования распределённых на несколько узлов таблиц и индексов при помощи штатной конструкции "ALTER TABLE/INDEX ... RENAME TO ...", а также изменения параметров индексов командой "ALTER INDEX ... SET ...";
-  Возможность полноценной интеграции с системой бизнес-анализа Tableau (достаточно выбрать PostgreSQL в настройках Tableau для подключения к CitusDB);
-  Поддержка расширения TopN (https://www.opennet.ru/opennews/art.shtml?num=48359), позволяющего эффективно рассчитывать выборки наиболее популярных значений в записях.

URL: https://www.postgresql.org/about/news/1845/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48407

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Доступна распределённая СУБД CitusDB 7.3"  +1 +/
Сообщение от Аноним (??) on 07-Апр-18, 14:08 
Кто-нибудь из здешних использует это?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от . on 07-Апр-18, 20:32 
> Кто-нибудь из здешних использует это?

в комментах к соседней новости про мандавошь-дб отметился пользовавший.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Доступна распределённая СУБД CitusDB 7.3"  +9 +/
Сообщение от raver email(??) on 08-Апр-18, 11:54 
Да использую, хорошо работает, даже очень.
Основное ограничения Community Edition в том, что нельзя потом ребаланс данных сделать, елси добавляешь новые ноды.

На одном стартапе сделали так, чтобы обойти ограничение и не брать сразу 16 серверов:

Повесили по 4 IP адреса и создали по 4 ноды с данными на каждом физ. сервере из 4-х машин заранее. В дальнейшем при добавлении но, просто тушили ноду, снимали IP и копировали ее каталог с данными на другую машину, включали там со старым IP. Профит:

Пример настройки:

1 сервер. 4 ноды с данными + координатор (WAL репликация синхронная)
2 сервер. 4 ноды с данными + координатор slave (WAL репликация синхронная)
3 сервер. 4 ноды с данными
4 сервер. 4 ноды с данными

Итого 16 нод. Использовали встроенную Citus репликацию, а не WAL, так при отсутствии нод Citus продолжает работать. Между координаторами WAL синхронная для метаданных.

Базовая онфигурация 1-го и 2го сервера, WAL репликацию между координаторами тут не показываю. Для 3-го и 4-го сервера просто не выполнять связанные строки c coordintor.

Репликация Citus включается указанием:

citus.shard_replication_factor = 2 (Ниже есть sed по этому поводу)

#!/bin/bash

pg_dropcluster --stop 10 main

pg_createcluster --start --start-conf=auto --locale ru_RU.UTF-8 --lc-collate ru_RU.UTF-8 -p 5432 10 coordinator -- --auth trust --auth-local trust --auth-host trust
pg_createcluster --start --start-conf=auto --locale ru_RU.UTF-8 --lc-collate ru_RU.UTF-8 -p 5433 10 main1 -- --auth trust --auth-local trust --auth-host
trust
pg_createcluster --start --start-conf=auto --locale ru_RU.UTF-8 --lc-collate ru_RU.UTF-8 -p 5434 10 main2 -- --auth trust --auth-local trust --auth-host
trust
pg_createcluster --start --start-conf=auto --locale ru_RU.UTF-8 --lc-collate ru_RU.UTF-8 -p 5435 10 main3 -- --auth trust --auth-local trust --auth-host
trust
pg_createcluster --start --start-conf=auto --locale ru_RU.UTF-8 --lc-collate ru_RU.UTF-8 -p 5436 10 main4 -- --auth trust --auth-local trust --auth-host
trust

pg_conftool 10 coordinator set max_connections 2048
pg_conftool 10 main1 set max_connections 1024
pg_conftool 10 main2 set max_connections 1024
pg_conftool 10 main3 set max_connections 1024
pg_conftool 10 main4 set max_connections 1024

pg_conftool 10 coordinator set listen_addresses '*'
pg_conftool 10 main1 set listen_addresses '*'
pg_conftool 10 main2 set listen_addresses '*'
pg_conftool 10 main3 set listen_addresses '*'
pg_conftool 10 main4 set listen_addresses '*'

pg_conftool 10 coordinator set shared_preload_libraries citus
pg_conftool 10 main1 set shared_preload_libraries citus
pg_conftool 10 main2 set shared_preload_libraries citus
pg_conftool 10 main3 set shared_preload_libraries citus
pg_conftool 10 main4 set shared_preload_libraries citus

echo "host    all             all             172.21.1.0/24            trust" >> /etc/postgresql/10/coordinator/pg_hba.conf
echo "host    all             all             172.21.1.0/24            trust" >> /etc/postgresql/10/main1/pg_hba.conf
echo "host    all             all             172.21.1.0/24            trust" >> /etc/postgresql/10/main2/pg_hba.conf
echo "host    all             all             172.21.1.0/24            trust" >> /etc/postgresql/10/main3/pg_hba.conf
echo "host    all             all             172.21.1.0/24            trust" >> /etc/postgresql/10/main4/pg_hba.conf

sed -i -e "/shared_preload_libraries = citus/a citus.shard_replication_factor = 2" /etc/postgresql/10/coordinator/postgresql.conf
sed -i -e "/citus.shard_replication_factor = 2/a citus.shard_count = 128" /etc/postgresql/10/coordinator/postgresql.conf

sed -i -e "/shared_preload_libraries = citus/a citus.shard_replication_factor = 2" /etc/postgresql/10/main1/postgresql.conf
sed -i -e "/citus.shard_replication_factor = 2/a citus.shard_count = 128" /etc/postgresql/10/main1/postgresql.conf

sed -i -e "/shared_preload_libraries = citus/a citus.shard_replication_factor = 2" /etc/postgresql/10/main2/postgresql.conf
sed -i -e "/citus.shard_replication_factor = 2/a citus.shard_count = 128" /etc/postgresql/10/main2/postgresql.conf

sed -i -e "/shared_preload_libraries = citus/a citus.shard_replication_factor = 2" /etc/postgresql/10/main3/postgresql.conf
sed -i -e "/citus.shard_replication_factor = 2/a citus.shard_count = 128" /etc/postgresql/10/main3/postgresql.conf

sed -i -e "/shared_preload_libraries = citus/a citus.shard_replication_factor = 2" /etc/postgresql/10/main4/postgresql.conf
sed -i -e "/citus.shard_replication_factor = 2/a citus.shard_count = 128" /etc/postgresql/10/main4/postgresql.conf

systemctl disable postgresql

systemctl enable postgresql@10-coordinator
systemctl enable postgresql@10-main1
systemctl enable postgresql@10-main2
systemctl enable postgresql@10-main3
systemctl enable postgresql@10-main4

systemctl restart postgresql@10-coordinator
systemctl restart postgresql@10-main1
systemctl restart postgresql@10-main2
systemctl restart postgresql@10-main3
systemctl restart postgresql@10-main4

sleep 5

su postgres -c "psql -h 127.0.0.1 -p 5432 -c 'CREATE DATABASE cdr;'"
su postgres -c "psql -h 127.0.0.1 -p 5432 -d cdr -c 'CREATE EXTENSION citus;'"

su postgres -c "psql -h 127.0.0.1 -p 5433 -c 'CREATE DATABASE cdr;'"
su postgres -c "psql -h 127.0.0.1 -p 5433 -d cdr -c 'CREATE EXTENSION citus;'"

su postgres -c "psql -h 127.0.0.1 -p 5434 -c 'CREATE DATABASE cdr;'"
su postgres -c "psql -h 127.0.0.1 -p 5434 -d cdr -c 'CREATE EXTENSION citus;'"

su postgres -c "psql -h 127.0.0.1 -p 5435 -c 'CREATE DATABASE cdr;'"
su postgres -c "psql -h 127.0.0.1 -p 5435 -d cdr -c 'CREATE EXTENSION citus;'"

su postgres -c "psql -h 127.0.0.1 -p 5436 -c 'CREATE DATABASE cdr;'"
su postgres -c "psql -h 127.0.0.1 -p 5436 -d cdr -c 'CREATE EXTENSION citus;'"

Далее добавляете ноды через 1-ый координатор:
IP адреса: 51,52,53,54 = 1-ый сервер. И так далее для остальных серверов.

psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.51', 5433);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.61', 5433);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.71', 5433);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.81', 5433);"

psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.52', 5434);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.62', 5434);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.72', 5434);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.82', 5434);"

psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.53', 5435);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.63', 5435);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.73', 5435);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.83', 5435);"

psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.54', 5436);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.64', 5436);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.74', 5436);"
psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * from master_add_node('172.21.1.84', 5436);"

psql -U postgres -d cdr -h 127.0.0.1 -p 5432 -c "SELECT * FROM master_get_active_worker_nodes();"

Далее создаете таблицу в базе cdr как обычно в стандратном постгресе через 1-ый координатор и назначаете ее distributed:

SELECT create_distributed_table('pgbench_history', 'aid');

Всё, можно писать данные. Кол-во шардов 16-128 выше задается, зависит от задач на сколько шардов бить еще таблицу.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от leap42 (ok) on 09-Апр-18, 09:15 
спасибо за комментарий, но лучше бы вы его статьёй оформили (тут так можно), комментарий тяжело будет найти со временем
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от raver email(ok) on 08-Апр-18, 12:03 
Сорри за очепятки, времени просто не было. Главное заранее создать базу cdr в 1-ом координаторе и на всех нодах с данными руками вначале, подключить extension citus в каждой ноде внутри каждой базы cdr. И только потом уже делать на 1-м координаторе SELECT * from master_add_node('172.21.1.51', 5433); и так далее опять же внутри базы cdr.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Доступна распределённая СУБД CitusDB 7.3"  +1 +/
Сообщение от _KUL (ok) on 08-Апр-18, 14:49 
Великолепно. Поделился опытом, рассказал о хитростях. Если в комментариях к новостям хотябы по 1 такому комменту будет, то это просто праздник какой то.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Доступна распределённая СУБД CitusDB 7.3"  +1 +/
Сообщение от raver email(ok) on 08-Апр-18, 16:06 
Добавлю к примеру выше. Когда создаете распределенную таблицу запросом SELECT create_distributed_table('pgbench_history', 'aid') то 'aid' это имя столбца в таблице по которому и будет происходить шардирование данных, естесственно он должен быть уникальным. Он может быть по типам напрмиер bigint, uuid и еще каких-то типов, в документации описано, мы используем uuid.

Так же рекомендую почитать про reference_table в Citus - по сути это создание просто одинаковой таблицы на всех нодах с одинаковыми данными во всех нодах, то есть она реплицируется всегда на все ноды с данными. Может использоваться для того чтобы по ней JOIN делать с распределенными таблицами в определенных случаях.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от mickvav email on 09-Апр-18, 09:19 
Правильно я понимаю, что когда дорастёте до 16-ти серверов, можно уже и за коммерческий суппорт заплатить будет?
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Доступна распределённая СУБД CitusDB 7.3"  +/
Сообщение от raver email(ok) on 09-Апр-18, 12:46 
Верно, но пока цены у них слишком высокие, надо торговаться. Стоит это дело дорого - 800$ в месяц за ноду, то есть 800 * 18 = 14400 долларов в месяц, с учетом 2-х координаторов, такую цену объявили после переписок, потом спросили сколько нас устроит, видимо поняв что дороговато, мы пока не отвечали. Например про купить разово лицензии речи не идет пока и потом платить например по 100$ в месяц за ноду.

За эти деньги проще сразу купить серверов и поставить на колокейшн допустим не 4, а 8 или 16 и развернуть на них *4 нод с данными, то есть 8x4 = 32 ноды на старте и потом их выносить как железо будет докупаться, или даже 16*4 = 64 ноды на старте. Но мы прикинули впринципе 16 серверов и 16 нод для всего проекта в будущем хватит с лихвой, чтобы вести детальную статистику и потом ежемесячно делать RENAME и создание новой таблицы, который как раз они реализовали для распределенных таблиц, по сути складывать как в архивные таблицы предыдущие данные. Так сами таблицы не будут раздуваться и SELECT будут быстрые, что по архивным, что по текущим таблицам.

Но правда мы еще не набили данными таблицы, чтобы посмотреть как долго RENAME будет работать по распределенным таблицам.

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

Для небольших относительно баз и не критичных к времени простоя, можно вообще дамп-рестор делать, добавив нод перед рестором.

И еще 1 вариант есть. Берем добавляем новые ноды, далее создаем например таблицу calls_new, копируем в нее все из calls, делаем DROP calls, затем RENAME calls_new в calls. Но повторюсь копирование данных для очень больших БД просто не имеет смысла так делать, это надо потом дописывать логику чтобы досинхронизировать остатки новых данных.
Так же тогда можно уже типа старые архивные таблицы так же плавно перераспределить меж всеми нодами, включая добавленные.

Надо в общем проверить все это будет касаемо RENAME.

Сам RENAME быстро происходит за 1-3 секунды. Кол-во данных судя по всему не влияет.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема


  Закладки на сайте
  Проследить за страницей
Created 1996-2018 by Maxim Chirkov  
ДобавитьПоддержатьВебмастеруГИД  
Hosting by Ihor