Компания Citus Data объявила (https://www.citusdata.com/blog/17-ozgun-erdogan/403-citus-un...) об открытии исходных текстов распределённой СУБД CitusDB (https://www.citusdata.com/products/what-is-citusdb). Ранее проект CitusDB развивался как форк PostgreSQL, но начиная с Citus 5.0 проект переработан в форму расширения к PostgreSQL, не требующего модификации кодовой базы и работающего поверх штатных выпусков PostgreSQL. Подобный подход позволяет использовать все появляющиеся в новых выпусках PostgreSQL новшества, такие как типы JSON/JSONB, операции UPSERT и работа (http://rhaas.blogspot.ru/2016/03/no-more-full-table-vacuums....) без периодического выполнения "vacuum full" для больших БД. Код открыт (https://github.com/citusdata/citus) под лицензией AGPLv3.Citus обеспечивает горизонтальное масштабирование PostgreSQL в кластере на базе типового оборудования, с разнесением данных по узлам при помощи (https://www.citusdata.com/docs/citus/5.0/aboutcitus/introduc...) шардинга и репликации. Шардинг даёт возможность организовать хранилище для очень большого объема данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера. Дополнительное реплицирование данных на несколько узлов обеспечивает отказоустойчивость и позволяет сохранить работоспособность при выходе узлов из строя.
Для приложений кластер Citus выглядит как один большой сервер PostgreSQL, обладающий производительностью стоящих за ним узлов. Входящие запросы распараллеливаются по имеющимся серверам, позволяя добиться предсказуемого времени выполнения запроса к большим массивам данных, пополняемым в режиме реального времени.
Например, благодаря распределению работы на все узлы кластера выполнение запроса в кластере из 20 серверов выполняется почти в 20 раз быстрее, чем на одном отдельном узле. Предлагается (https://www.citusdata.com/docs/citus/5.0/reference/configura...) три планировщика выполнения запросов (router, real-time и task-tracker), позволяющий добиться оптимальных показателей при разном характере работы с данными (оперативная обработка (низкие задержки) или аналитика (пропускная способность)).<center><a href="https://www.citusdata.com/docs/citus/5.0/_images/citus-basic... src="https://www.opennet.ru/opennews/pics_base/0_1458850594.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Типовыми областями использования Citus являются системы аналитики, разбор информации о случившихся событиях, архивирование больших наборов данных, генерация отчётов, анализ сеансов. Кластеры на базе CitusDB применяются в таких компаниях как CloudFlare (аналитика в реальном времени 100 Тб БД с данными 4 млн сайтов), MixRank (накопление и анализ статистики о B2B-продажах для поиска новых клиентов), Neustar (анализ миллиардов ежедневных событий в рекламной сети), Agari (обработка 6-8 Тб данных c электронной почтой).
<center><iframe width="640" height="360" src="https://www.youtube.com/embed/NVl9_6J1G60?list=PLixnExCn6lRp... frameborder="0" allowfullscreen></iframe></center>
URL: https://www.citusdata.com/blog/17-ozgun-erdogan/403-citus-un...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44108
Не знал, что CloudFlare данные собирает и что-то в них анализирует. Вот тебе и нейтральный CDN.
корпорации добра, слышали, да
А, вот почему они пользователям Tor капчу показывают. Шпионаж плохо работает. Эти гады еще и SSL хакают для этого.
>> собирает и что-то в них анализируетПрямо, как Гугл Аналитикс!!!
А ещё они данные об отказе винчестеров публикуют!!!
Им как минимум нужно понимать к каким узлам нужно физически приблизить какие-то запрашиваемые данные, распределять ресурсы их основная работа :)
для этого не нужны системы оффлайновой аналитики, это штатная операция самой CDN
>не нужны системы оффлайновой аналитики,Где здесь что-то про "оффлайн-аналитику"? Вам привиделось.
> это штатная операция самой CDN
Вы уж их извините, что они с вами не посоветовались, как им своей системой управлять и что (возможно - для улучшения работы) анализировать!
Любая BigData стоит денег, покупается и продается. Конечно они ее собирают и сливают куда надо.
> Не знал, что CloudFlare данные собирает и что-то в них анализирует. Вот
> тебе и нейтральный CDN.https://blog.cloudflare.com/scaling-out-postgresql-for-cloud.../
А как там с резервированием? Если один узел упадет - упадет все? Если есть запас прочности - то будет шикарно, классический постгрес можно будет выкидывать.
Это надстройка над "классическим" постгресом, выкидыватель мамкин.
Выкидыш же! :)
угу, примерно.
еще не кассандра или мнезия(или еще более тяжелые "распределенные" БД без точек отказа), но уже не постгресСКЛ )
в любом случае - портирование на - будет попроще для отягощенные legacy-кодом.
Правильно ли я понимаю, что при таком шардинге всякие там уникальные индексы, внешние ключи и прочие РСУБДшные радости работать не будут?
> Правильно ли я понимаю,TMF ждёт.
Можно ли шардить 1 таблицу на несколько машин и как с ней будет работать джойн?
> Можно ли шардить 1 таблицу на несколько машин и как с ней
> будет работать джойн?А Вас ждёт их отдел продаж. С нетерпением.
>начиная с Citus 5.0 проект переработан в форму расширения к PostgreSQL, не требующего модификации кодовой базы и работающего поверх штатных выпусков PostgreSQLпользуясь случаем, хочется передать превед разрабам 1С, которые так ниасилили
Просто переделывать не хотят. Как я понял, 1ц заточен под хранимые процедуры, которые по мнению разрабов postgresql не нужны. Хотя, емнип, разрабы postgres так говорили и про мастер-мастер, и про синхронную реплику, так что нужно подождать, и проблема может решиться сама собой))
Какие хранимые процедуры, ты о чем, Вася?
Сборка postgresql от 1C отличается переделанными блокировками и всё.
> Просто переделывать не хотят. Как я понял, 1ц заточен под хранимые процедуры,
> которые по мнению разрабов postgresql не нужны. Хотя, емнип, разрабы postgres
> так говорили и про мастер-мастер, и про синхронную реплику, так что
> нужно подождать, и проблема может решиться сама собой))Не под хранимые процедуры же, а под блокировки (привет от MS SQL) и под регистронезависимость (привет Windows)
Несколько неверно Вы поняли...
>хранимые процедуры, которые по мнению разрабов postgresql не нужныОхъ! Аж пузо свело от ржачки, это адский трэщЪ! :))))))))
Есть готовые сборки для 9.4, только не от 1С правда. http://www.postgrespro.ru/products/1c_build
> и работа (http://rhaas.blogspot.ru/2016/03/no-more-full-table-vacuums....)
> без периодического выполнения "vacuum full" для больших БД.Это неточный перевод, речь про отсутствие необходимости выполнять VACUUM FREEZE на больших таблицах, эта фича попала в 9.6. А VACUUM FULL в postgres'е не надо запускать уже лет десять как.
