Базы данных *

В интернете есть много статей на тему «как перевести старую систему с 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-модель управления доступом. Разбираем ключевые нововведения релиза, которые помогут навести порядок в зоопарке конфигураций и спать спокойно, зная, что система сама предупредит о проблемах.

Всем привет!

Я Senior Java Developer в банке, и за эти годы мне довелось пройти немало собеседований. Где-то было спокойно, где-то — как в допросной, с каверзными вопросами, странными задачами и вечным «а почему так, а не иначе?». В процессе я собрал целую коллекцию тем, которые всплывают снова и снова, особенно когда дело касается баз данных.

Сегодня хочу поделиться этим опытом и разобрать вопросы, которые чаще всего задают именно по SQL-базам.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

Меня зовут Дмитрий Фатов, я разработчик в Газпромбанке — вместе с командой создаю платформу G2, на которой мы разрабатываем свои решения. Одно из решений — SaaS, система, в которой есть внешние интеграции через xml. До какого-то момента к нам приходило максимум 30 тыс. документов в одной выгрузке, но после подключения очень крупного клиента в одной выгрузке начали получать до 2 млн документов. Это около 4 млн записей в базе данных. 

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

В этой статье расскажу именно про последнюю часть — как ускорить вставку данных. Покажу, какие настройки стоит применить для Spring и Hibernate, для чего они нужны и какой буст по производительности дают. Здесь же разберем, как можно создать свою собственную прослойку для вставки данных в PostgreSQL. Эта прослойка позволит нам использовать разные подходы к вставке данных, в том числе кастомные методы PostgreSQL, а также распараллелить процесс вставки. Посмотрим, как ее можно подружить со Spring, а также какой профит нам даст каждый из рассмотренных подходов. 

Я наблюдал, как мой опытный коллега-финансист целый час колупался в Excel. Он гуру экселя, работает с ним 20 лет. Но увидев, как он печатает формулы, я не выдержал и показал пару простых трюков, от которых он пришёл в восторг.

Это была проблема незнания — незнания о функциях, которые лежат в Excel годами, экономят часы работы, но о которых просто никто не рассказывает.

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

Debezium — популярный фреймворк для Change Data Capture (CDC), позволяющий отслеживать изменения в источниках данных (таких как базы данных) и передавать их в потоковые платформы вроде Apache Kafka. Одним из компонентов Debezium является JDBC Sink Connector, предназначенный для записи данных из Kafka в реляционные базы данных посредством интерфейса Java Database Connectivity (JDBC). 

Debezium JDBC Sink Connector может решать множество задач: от репликации данных между БД и синхронизации обновлений между микросервисами до создания резервных копий данных для целей тестирования или разработки. Мы в VK Tech используем Debezium JDBC sink connector, чтобы строить перформанс-интеграции. Но в нагрузочных тестах столкнулись с проблемой производительности, которая не решалась никакими обходными путями. Поэтому нам пришлось детально погрузиться в нюансы обработки событий в Debezium JDBC connector.

Привет, Хабр. Меня зовут Артём Дубинин. Я старший разработчик Backend в команде Tarantool CDC — решения для репликации данных в реальном времени между системами управления базами данных (СУБД). В этой статье я изложу свою интерпретацию создания Debezium, расскажу о том, как работает Debezium JDBC connector, а также о нашем варианте оптимизации перформанса, который попал в Open-source версию.

История началась в далеком 2016 году, когда у меня был небольшой свечной заводик. Не свечной, конечно, но все же производство — и нужно мне было на нем сделать автоматизацию. Чтобы компоненты закупались вовремя, списывались со склада в правильном количестве и автоматически планировалось, какие операции делать в рамках рабочего дня. Тогда я впервые подумал, что неплохо бы иметь программируемый конструктор — что-то типа MS Access, но только в web и чтобы логика и запросы программировались одинаково и понятно.

В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz. 

Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.

Привет, Хабр! Меня зовут Валерий Пташкин, я руководитель направления в трайбе «Потребительское Кредитование» в Сбере. Статью я подготовил вместе с моими коллегами — Кириллом Макаровым и Евгением Беляевым.

Наш продукт отвечает за хранение клиентских заявок на потребительские кредиты, заявок кредитного потенциала, автокредитов, ипотечного кредитования и так далее. И в этом году мы перевели работу нашего модуля хранения с Oracle на СУБД Pangolin (сборка PostgreSQL с доработками от СберТеха).

При переезде у нас было несколько критичных требований к СУБД: способность держать достаточно высокую нагрузку (4 тысячи запросов в секунду), при этом иметь время отклика не более 100 мс для 99 % запросов, и обеспечивать максимально высокую доступность нашего сервиса как системы уровня mission critical.

В этой статье мы расскажем про состояние нашей инфраструктуры, этапы миграции, и коснёмся возможных нюансов и потенциальных рисков. Это будет полезно тем, кто тоже планирует переезд на СУБД Pangolin или другой форк PostgreSQL. Уверен, многие рекомендации пригодятся и пользователям стандартного PostgreSQL. Итак, начнём.

Привет, Хабр! Меня зовут Александр Гришин, я руководитель по развитию продуктов хранения данных в Selectel. Сегодня я предлагаю продолжить разбираться с PostgreSQL и заглянуть еще глубже в эту кроличью нору. Посмотрим, что происходит под капотом СУБД во время записи строк, поверхностно разберем, как устроены страницы памяти, что такое tuple, tuple chain, fillfactor, VM и FSM. Эти знания помогут разработчикам не только понимать, как работает база данных, но и эффективно управлять ее производительностью в продакшене.

Если вы начинающий DBA, разработчик, инженер или архитектор облачной инфраструктуры, эта статья для вас. Погнали?

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

NB! Данный пост является информационным, опубликован с целью показать IT-сообществу как несогласованные действия SMM-специалистов могут отразиться на безопасности проектов в целом. Помните, что незаконный сбор персональных данных карается в большинстве стран мира.