Вооруженным глазом: наглядно о проблемах PostgreSQL-запроса

В этом нам помогут различные варианты визуализации:


Облекаем данные в красивую оболочку


Привет, меня зовут Дарья, и я Frontend-разработчик юнита Гео в Авито. Хочу поделиться опытом того, как мы сделали на вебе новый поиск по карте, заменив кластеры более удобным решением и сняв ограничение на количество отображаемых объектов.
В статье я расскажу, какая перед нами стояла задача и как мы справлялись с проблемами в процессе реализации.


Продолжаем цикл статей про построение систем роутинга со сложными требованиями на основе Open Source базы данных PostgreSQL и расширения PgRouting на карте OpenStreetMap. Сегодня мы поговорим о том, как добавить поддержку односторонних дорог (направлений движения). Зачастую, именно отсутствие этой поддержки является основной причиной смены PgRouting на другой "движок" маршрутизации. Как обычно, все данные и результаты доступны в моем GitHub репозитории OSM Routing Tricks, который я пополняю по мере публикаций.

Небольшой маршрут из 330 адресов на карте OpenStreetMap.
Общероссийское голосование по вопросу одобрения изменений, вносимых в Конституцию Российской Федерации, проводилось с 25 июня по 1 июля 2020 года (wikipedia).
Основная цель данной заметки — это продемонстрировать как можно быстро начать работать с данными голосования и показать наличие определенного вида аномалий в них.
Все вычисления, визуализации и парсинг данных приведены в Google Colab, который доступен по этой ссылке Google Colab.
Хотелось бы поделиться опытом создания систем маршрутизации PostgreSQL/PgRouting на карте OpenStreetMap. Речь пойдет о разработке [коммерческих] решений со сложными требованиями, для более простых проектов, вероятно, достаточно обратиться к документации. Насколько мне известно, такие вещи, как полная поддержка односторонних дорог и направлений движения, быстрый роутинг на тысячах адресов (порядка секунд на обычном лаптопе, к примеру, Macbook Pro 13" 2013 года), создание дорожного графа с заданными свойствами, мета-оптимизация маршрутов вообще нигде и никак не рассматриваются. Как обычно, все данные и результаты доступны в моем GitHub репозитории OSM Routing Tricks, который я буду пополнять по мере публикаций.

Небольшой маршрут из 330 адресов на карте OpenStreetMap (время построения около 5 секунд на вышеупомянутом лаптопе). Можно ли за это же время построить маршрут, скажем, из 5000 точек? Да, можно, и об этом мы тоже поговорим (в следующих частях статьи).




VictoriaMetrics, TimescaleDB и InfluxDB были сравнены в предыдущей статье по набору данных с миллиардом точек данных, принадлежащих 40K уникальным временным рядам.
Несколько лет назад была эпоха Zabbix. Каждый bare metal сервер имел не более нескольких показателей – использование процессора, использование оперативной памяти, использование диска и использование сети. Таким образом метрики с тысяч серверов могут поместиться в 40 тысяч уникальных временных рядов, а Zabbix может использовать MySQL в качестве бэкенда для данных временных рядов :)
В настоящее время один node_exporter с конфигурациями по умолчанию предоставляет более 500 метрик на среднем хосте. Существует множество экспортеров для различных баз данных, веб-серверов, аппаратных систем и т. д. Все они предоставляют множество полезных показателей. Все больше и больше приложений начинают выставлять различные показатели на себя. Существует Kubernetes с кластерами и pod-ами, раскрывающими множество метрик. Это приводит к тому, что серверы выставляют тысячи уникальных метрик на хост. Таким образом, уникальный временной ряд 40K больше не является высокой мощностью. Он становится мейнстримом, который должен быть легко обработан любой современной TSDB на одном сервере.
Что такое большое количество уникальных временных рядов на данный момент? Наверное, 400К или 4М? Или 40м? Давайте сравним современные TSDBs с этими цифрами.


Интерпретируемое машинное обучение — популярная тема в последние годы. Во многом благодаря использованию этой технологии в медицине, транспорте и других областях, где цена ошибки велика, нужно понимать, как модель устроена и чем "руководствуется" при принятии решений.
Простота объяснения зависит от сложности модели. Куда проще понять, как работает дерево принятия решений, чем извлечь какие-то определенные правила из весов полносвязной нейронки. К счастью, каскады Хаара имеют довольно простую структуру и можно, последовательно применяя их к изображению, узнать, как работает модель.

