Базы данных *

Всем привет! Мы делаем проекты по Zabbix, накопили большую экспертизу и решили сделать переводы нескольких статей, которые нам показались интересными и полезными. Наверняка, будут полезны и вам. Также своим опытом делимся в телеграм-канале zabbix_ru, где вы можете найти полезные материалы и записи наших вебинаров, опубликованных на нашем ютуб-канале (прим. переводчика). Ниже ссылки на предыдущие статьи из цикла.

Миграция с MySQL на PostgreSQL

SELinux: интеграция с Zabbix и другими инструментами

Защита от ложных срабатываний триггеров в Zabbix с использованием функций min/max/avg

Zabbix – автоматизация управления пользователями (JIT)

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

Если вы работаете с ClickHouse, то наверняка слышали про такую фишку, как внешние словари. А если не слышали, самое время узнать, потому что эта штука способна творить чудеса с производительностью запросов и удобством архитектуры.

В этой статье разберем ее подробнее.

ПД — персональные данные.

Пока в одних компаниях заставляют подписать согласие на обработку ПД даже «мимопроходил», другие не имеют точного представления, что это за документ и для чего он нужен. 

Давайте прямо сейчас поставим жирную точку в этом вопросе. Разобраться — дело пяти минут. Засекайте.

Стабильная и быстрая работа платформы «1С:Предприятие» — критически важный фактор для бизнеса. Команда Postgres Professional ведёт постоянную работу над совершенствованием ядра СУБД, устраняя архитектурные узкие места, которые проявляются при высоких нагрузках, характерных для 1С.

Недавно мы выпустили Postgres Pro Enterprise 17.6, куда добавили новый пакет улучшений для 1C. 

Слышали о ГИС ГМП? Скорее всего, мало кто слышал. Зато точно видели, если:

— вам на Госуслуги приходила пошлина на оплату нового загранпаспорта

— вы получали уведомление о штрафе ГИБДД в банковском приложении

— вы узнавали состояние своего единого налогового счёта (ЕНС)

Чтобы всё это стало возможным, Федеральное Казначейство создало Государственную информационную систему о государственных и муниципальных платежах (ГИС ГМП). Именно она аккумулирует все назначенные людям и компаниям платежи и контролирует их оплату, сверяя платёжные поручения банков с начислениями.

Как вы думаете, много ли там начислений? А платежей? Сотни миллиардов.

В рамках импортозамещения нам в РТЛабс поставили задачу — мигрировать ГИС ГМП с базы данных Oracle на другую подходящую. Да-да, нам предстояло мигрировать систему, которая хранит сотни терабайт данных — кому и что было начислено, как и когда это оплатили.

Как нам это удалось? Именно об этом я и хочу рассказать. На связи Михаил Денисов — технический директор блока развития казначейских проектов.

Данная публикация является переводом статьи Jeff-a Atwood-а почти 20-ти летней давности. Jeff Atwood, один из фаундеров StackOverFlow, написал эту статью как некоторое резюме того, как человечество боролось с проблемой O/R Impedance Mismatch.

Я частично принимаю участие в написании разных ORM решений, например, Spring Data JDBC / R2DBC, и скоро мы вместе с Amplicode проведем online событие (оно бесплатное) по Spring Data JDBC. Будем обсуждать Spring Data JDBC, что в ней хорошо а что в ней плохо. Какие trade-off-ы она имеет.

Я решил выпустить данный перевод с целью того, чтобы напомнить людям - silver bullet-а Spring Data JDBC не придумала. Она лишь заняла конкретную позицию по ряду вопросов, из чего следуют определённые ограничения и преимущества. Их мы и обсудим.

Чистые улицы Калифорнии и свободный доступ к передовым технологиям — мечта любого айтишника 90-х. Но он предпочёл вернуться в страну, где ещё ничего не было, и построить своё с нуля.

В подкасте  «В Офисе» я, Ваня Ботанов, автор телеграм-канала «Деплой» вместе с Олегом Бартуновым. Поговорили о том, почему AI не заменит инженера, и зачем сегодня так важно инвестировать в ИТ-образование. Это вторая часть интервью — не только история развития одного из главных российских open source проектов, но и редкий разговор про деньги, принципы и долгосрочное мышление.

— Какое-то время назад начался отток IT-специалистов из России. Как вы к этому относитесь?

— Я не считаю это чем-то критически страшным. В основном уезжают молодые ребята, и для молодежи нормально поехать, посмотреть, как живут в других странах. Многие большие проблемы в мире и в политике возникают из-за того, что люди не путешествуют. Недавно читал статистику: до недавнего времени 98% граждан не имели загранпаспорта. Что они могут думать о других странах, если никогда в них не были? У них нет критического мышления. А те, кто ездят, видят другую жизнь, понимают, как и где живут люди, какие плюсы и минусы, и их гораздо сложнее зомбировать.

— Где, на ваш взгляд, лучше жить?
— Конечно, там, где родился. Мы родились здесь, у нас своя ментальность. Хотя, например, я был 26 раз в Непале, и мне там очень нравится — чувствую себя комфортно. Думаю, это связано с историческими корнями, я как бы — степной кочевник, но подозреваю, что мой народ всё-таки пришёл из гор. А молодежь, которая уехала, посмотрела мир — если создать им условия, они вернутся.

Меня зовут Андрей Серебрянский, и я люблю Apache Kafka. И гарантии доставки exactly once. И рассказывать обо всём этом на конференциях. Пять лет я строил платформы потоковой обработки данных в финтехе, а теперь вместе с командой работаю над YDB Topics: частью YDB (СУБД Яндекса), которая заменяет Apache Kafka в роли брокера сообщений. СУБД Яндекса уже некоторое время поддерживает Apache Kafka API. Недавно мы расширили этот API, добавив поддержку Kafka-транзакций.

Но наличия транзакций в брокере сообщений недостаточно для получения гарантий exactly once. Чтобы неудачно зависший или перезагрузившийся сервер не привёл к дублированию или потере сообщений, нужно хорошо понимать, как именно работают транзакции в брокерах сообщений вообще и в Apache Kafka в частности.

Эта статья будет полезна начинающим разработчикам и тем, кто хочет освежить знания или разобраться в тонкостях exactly once обработки данных с помощью YDB Topics или других брокеров сообщений.

Зачем сразу тянуть в проект тяжёлую артиллерию типа Elasticsearch, если нужно просто поискать по тексту статей? Ведь у PostgreSQL есть свой, встроенный полнотекстовый поиск. Многие о нём забывают.

Всем привет! Мы давно и усердно работаем по направлению наблюдаемости и регулярно находим интересные статьи. Например, в этой вы узнаете подробности об устройства популярной системы хранения временных рядов — VictoriaMetrics. Перевод мы сделали специально для телеграм-канала Мониторим ИТ. Подписывайтесь! Там еще больше полезных постов о мониторинге.

VictoriaMetrics — это высокопроизводительная и масштабируемая база данных временных рядов и решение для мониторинга. VictoriaMetrics разработана для сбора, хранения и запроса больших объёмов данных временных рядов, что делает её идеальной для мониторинга инфраструктуры, приложений и IoT-устройств. Она поддерживает модели приёма данных как pull (сбор данных в стиле Prometheus), так и push (различные протоколы). Подробности под катом.

В интернете есть много статей на тему «как перевести старую систему с Oracle на PostgreSQL». Как мигрировать схему данных, сами данные и логику. Не буду повторять это, просто сравню две СУБД на небольшом вымышленном учебном примере. Я расскажу про то, как организовать процесс написания и проверки кода системы для PostgreSQL, чтобы на выходе получился продукт даже более качественный, чем он мог быть без смены СУБД.

Чтобы было интереснее, я решил объединить два жанра и сделать техническую статью в виде фантастического рассказа. Тут будет и мультивселенная, и путешествия во времени. Вся фантастика оформлена в виде цитат, чтобы те, кто хочет просто факты, могли не терять время.

Привет, Хабр! Меня зовут Кирилл Тарасов, я — инженер данных в K2Tех. Наша команда Big Data & Bi работает с 2006 года, мы активно занимаемся Greenplum, Arenadata Hadoop/Streaming и внедряем собственные наработки, такие как ELT Framework. Также с 2012 года мы создаём аналитические системы и хранилища данных, и за это время моя команда столкнулась с самыми разными ситуациями, которые вызывали различные проблемы для реальной продуктивной эксплуатации СУБД. Некоторые из них были связаны с настройками баз данных, другие — с компонентами защиты, а третьи были настолько необычными, что их причиной оказалось исключительно странное и редкое поведение бизнес-логики, с которым разработчики хранилищ данных почти не сталкиваются. В этой статье вы найдете шесть кейсов, которые могут встретиться на любом проекте. Они помогут избежать попадания «ложки дегтя» в ваше хранилище.  

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

Вместо 3 часов дебага падающего Prometheus вы смотрите дашборд, который показывает 99.9% uptime вашего мониторинга.

Это реальность с правильно настроенным стеком на основе VictoriaMetrics.

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо.

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

В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

Упереться в лимит 4 миллиарда строк в TOAST-таблице или поймать OidGen lock при массовой заливке документов — страшный сон администратора PostgreSQL. Хотя архитекторы советуют выносить файлы в S3, реальность часто диктует хранение внутри БД. Руководитель группы по оптимизации приложений Александр Попов разбирает, как работают стандартные механизмы bytea и pg_largeobject, где находятся их «бутылочные горлышки» и как эти ограничения обходятся в Postgres Pro Enterprise.

Чтобы транзакции в InnoDB работали предсказуемо, важно понимать внутреннюю логику InnoDB. Ошибки чаще всего возникают не из-за отсутствия транзакций, а из-за неверных ожиданий относительно уровней изоляции и работы блокировок.

В этой статье давайте разберём несколько распространенных заблуждений и на примерах посмотрим, как на самом деле работают транзакции.

В Kubernetes короткий жизненный цикл подов — норма. Но когда лидер-узел MySQL внезапно исчезает, рискуешь потерять не только доступность, но и согласованность данных. Оператор Moco предлагает решение: полусинхронная репликация, автоматический failover и восстановление с PITR — всё это без боли миграции на полностью синхронную репликацию.

В статье — детали репликации, бэкапов, PITR, switchover и нюансов работы с пользовательскими образами. А также честно — чем он лучше (и хуже) альтернатив, и стоит ли его рассматривать для продакшена.

Зачем вообще делать что-то своё?

Я знаю, что вы можете подумать: «Почему бы просто не использовать Elasticsearch?» или «А что насчёт Algolia?» Это вполне рабочие решения, но у них есть нюансы. Нужно разбираться с их API, поддерживать инфраструктуру под них и учитывать все тонкости их работы.

Но иногда хочется чего-то более простого...

Иногда в архиве нашего сервиса анализа планов запросов к PostgreSQL встречаются примеры не очень эффективных, мягко говоря, запросов.

Сегодня на примере одного из них, вызванного простой бизнес-задачей, посмотрим, как отказ от использования агрегатных функций может ускорить запрос в разы.

Что общего у массового применения конфигураций, встроенной поддержки OpenTelemetry и управления HA-кластерами в пару кликов? Всё это — части пазла, который мы собираем, чтобы сделать администрирование PostgreSQL по-настоящему удобным и безопасным. Выход версии Postgres Pro Enterprise Manager (PPEM) 2.3 стал важной вехой в развитии нашего графического интерфейса. Мы добавили поддержку пользовательских пресетов, переработали систему алертинга и усилили RBAC-модель управления доступом. Разбираем ключевые нововведения релиза, которые помогут навести порядок в зоопарке конфигураций и спать спокойно, зная, что система сама предупредит о проблемах.