Писать SQL руками или использовать ORM — тема очень спорная, и я опишу, как использовать первый подход максимально эффективно. А какой из подходов выбрать, думаю, каждый сам для себя уже решил.
Автор статьи: технический руководитель проектов внедрения 1С:ERP Внедренческого центра «Раздолье» Дмитрий Малышев.
Миграция базы данных 1С с MS SQL на PostgreSQL – по-прежнему насущная тема, особенно в контексте импортозамещения. На наших вебинарах и в беседах с клиентами мы получаем много вопросов по нюансам миграции. Решили собрать основные рекомендации в одну статью.
Привет, Хабр! На связи Михаил Семенов, лидер дивизиона баз данных в СберТехе, Артем Лаптев, руководитель эксплуатации продукта Platform V Pangolin в SberInfra, и Вячеслав Гавришин, руководитель команды развития Platform V Pangolin в SberInfra.
В этом посте мы поделимся историей импортозамещения систем управления базами данных в Сбере и опытом миграции с MSSQL и Oracle на собственную СУБД Platform V Pangolin. Расскажем, как разрабатываем и кастомизируем отечественную СУБД уровня enterprise и какие решения помогли нам упростить процесс миграции и использовать продукт в микросервисной архитектуре банка.
PostgreSQL - это система управления реляционными базами данных с открытым исходным кодом, которая используется в непрерывной разработке и продакшне уже 30 лет. Почти все крупные технологические компании используют PostgreSQL, поскольку это одна из самых надежных, проверенных в боях систем реляционных баз данных на сегодняшний день.
PostgreSQL является критически важной точкой в вашей инфраструктуре, поскольку в ней хранятся все данные. Для этого важна наглядность, а значит, вы должны понимать, как работает протоколирование в PostgreSQL. Это достигается с помощью журналов и метрик, которые предоставляет PostgreSQL.
В этой статье я объясню все, что вам нужно знать о журналах (логах) PostgreSQL, начиная с того, как их включить и заканчивая тем, как их легко форматировать и анализировать.
Опрос о состоянии PostgreSQL 2022 завершился несколько недель назад, и мы усердно работаем над очисткой и анализом данных, чтобы поделиться с сообществом PostgreSQL максимально полной информацией.
В сообществе по базам данных обычно из года в год множество дискуссий вызывают две вещи: производительность и инструментарий. В этом году мы немного скорректировали вопросы, чтобы сосредоточиться на конкретных случаях использования и инструментах 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 конструкций.
Часто бывает, при ближайшем рассмотрении некоторая проблема выявляет более глубокую, погружаясь в решение которой находишь для себя много интересного.
О такой ситуации на одном из наших проектов и пойдет речь.
Привет, я - Алмаз Мустакимов, ведущий разработчик одного из бизнес-центров в компании «БАРС Груп». Мы более года работаем над мобильным приложением, которое фактически позволяет получить любые услуги здравоохранения в режиме единого окна, без многочасовых квестов по поликлиникам.
