Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap
Я покажу в PostGIS, как каждый может проанализировать геоданные всей Земли и получить ответы на свои глобальные вопросы за минуты и секунды.
Когда вы пользуетесь такси в небольших городах, вызывая машину по телефону, то с высокой вероятностью вашу поездку тарифицирует программа на основе данных OSM. Для тарификации используется какой-либо из пакетов прокладки маршрута. Благодаря этому сценарию использования, сотрудники таксопарка указывают номер дома и улицу на зданиях и делают вклад не только в свой бизнес, но и в OpenStreetMap.
В сценарии аналитики данных входят и задачи где лучше разместить торговую точку, чтобы в нее приходили покупатели. Опять же данные о шаговой доступности и населенности окресностей можно извлечь из геоданных. Можно расчитывать стоимость недвижимости на основе множества факторов связанных с расположением объекта и его окружения.
Ученые могут строить прогнозные модели для предсказания эпидемий, эволюции городов, планировать рекреационные зоны и застройку существующих территорий на основе открытых геоданных.
Ну и можно ответить на любой вопрос по географии который вам придет в голову: посчитать площади городов и построек, протяженности дорог и извлечь названия городов, областей и островов. Можете, например, стать чемпионом по игре в "Города" или основать новый сервис прокатов электро самокатов. Все ограничивается лишь вашей фантазией.
Я опубликовал https://github.com/igor-suhorukov/openstreetmap_h3 — мой проект высокопроизводительного загрузчика данных, который позволяет выполнять геоаналитику данных из OpenStreetMap в PostGIS. Он преобразует дамп OpenStreetMap всего мира или региона PBF в схему, разделенную по регионам H3. Опция столбцового хранения активирует расширение CitusDB в PostgreSQL для ускорения аналитических запросов.
Слайды
Видео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
ППавел Лузанов Postgres Professional Руководитель образовательных программ
PostgreSQL 16: На финишной прямой
8 апреля завершается прием изменений в 16-ю версию.
Ряд новинок уже известен, в частности нас ждут любопытные изменения в области безопасности и логической репликации. Но сделать анонс всех интересных патчей до окончания мартовского коммитфеста нельзя. По опыту предыдущих релизов можно предположить, что самые интересные патчи будут приняты во второй половине марта и начале апреля.
Поэтому интрига с содержанием этого доклада будет сохраняться до самого последнего момента в том числе и для автора.
-
Альфред Столяров ООО "Еваппс" (EvApps) директор
Как мы перевели клиента с Oracle на PostgreSQL до того, как это стало мейнстримом
Импортозамещение не началось в прошлом году после всем известных событий. Его старт датируется 2014 годом. Именно с этого года государственные и окологосударственные компании начали прорабатывать вопрос перехода на рекомендованное ПО. Одна из таких компаний и обратилась к нам еще в 20-м году с проектом перехода с Oracle на PostgreSQL. Данный проект был призван решить накопившиеся архитектурные проблемы (не оптимальное хранение телеметрических данных, сама СУБД работала внутри виртуальной машины), оптимизировать использование дискового пространства (освободить основное хранилище, отладить сохранение архивных данных, обеспечить корректное резервное копирование). Так как система заказчика должна работать бесперебойно 24/7, то требовался переход с одной СУБД на другую без простоев, с одновременной работой обеих для обеспечения пошагового перевода подсистем и возможности контролировать корректность данных. И, само собой, работы нужно было завершить как можно быстрее.
В докладе расскажем, как нам удалось решить этот кейс.
-
Павел Конотопов inCountry DBA team lead
Пять оттенков шардинга
Колоссальное значение сейчас приобретает шардинг. Размеры современных БД перешагивают 100 терабайтные пределы, вертикальное масштабирование, добавление реплик, содержащих полную физическую копию БД, становится затруднительным, особенно при дефиците вычислительных ресурсов. Шардирование базы данных – это способ горизонтально масштабироваться, разделив данные между независимыми друг от друга вычислительными узлами.
В мире PostgreSQL существуют как давно известные инструменты масштабирования: CitusDB, Greenplum, так и решения нового поколения – Cockroach DB, Yugabyte DB, SPQR, Shardman.
В нашем докладе мы будем рассуждать о разнице между этими реализациями, достоинствах и недостатках этих решений, рассмотрим текущее состоянии реализации шардинга в ванильном PostgreSQL, а также затронем и не менее важны темы – предоставления гарантий целостности и согласованности данных в масштабах распределенного кластера.
-
Анатолий Анфиногенов АО "ВНИИЖТ" Зам. директора научного центра - начальник отдела разработки ПО
Вакуумотерапия: лечим хронические заболевания БД
После импортозамещения и перехода с СУБД Oracle на PostgreSQL мы столкнулись как с "детскими" болезнями нашего приложения на новой СУБД, которые успешно вылечили, так и с "хроническими заболеваниями", с которыми пришлось разбираться существенно дольше. Одной из наиболее запомнившихся проблем стала проблема деградации производительности, которая, как выяснилось, была вызвана недостаточным вакуумированием нашей БД. Опыт осознания и решения этой проблемы предлагается вашему вниманию в виде практических рекомендаций по борьбе с эффектом bloat для таблиц и индексов БД, а также настройке VACUUM/autovacuum PostgreSQL.