Конференция проходила 7-8 ноября в кампусе Сколково (Школа управления и менеджмента Сколково). Место весьма пафосное, и столь же неподходящее для подобного рода мероприятий. Своим ходом добираться очень удобно, мне так вообще 15 минут от дома, но парковка сто рублей в час. А если городским транспортом, то целая история: автобусы, маршрутки, очереди. Такси, разве что. Правда, надо отдать должное организаторам, регулярный транспорт был обеспечен.

Само здание кампуса, круглой формы, оставило, конечно, неизгладимое впечатление. Ну, то есть, конечно, да — все весьма и весьма. Но быстро что-нибудь там найти, та еще задача. Если там жить, то привыкнуть можно, конечно. Но вот так, чтобы за два дня, постичь эту странную систему координат, непросто. Знание географии мало помогает. Да, Москва в России (на втором этаже, разумеется), но почему все это между Индией и Сингапуром? Схемы есть, есть даже специальные люди с надписью на спине «Отвечу на любой вопрос», и они иногда даже знали правильное направление в этом неевклидовом пространстве. Но от этого мало толку, когда надо быстро с одного доклада попасть на другой. Поэтому получилось послушать не все, что хотелось, а только то, что смоглось 🙂

Тем не менее, впечатление осталось хорошее. Доклады интересные, докладчики — люди солидные и знающие, темы актуальные. Видно, слышно — хорошо в любом зале. Организаторы обещают в ближайшее время опубликовать не только тезисы, но и видеозаписи. Можно будет посмотреть то, что не удалось увидеть живьем.

А еще, в этом круглом кампусе на стенах висят большие фотографии членов политбюро и прочих любимых руководителей. Сразу понятно, что все они непрерывно пекутся об инновациях и импортозамещении. Но это совсем другая история.

Докладов было очень много, что-то ближе к трем сотням. Вот что удалось послушать (в порядке не хронологическом, а случайном).

1. Сети передачи данных в интернете вещей

Олег Артамонов (Unwired Devices LLC), oleg@unwds.com (стр. 163 в книге Тезисы)

Проблема объединения в сеть очень большого количества мелких устройств, датчиков. Объемы данных очень маленькие, скорости тоже. Высокие требования по энергосбережению (компактные устройства с автономным питанием, работающие несколько лет в тяжелых условиях). Типичные расстояния — от нескольких метров до нескольких десятков километров (не шутка, например — длинный трубопровод).

Из готовых решений, 60% рынка — Z-Wave, проприетарный протокол, для небольших расстояний. Если надо далеко, то LoRa, тоже проприетарный протокол, 300 бит/с, надежно работает вплоть до 50 км.

Есть еще много вариантов. Но либо все совсем закрыто, и надо привязываться к вендору, либо все делать своими руками.

А еще, истина, о которой часто забывают: чем уже полоса, тем больше каналов можно вместить, но при этом уменьшается вероятность получить дуплекс (из-за дрейфа несущей частоты).

Гуглить: локальные ячеистые сети — Z-Wave, Zigbee, 6LoWPAN, Thread, сети большой дальности — LoRa/LoRaWAN, Sigfox, Стриж, Weightless.

2. Нейронные сети: практическое применение

Наталия Ефремова (NTechLab), стр. 176 в книге Тезисы

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

Конечно, очень интересная область. Прежде всего, задачи классификации (идентификация объектов, распознавание лиц, частей тела человека, выделение границ) — сверточные сети (CNN, DBN). Рекуррентные сети (RNN) — распознавание и генерация естественного языка, распознавание эмоций (EmoNets), анализ высказываний (LSTM). Решение творческих задач (Призма, Аристо, DeepDream).

3. PostgreSQL: практические примеры оптимизации SQL-запросов

Иван Фролков, Postgres Professional, стр.106

Прописные истины, актуальные всегда. Чем меньше (строк, индексов, ввода-вывода, страниц), тем лучше. Автовакуум, сбор статистики, индексы (btree можно перестраивать находу, при выполнении запросов), удаление неиспользуемых индексов, партиционирование. Рекомендуется всегда указывать точность для типа numeric, поскольку она всегда оказывается избыточной. Статистики удобно смотреть вьюхой pg_stats.

4. Зачем нужен мультимастер?

Илья Космодемьянский, PostgreSQL Consalting LLC, стр.122

Если подумать, ни-за-чем. Тем более, что хорошей реализации все равно нет. Это если мы заботимся о целостности данных (если нет, то все гораздо проще).

В большинстве случаев можно обойтись репликацией. Причем, самый проверенный и надежный способ — Slony. Штатные средства, конечно, хороши. Но уж больно молоды. Мы сейчас о чем? О продакшн? Тогда слоны. В Сообществе зарождается DTC (распределенный координатор транзакций), но до практического использования еще далеко. Несколько ближе к реальности BDR — геораспределенный кластер с логической репликацией (этапы развития: PostgresXC->XL->BDR).

Еще модно хотеть от постгреса аналога Oracle RAC. Но это вовсе даже не мультимастер, это несколько инстансов с общим хранилищем. Имеет свою нишу, но чрезвычайно сложно в настройке и поддержке. Да и не все гладко.

Кстати, по поводу распределенных транзакций. Помимо докладов были еще и свободные дискуссии, без заранее определенной темы. Поговорили, довольно подробно, в том числе и о состоянии дел с DTC. Все не так уж плохо, скоро можно будет попробовать. Правда, это точка зрения сообщества. А Илья Космодемьянский консультирует реальных пользователей, стало быть, и подход несколько другой, более консервативный.

И еще: лучший файловер — это DBA.

5. Девять кругов ада или PostgreSQL Vacuum

Алексей Лесовский, PostgreSQL Consalting LLC, стр.117

Об этом уже и так много говорилось. Выключать вакуум нельзя, а если он начинает потреблять слишком много ресурсов, значит вы что-то делаете не так. Дефолтные настройки неоптимальны, надо настраивать, ручек много. Можно настраивать для отдельно взятой таблицы (alter table). Интересно, что временный таблицы вакуум не обрабатывает.

Ну а вообще, доклад посвящен тому, как устроен вакуум.

6. Внутреннее устройство PostgreSQL: временные таблицы и фрагментация памяти

Григорий Смолкин, Сергей Петров, Postgres Professional, стр.113

Замечательный дуэт: один скурпулезно объясняет суть проблемы, а другой завершает «Ну в двух словах это так …».

Короче, в двух словах, — многочисленные временный таблицы (их очень любит 1С) приводят к фрагментации памяти. Вакуум не решает проблемы. Бороться можно настройками памяти (увеличивать vm.min_free_kbytes; vm.extfrag_threshold = 500). Начиная с версии 9.5 можно использовать hugepages.

Временные таблицы: привязаны к определенному серверному процессу; не имеют механизма сбора статистики; размещены в локальной памяти; удаляются после отключения клиента. Тройная буферизация. Осиротевшие временные таблицы не удаляются, переполняются таблицы блокировок. Часть проблем решается в enterprise-сборке PostgresProfessional (буферизация, проблема с блокировками), есть патч.

Расширение online_analyze решает проблему сбора статистики для временных таблиц. Однако, при большом количестве временных таблиц это становится накладным. Есть патч.

7. Долгожданный релиз pg_pathman 1.0

Александр Коротков, Дмитрий Иванов, Postgres Professional, стр.118

У штатного механизма партиционирования есть проблемы: Много ручной работы; Полный перебор секций при планировании; Отсутствие оптимизаций во время исполнения; Нет встроенной поддержки HASH секционирования; Не копируются foreign keys родителя; Бывают странности с привилегиями.

Расширение pg_pathman — это:

  • Поддержка HASH и RANGE секционирования
  • Автоматическое + ручное управление секциями
  • Улучшенное планирование запросов
  • RuntimeAppend — выбор секции во время исполнения
  • PartitionFilter — INSERT без триггеров
  • Перехват оператора COPY FROM/TO
  • Неблокирующее конкурентное секционирование
  • Поддержка FDW (хранилище на разных файловых системах)

Можно клонировать таблицы вместе со всеми индексами. Инсерты без триггеров, по скорости — как для обычных таблиц.

Можно пользоваться уже сейчас. Штатно декларативный синтаксис будет в v10.

8. Новые возможности полнотекстового поиска в PostgreSQL

Олег Бартунов, Postgres Professional, стр.127

Возрожденный FTS (некоторое время был заброшен).

Стабильнее и проще в настройках, чем внешний поиск. Индексирует один раз при инсертах. Индексируется все, что угодно, вплоть до химических формул и описаний генома. Учитывает расстояние между поисковыми словами, время (индекс RUM). Ищет фразы.

9. ClickHouse: очень быстро и очень удобно

Виктор Тарнавский, Алексей Миловидов, Яндекс, стр.93

Доклад практически слово в слово повторяет то, что было в Яндексе: [1]

Хорошая документация (первоисточник) вот здесь [2]

Доклад был в большом зале (Конгресс-холл), народу туча, вопросом — море, интерес огромный.

10. Переезжаем на Yandex ClickHouse

Александр Зайцев, LifeStreet, стр.132

Пример практического использования. 10 млрд. событий в сутки. Ранее было реализовано на Вертике. Производительность получается примерно такой же, но можно уменьшить количество узлов (непонятно, за счет чего?), и не нужны дорогие лицензии.

Проблемы CH:

  • Нет транзакций
  • Нет констрейнтов
  • Нет Consistency
  • Нет UPDATE/DELETE
  • Нет NULLs
  • Нет Миллисекунд
  • Нет Implicit type conversions
  • Нет нормального SQL
  • Нет произвольного партиционирования
  • Нет средств управления кластером

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

Ограничения внешних словарей:

  • Ключ – только UInt64
  • Нет прямого способа получить все значения колонки
  • Ограничения по размеру
  • Нет обновления on demand или по изменению источника
  • Каждый узел кластера обновляется независимо (требуется синхронизация файлов на всех узлах кластера)
  • Может быть медленно, если словарь нельзя целиком разместить в памяти

Удалять (условно) из таблицы фактов можно, используя движок CollapsingMergeTree. При этом изменяются не сами данные, а результаты агрегации. На практике данные заливаются один раз и навсегда, повторить неудавшуюся заливку нельзя, и все вокруг строится с учетом этого (данные заливаются практически в реальном времени).

Шардить лучше вручную. То есть, грузить не в distributed, а в локальные таблицы на всех нодах. (Почему?)

Доступ к данных — основная проблема в странном SQL. Решается многочисленными костылями.

BI прикрутить пока не получается. Аналитики умеют сами писать SQL-запросы (это, кстати, давно замеченная тенденция — давать аналитикам доступ непосредственно к базе).

Этот доклад был самым последним. Тем не менее, народу был полон зал, много вопросов.

11. NoSQL внутри SQL: приземленные вопросы практического применения

Дмитрий Долгов, Mindojo, стр.101

Неструктурированные данные (докуиенты) в формате json. Естественная среда — MongoDB. Но с некоторых пор реляционные базы имеют поддержку: Mysql (json), PostgreSQL (hstore, json, jsonb). А также проприетарные Oracle, MSSQL, DB2.

Проведено сравнительное тестирование Mongo, Postgres, Mysql. Использовался стандартный тест Yahoo YCSB 0.8. Вполне ожидаемо Mysql оказался на последних местах. Mongo и Postgres очень близки практически во всех тестах. Причем, для Mongo характерен довольно резкий спад throughput при достижении некоторого количества клиентов. Реляционные базы выходят на полку и держатся очень долго. Latency для Postgres растет медленнее всех. На сложных запросах картина сложнее, но тенденции не меняются.

Вывод: Mongo имеет смысл использовать, только если есть к ней привычка и нет необходимости гарантировать целостность данных.

 

Comments are closed.

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