Японцы уже в 2018 году научили немецкий GraphHopper строить маршруты по дорогам хранящимся в PostgreSQL.
Как кастомизировать источник данных, и сохранять новые дороги в таблицу правильно?
Свободная объектно-реляционная СУБД
Японцы уже в 2018 году научили немецкий GraphHopper строить маршруты по дорогам хранящимся в PostgreSQL.
Как кастомизировать источник данных, и сохранять новые дороги в таблицу правильно?
В прошлой работе автор представил описание архитектуры платформы приемной коммисии для обработки миллиарда абитуриентов за один день. В этой работе автор предлагает разработать, используя Spring + JDBCTemplate и Kafka микросервисы для предложенной архитектуры.
Многие СУБД, помимо поддержки стандарта SQL, предлагают дополнительную проприетарную функциональность. Одним из таких примеров является тип данных JSONB в PostgreSQL, позволяющий эффективно хранить JSON-документы.
Конечно, хранить JSON-документ можно и в виде простого текста — это входит в стандарт SQL и поддерживается Hibernate и JPA. Но тогда вам не будут доступны возможности PostgreSQL по обработке JSON, такие как валидация JSON и другие интересные функции и операторы. Хотя, вероятно, вы об этом уже знаете, раз читаете этот пост.
Если вы хотите использовать колонку типа JSONB с Hibernate 6, то у меня для вас отличные новости. В Hibernate 6 появился стандартный маппинг атрибутов сущностей на колонки JSON — необходимо только его активировать. К сожалению, Hibernate 4 и 5 не поддерживают JSON-маппинг, поэтому при их использовании придется реализовать UserType
. Мы рассмотрим оба варианта.
Недавно мы написали о том, насколько экономически разумно «переезжать» с Oracle на PostgreSQL. В этом материале хотели бы поделиться практическим опытом, как осуществить миграцию небольшой СУБД, и какие подводные камни вас могут ожидать при этом.
Статья продолжает наш обзорный цикл о PostgreSQL-операторах для Kubernetes. В первой части мы рассматривали операторы Stolon, Crunchy Data и Zalando. Во второй — KubeDB и StackGres, а также объединили все пять операторов в сравнительную таблицу. В этот раз разбираем решение CloudNativePG, его возможности и особенности, а заодно актуализируем таблицу.
Продолжим наше знакомство с Point in time Recovery.
В первой части мы рассмотрели ситуацию, когда нужно найти момент, в который была очищена таблица и произвели восстановление до точки находящейся перед этим событием.
В этот раз мы рассмотрим более сложную ситуацию.
JVM основная платформа для Big Data решений, таких как Hadoop, Spark, Presto, NiFi но на производительность значительно влияют копирование/сериализация данных "на каждый чих" с последующей сборкой мусора и отсутствие SIMD оптимизаций при работе с данными.
А можно ли в программе на JVM прочитать сотни гигабайт Parquet файлов без Spark/Hadoop? В этом нам поможет библиотека Apache Arrow - проект, которым объединяются десятки решений для работы с Большими Данными. Но для этого даже не обязателен кластер с тысячами ядер и петабайты хранилища! Обработку данных начнем с "золотого стандарта" для open source: PostgreSQL 14 + PostGIS 3.2.0, а продолжим на OpenJDK 11 + Apache Arrow 9.0.0.
В качестве примера измерим с неизвестной точностью "среднюю температуру по больнице" - мы посчитаем число школьных зданий по всему миру в проекте OpenStreetMap. И когда говорят что образование избыточно и в школе дают много лишних знаний, то сразу же хочется задать компьютеру этот вопрос, сверив его с географией.
Данный материал был создан на основе одноимённого доклада на PGConf.Online, вошедшего в число самых популярных выступлений конференции. Поскольку тема ограничений по-прежнему сохраняет свою актуальность, а смотреть видео с мероприятий любят не все, появилась эта статья.
Концепция “тупого хранилища”
В последние годы разработчики ПО всё чаще утверждают, что база в их проекте “всего лишь тупое хранилище, и поэтому никакой логики в ней нет”. Откуда такой подход? Обычно он объясняется сложностями миграции, развёртывания, неудобствами при работе с системами контроля исходного кода. Не стоит списывать со счетов и простую человеческую лень: раз всё и так нормально, зачем связываться с логикой в СУБД? Создали таблицы (или, ещё лучше, пусть ORM их создаст!), и всё отлично.
NoSQL для документов
Случай с NoSQL ещё проще – не надо ничего создавать, контролировать и напрягать мозги, всё уже автоматизировано, оно само работает. Этого вполне достаточно, если из базы нужно просто доставать документы по идентификатору, но если требуется решать задачи посложнее, то всё-таки выбирают SQL СУБД. Их использование, однако, ограничивается созданием таблиц и индексов, логика на стороне СУБД и в этом случае видится избыточной.
СУБД: не только технология, но и бизнес-инструмент
Такой подход является очень распространённым (люди вообще ленивы!). Тем не менее, крайне наивно дистанцироваться от хороших возможностей только из-за нежелания заморачиваться и приобретать новые навыки. СУБД – это очень изощрённая система хранения (чтобы понять это, достаточно почитать про уровни изоляции или процедуры резервного копирования). СУБД помогает синхронизировать бизнес-процессы и избежать реальных убытков, иногда в очень крупном размере.
Сегодня я хочу поговорить с вами про такую замечательную вещь как Point in time recovery (PITR) в PostgreSQL.
Механизм восстановления на определенную точку во времени работает таким образом – у нас есть базовый бэкап, созданный при помощи какой-либо утилиты создания бэкапов (например pg_basebackup), а также набор журнальных файлов, постепенно применяя (накатывая) который, мы можем восстановиться до указанной точки.
Звучит это довольно просто, но, как водится, в каждой простой вещи есть какие-то нюансы, вот о них мы сегодня с вами и поговорим.
Одно я могу сказать точно: миграция данных между двумя БД - это одна из, если не самая сложная часть при смене СУБД или схемы базы данных. И что-то мне подсказывает, что Вы не фанат громоздких, чрезвычайно трудно отлаживаемых, SQL конструкций.
Часто бывает, при ближайшем рассмотрении некоторая проблема выявляет более глубокую, погружаясь в решение которой находишь для себя много интересного.
О такой ситуации на одном из наших проектов и пойдет речь.
Привет, я - Алмаз Мустакимов, ведущий разработчик одного из бизнес-центров в компании «БАРС Груп». Мы более года работаем над мобильным приложением, которое фактически позволяет получить любые услуги здравоохранения в режиме единого окна, без многочасовых квестов по поликлиникам.
Несмотря на общую популярность и тренд, Massive Parallel Processing (MPP) РСУБД всё ещё очень редко используются для целей автоматизации маркетинга (платформы aCRM). Часто быстрее и удобнее использовать классическую РСУБД. Однако рано или поздно организации приходят к тому, что вертикальное масштабирование уже не спасает, а бизнес продолжает расти.
В рамках данной статьи хотим поделиться опытом использования Massive Parallel Processing (MPP) РСУБД на примере GreenPlum в проекте внедрения платформы aCRM для автоматизации маркетинговых процессов в крупном Retail.
С этого сообщения в мессенджере началось мое масштабное расследование вопроса, который давно не дает спать многим айтишникам — можно ли вот так взять и переехать с Oracle на «свободную» СУБД PostgreSQL?
Этот вопрос сначала бередил умы только тех, кто был в курсе стоимости закупок лицензий. В крупных компаниях бюджет на это мог составлять несколько десятков миллионов долларов. А потом каждый год поддержка вендора «съедала» ещё 22% от стоимости лицензий. Теперь та финансовая боль сменилась другой, и у компаний поменялся запрос: а можно ли заменить? И главное, можно ли организовать это в разумные сроки и по адекватной стоимости?
Скажу сразу, что в этом посте не будет технических аспектов миграции с СУБД Oracle на PostgreSQL. Как это делать и как обходить сложности — разберем в следующий раз. Тут же больше поговорим о целесообразности и возможности миграции. С этим мы разбирались в ходе одного проекта, а заодно развенчали строй существующих иллюзий.
Эта статья завершает цикл о миграции с СУБД Oracle на СУБД PostgreSQL. В первых двух статьях рассматривались проблемы и устоявшиеся способы переноса данных из одной СУБД в другую (часть 1, часть 2). В третьей статье была представлена часть особенностей, которые нужно учесть при переводе хранимого кода с PL/SQL на PL/pgSQL. В сегодняшнем материале рассматривается оставшаяся часть особенностей, адаптация и конвертация кода, включая выбор средств для конвертации.
Глобальные структуры данных уровня пакета
Для таких структур рекомендуется использовать модуль pg_variables. Он позволяет сохранять как скалярные значения, так и множество записей, массивы
При этом нужно понимать, требуется ли собирать статистику для планировщика. Если да, то придётся пользоваться временными таблицами. По возможности, их лучше не использовать слишком интенсивно. Создание и удаление временных таблиц ведёт к изменениям в системном каталоге и сообщениям об инвалидации. Может возникнуть ситуация, когда серверным процессам для своей работы придётся многократно перечитывать системный каталог.
Пример: у одного клиента процессы Postgres тратили большое количество времени на планирование запросов, поскольку они многократно пытались прочитать данные pg_statistic и pg_class и при этом взять соответствующие блокировки на самые распространённые объекты. Соответственно, от создания и удаления временных таблиц на каждую транзакцию пришлось отказаться.
pg_variables можно использовать на реплике – работа с модулем не приводит к изменениям в системном каталоге. Временные таблицы использовать не получится, поскольку реплика не позволяет делать изменения в словаре данных.
В предыдущих статьях о миграции с Oracle на Postgres мы рассматривали перенос данных из одной системы управления базами данных в другую (часть 1, часть 2). Сегодня разговор пойдёт об особенностях работы с кодом приложения при необходимости смены СУБД. В частности, будут рассмотрены следующие вопросы:
Пройдя много собеседований, выяснилось, что довольно приличная часть собеседующих, спрашивавших или как-то затрагивавших тему транзакций и их работы, не знают как работают транзакции и что означает для разработчика термин изоляция. Вплоть до архитектора в одной очень большой российской компании, для которого выводы, использованные мною для формулирования решения при прохождении архитектурной секции оказались чем-то вроде бреда. Пока готовится вторая статья (Миллиард абитуриентов МИРЭА 2), можно отвлечься и разобрать тему, продемонстрировать разработчикам что означает для них I в ACID.
Все об использовании шаблонов в Airflow с примерами кода. Продолжение серии публикаций astronomer.io