PGConf 2016 – российская конференция международного уровня, посвященная PostgreSQL. Проводится сообществом. Уже вторая по счету (на первой я не был). По масштабу почти как HighLoad, но только один сплошной постгрес. Проходила в довольно странном месте Lookin-Rooms, рядом с метро Пушкинская, 30 метров от двери до двери. На метро удобно, а парковкой можно и не заморачиваться, ее нет. Место — что-то типа ночного клуба — столики, отдельные кабинеты, еда, цветные лампочки. Так что народ по большей части сидел за столиками и жрал. Это не так уж и плохо на самом деле, потому как всюду экраны, и все хорошо видно и слышно. Интернет был только местный: с авторизацией в Твиттере, и обязательным постом в этот самый Твиттер совершенно дебильного текста со столь же дебильной фотографией (приходилось тут же удалять). Кабак и есть кабак.

Немного напрягало то, что расписание менялось по ходу дела, и узнать об этом было негде. И организаторы поскупились на блокноты и ручки.

На открытии конференции обещались быть министр связи и советник президента, и еще какие-то чины. Что там на самом деле было — не знаю. Во-первых, лениво так рано просыпаться, во-вторых — тошнит от одного вида чиновников, от этого идиотского «импортозамещения». Начинать так день совсем не хотелось.

Ну а по делу — вот, что удалось послушать. Что запомнилось, показалось интересным (не пересказ докладов).

Поток данных в Авито

Константин Сергеевич Евтеев

Очень рекомендовал использование intarray: можно сильно уменьшить размер таблицы, хорошо работают индексы GIN, GIST (при частых апдейтах); но не все здорово с autovacuum.

Чудесная методология Anchor Modeling — предполагает хранение данных в 6-й нормальной форме (Есть обратный подход — Data Vault — одна широкая таблица). Преимущества проявляются при накоплении исторических данных, когда вставка в кучу мелких таблиц обходится дешевле, чем в одну широкую. К тому же все лучше параллелится, почти MPP.

Осталось ощущение, что это опыт, перенесенный с Вертики, поскольку есть информация, что в Авито для аналитики используется именно Вертика.

[ Здесь можно почитать про Anchor Modeling]

[Data Vault]

[Еще докладчик рекомендовал посмотреть вот тут]

Интеграция данных в мире микросервисов

Валентин Гогичашвили

Компания Zalando торгует шмотками через интернет. Речь по сути об организационной структуре: туча крошечных команд реализуют каждая свой микросервис любыми доступными средствами. Пропогандируется использование сохраненных процедур, коротких транзакций, фреймворк JAVA Sproc Wrapper. До кучи: Kafka, Patroni, Spilo. Ну и да, репликация данных каждого микросервиса в общую базу для анализа.

»pglogical» — расширение, реализующее логическую репликацию. Гибкая, как на триггерах, и быстрая, как потоковая. Возможно, хорошая замена londiste.

»PGObserver» — мониторинг базы, собственная разработка

»pg_view» — информация о состоянии процессов базы, собственная разработка

Масштабируемость PostgreSQL

Дмитрий Васильев
Postgres Professional

При распарралеливании производительность ограничивается законом Амдала. Линейный рост — только если параллелится абсолютно все. Реально всегда есть нераспараллелельные участки. А в случае СУБД еще и время на синхронизацию данных. То есть, масштабируемость имеет теоретический максимум.

Как водится, список полезностей для мониторинга и настройки:

»pg_locks» — системная вьюха

»pg_stat_wait» — расширение (Ildus Kurbangaliev)

»pg_buffercache» — расширение, единственный (?) способ посмотреть использование shared memory

»partman» — автоматическое партиционирование (по мне, так проще все сделать вручную, чем с помощью этого чудесного расширения)

»Flame Graphs» — рисует красивые графики системных ресурсов

»Process Monitor» — винда.

Когда хочется совсем уж глубоко копать, вспоминают perf и gdb. Например, вот так:

perf top -F 100 -u postgres

А еще, есть репозиторий, где можно найти хорошо подкрученную сборку постгреса

Почему IBM Power8 — оптимальная платформа для PostgreSQL

Иван Гончаров
IBM

Упоминалась некая Пирамида Брюса, которая в случае POWER8 превращается в трапецию. Нагуглить чего-либо вразумительного на эту тему так и не удалось. По памяти: основание пирамиды — диски, вершина — ядра. Это традиционная конфигурация железа для СУБД. Но последние достижения IBM предлагают нам столь быструю память всех уровней, что можно уже подумать и о процессоре. Кто такой этот загадочный Брюс?

Некоторые тезисы:

Известно о существовании специальных сборок Redis и Neo4j, которые умеют использовать флеш как оперативную память. Правда, для этого нужна еще какая-то железяка, существующая чуть ли не в единственном экземпляре.

Hardware Transactional Memory — аппаратная привязка shared memory к тредам. Блокировки вроде как больше не нужны. Известно, что Memcached это уже умеет. Для постгреса прогнозируется ускорение в 40 раз.

nvlink — Новая системная шина, по следам Nvidia. Обещает очень быстрый обмен между ядрами и памятью. Еще нет, но скоро будет. Не путать с NWlink.

Расширяемость PostgreSQL: Истоки и новые горизонты

Александр Евгеньевич Коротков
Постгрес Профессиональный

Докладчик рассказал, как идут дела по добавлению возможности полноценно использовать подключаемые хранилища и соответствующие индексные методы доступа. Понимание необходимости этого только-только наступает в сообществе. В версии 9.6 предполагается закоммитить обобщенный WAL и расширяемые индексные методы доступа.

Для справки: сейчас известна только одна субд с подключаемыми хранилищами — MySQL. Но там каждое новое хранилище по сути означает новую базу.

Ну и да: в воздухе витает идея необходимости колоночного хранилища и in-memory.

PL/v8 в медицине

Николай Рыжиков
Health Samurai

Ну, то есть, javascript. И все в среде Node.JS. Медики, им так лучше.

Интересно, что во всем мире в медицине используется какой-то очень древний софт (имеется в виду обработка и хранение информации о пациенте). Есть стандарт — FHIR, и потихонечьку начинает внедряться. В частности, fhirbase. Постгрес, jsonb, один-единственный индекс, позволяющий делать любые запросы. Сначара разрабатывали на pl/sql, потом стало слишком сложно, и перешли на javascript. Вся бизнес-логика внутри базы.

Как мы сделали Greenplum Open Source

Andreas Scherbaum
Pivotal

Известны случаи использования в качестве OLTP размером более 100TB. Структура: Мастер->Сегменты (множество), общего хранилища нет, сетевой трафик маленький. Хранилище умеет и строки, и колонки (polimorphic storage), сжатие, партиционирование, параллельная загрузка.

Большая часть доклада была посвящена тому, что основой Greenplum послужил PG версии 8.2.14 и с тех пор не мержился. Но они понимают, что это плохо, и собираются решать эту проблему. Для начала выложили в опенсорс.

Ближайшие конкуренты:

Terradata
Exadata
Netezza

CitusDB: расширение для масштабирования PostgreSQL

Marco Slot
Citus Data

Есть коммерческий продукт CitusDB. И есть два свободно распространяемых расширения для PG: pg_shard и cstore_fdw. (Для них тоже есть коммерческая поддержка). Первое расширение — сам кластер, прозрачное шардирование по времени или по id (хэш), параллельные запросы, в том числе и с join. Второе — колоночное хранилище с поддержкой сжатия (4-6 раз, для json — до 12 раз). Могут использоваться по-отдельности. Все вместе — CitusDB. Ориентировано как на аналитику, так и на DWH. Постоянно упоминается работа в реальном времени. Транзакционность поддерживается как-то не очень и не рекомендуется на нее полагаться.

Собственная репликация. Собственный планировщик. Разработчик тут: [https://www.citusdata.com/products/what-is-citusdb]
»’cstore_fdw»’ — внешние таблицы (foreign), соответственно, никаких транзакций, select только, загружать данные можно copy и insert into. Update, delete — не работают. Собственный планировщик (работает analyze). Для каждой таблицы можно включить сжатие, явно указать имя файла (таблица хранится в двух файлах). Рекомендуется при загрузке сортировать данные по тому полю, по которому они будут выбираться селектом).

Вот типичная последовательность действий:

CREATE EXTENSION cstore_fdw;
— create server object
CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;
— create foreign table
CREATE FOREIGN TABLE customer_reviews (
customer_id TEXT,
review_date DATE
) SERVER cstore_server OPTIONS(compression ‘pglz’);

В конфиге postgresql.conf должна быть строка:

shared_preload_libraries = ‘cstore_fdw’
»’pg_shard»’ — шардинг и репликация. Вся работа с мастером, но сами данные хранятся только на нодах. На нодах должны быть созданы пустые базы с тем же именем и владельцем, что и на мастере. Ноды должны быть видны с мастера (обратное — не понятно). Вся структура создается на мастере, а потом специальными функциями раскладывается по нодам вместе с индексами и пр. При удалении таблицы на нодах их приходится удалять вручную (в нормальном режиме таблицы на нодах недоступны; но если удалить таблицу на мастере, то на нодах все ее шарды превращаются в обычные таблицы; в будущих версиях обещают автоматизировать). Скорее всего, то же самое будет и с alter (утверждается, что существует скрипт, который распространяет изменения на все ноды). На кластерных таблицах не работает explain (решается auto_explain), вложенные запросы, copy, insert from… Delete, update — работают, но требуют обязательного предложения where (работают в пределах одной шарды). Джойны и транзакции, похоже, работают только в пределах ноды (надо проверять).

Последовательность действий:

CREATE EXTENSION pg_shard;
CREATE TABLE s_uagent_shard (
id BIGINT primary key,
appid integer,
serial varchar,
cids varchar,
md5 varchar
);
create index s_uagent_shard__appid_i on s_uagent_shard(appid);
create index s_uagent_shard_serial_i on s_uagent_shard(serial);
create index s_uagent_shard_cids_i on s_uagent_shard(cids);

Определяем ключ, который будет шардиться
SELECT master_create_distributed_table(‘s_uagent_shard’, ‘id’);
Шардится на 16 частей, 1 копия
SELECT master_create_worker_shards(‘s_uagent_shard’, 16, 1);

Дальше заливаем данные. Делать это можно только инсертами или из файла (замена copy). В комплекте есть скрипт на sh (при необходимости можно залезть внутрь), который парсит файлы csv, бинарные, и текстовые (?). Но на нодах это все равно превращается в инсерты. Все медленно и печально. Для ускорения загрузки предлагается создавать несколько параллельных инсертов.

/usr/pgsql-9.4/bin/copy_to_distributed_table -CH -d ‘,’ s_uagents_c.csv s_uagent_shard

В файле данных поля должны располагаться в той же последовательности, что и при создании таблицы (строка заголовка просто игнорируется). Имя базы — по-умолчанию (задается в переменной среды PGDATABASE). Посмотреть что-куда-как шардится можно такими командами:

SELECT * FROM pgs_distribution_metadata.partition;
SELECT * FROM pgs_distribution_metadata.shard;
SELECT * FROM pgs_distribution_metadata.shard_placement;

Для селектов планировщик работает примерно так же, как для партиционированных таблиц. Только в итоге запускаются на нужных нодах параллельные процессы, а результаты мержатся на мастере.

»’CitusDB»’ — специальная сборка postgresql, на которую потом ставится pg_shard. Утверждается, что часть ограничений снята, особенно в версии 5. Появляются join, транзакции (условно). Но тем не менее, сложные запросы предлагается делить на простые и использовать временные таблицы (они тоже могут быть кластеризованы), есть встроенные функции для работы с такими таблицами. Есть нечто похожее на copy для заливки данных из файлов.

Не очень понятна ситуация с лицензиями.

Итого: надо еще смотреть и пробовать. Пока впечатление не очень.

Оптимизация обработки данных аналитических отчётов

Камиль Фаритович Исламов
Троник

Интернет вещей. Умный фонарный столб — погодная станция. Столбов много, данные стекаются в одну базу, там и агрегируются. Сначала они использовали материализованные вьюхи, потом триггеры, а в итоге научились обрабатывать маленькими порциями по мере поступления. Вот и все.

Расширенные возможности аудита в СУБД PostgreSQL в дистрибутиве ОС «Astra Linux Special Edition»

Дмитрий Леонидович Воронин
ОАО «НПО РусБИТех»

Полезная информация: версия постгреса 9.4.5 сертифицирована для работы с гос.тайной.

Слон из нержавеющей стали: продолжаем тестирование производительности PostgreSQL

Александр Чистяков
ООО «Жить в небе»

Тестировал постгрес на разных платформах. Лучшие результаты получены на Ubuntu без каких-либо дополнительных настроек с ф.с. xfs, «из коробки». Еще неплохо использовать zfs (встроенное сжатие данных). Синхронные коммиты — ну очень хорошо:)

Lua в Postgres(из alpha в beta)

Евгений Михайлович Сергеев

PG/Lua, собственно. Хороший учебни по Lua: Lua in 15 minut.

Как построить высокоэффективную (гео)распределённую ИТ-систему при любых каналах связи?

Владимир Игоревич Сердюк
SOFTPOINT

Во-первых, это микрософт. Во-вторых, это чудесный (коммерческий) продукт DB Replicator, который из любой базы делает кластер мастер-мастер. Без комментариев.

 

Добавить комментарий

Set your Twitter account name in your settings to use the TwitterBar Section.