Привет! Меня зовут Ильсаф, я инженер данных в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов. В этой статье я собрал свои практические наблюдения по работе Kafka Connect и Debezium с PostgreSQL: от настройки репликации до мониторинга и бэкфиллинга.
Чтобы подготовить КП по сложному инженерному проекту, одного менеджера недостаточно. Нужно собрать расчёты от нескольких специалистов, а после согласования решения проверить наличие сотен позиций на складе и докупить недостающее. Когда это ведут в разных системах, растёт доля ручных операций и риск ошибок. Рассказываем, как собрали единый цифровой контур для управления сложными продажами и закупками в on-prem BPMS на Linux и PostgreSQL.
jsonb легко полюбить. Он даёт гибкую схему, позволяет не плодить десятки мелких колонок, хорошо подходит для полуструктурированных данных и обычно очень удобен на старте проекта. Пока документы маленькие и меняются редко, кажется, что всё отлично.
Проблемы начинаются позже. Данные растут, в документ добавляются новые поля, часть из них начинает часто обновляться, а потом внезапно выясняется, что вроде бы безобидный UPDATE одного ключа внутри jsonb стоит заметно дороже, чем ожидалось.
В этой статье мы не собираемся доказывать, что jsonb плохой тип данных. Наоборот: jsonb – один из самых полезных инструментов PostgreSQL. Хотелось бы разобраться в более узком вопросе:
что именно происходит, когда мы обновляем один ключ внутри большого JSONB-документа, и чем это отличается от обновления обычной колонки рядом с таким же большим документом?
На протяжении уже лет пятнадцати мы сталкиваемся с вопросом типа: «А вы уверены, что без обрезки никак?». Речь идёт о многотерабайтных базах 1C: десять лет назад это были базы 1-2 Тб, а сейчас это уже десятки Тб. Специалисты меняются, железо становится мощнее, но вопрос остаётся.
Пожалуй, можно поделить участников этого опроса на две группы: «Резать к чёртовой матери» и «Полный бред резать базу – нужно правильно обслуживать и заложить нормальную архитектуру».
Я разрабатываю PWA для голосовой практики английского. Несколько раз пытался опубликовать его в RuStore через Trusted Web Activity (TWA) — Google-обёртку, которая упаковывает PWA в подписанный Android AAB. После четырёх отказов модерации я понял, что для моего класса приложений TWA в RuStore не работает, и за день переключился на Telegram Mini App.
Эта статья — не история стартапа, а разбор технических решений:
Привет, Хаброжители! Исправление ошибок в базах данных PostgreSQL может быть трудоемким и рискованным процессом — особенно при внесении изменений в работающую систему в реальном времени. К счастью, можно учиться на ошибках, которые уже совершили другие! Автор подробно описывает, как выявлять и предотвращать самые распространенные, опасные и скрытые антипаттерны проектирования при работе с PostgreSQL.
Думал, зайду в крипту и буду просто дёргать API блокчейна. Не вышло.
Захожу в проект. Стек: FastAPI, PostgreSQL, Redis как Celery broker, Celery workers, Docker, Web3. Стартап на хайпе, деньги реальные, архитектура собрана на коленке. Смотрю на архитектуру платёжного процессинга и первая мысль: ребята, вы серьёзно? Финансовые операции с реальными деньгами, без idempotency вообще, Redis как брокер без persistence, Web3.py синхронные вызовы внутри Celery тасков.
Разговор был короткий: задача такая, чини что есть. Сроки горели.
В конце апреля мы выпустили очередное обновление нашей системы резервного копирования Кибер Бэкап. В этом обзоре познакомимся с новыми и обновленными функциями, включенными в релиз, а также расскажем о ключевых направлениях развития продукта.
Все началось с того, что мне поставили задачу: «У менеджеров есть большой телевизор. Сделай так чтобы у них там крутились красивые циферки и графики с результатами продаж».
Ни одна «одна технология» не закрывает это без слоёв. Сначала — почему в стеке именно Kafka, PostgreSQL и Redis; дальше — как мы спроектировали сервис Requester: контекст, движение данных, внутренние воркеры, graceful shutdown, детали rate limit / retry / cache / отложенных задач, wake-up, тестирование и узкое место с большими payload в Redis.
Последние полгода я работаю над VibeMuvik — кино-соцсетью с рецензиями, дебатами и синхронным просмотром фильмов. Одна из тех штук, которые «ну вроде несложно», пока не начинаешь копать.
Эта статья — про неожиданные находки. Не про «как я выбрал стек» (скучно) и не про «туториал по WebRTC» (и без меня есть). Это пять ситуаций, в которых я споткнулся, обнаружил что-то интересное, и подумал «об этом стоит рассказать — другим пригодится».
Поехали.
Автор прекрасно понимает, что тема ERP/CRM систем обсосана со всех сторон ещё десятилетие назад. Огромное количество разработчиков и по сей день зарабатывают на внедрении систем на подобии 1C:ERP в предприятия. Однако поспешу обрадовать читателя, сегодня я попытаюсь описать процесс создания своего рода аналога такой системы на довольно необычном для этой сферы стеке и углубиться в тонкости её устройства.
Проще говоря, я опишу процесс создания системы управления малым бизнесом на Go, опишу ключевые архитектурные проблемы, возникшие передо мной и затрону ряд зависимостей, которые я успешно приобрел и преумножил в процессе реализации такого инструмента (включая трамадоловую и алкогольную). Кроме того в этой статье затрагиваются аспекты реализации SAAS-подобных систем с физической изоляцией данных, что в свою очередь применимо к огромному количеству сфер разработки, кроме ERP систем.
Потоковая репликация - это хорошо зарекомендовавшая себя техника физической репликации в режиме мастер-реплики. Она проста в настройке, стабильна и демонстрирует высокую производительность. Многие удивляются, когда узнают о конфликтах при репликации - ведь реплики работает только в режиме чтения.
В статье описываются конфликты репликации и как с ними бороться.
В инфраструктуре почти не бывает задач «на один клик»: за деплоем тянутся CI/CD, за Kubernetes — эксплуатация, за нагрузкой — Nginx, Postgres, мониторинг и безопасность. В этом выпуске собрали материалы и ближайшие открытые уроки по тем темам, в которые чаще всего приходится погружаться уже на практике. Это хороший способ быстро разобраться в конкретной теме, посмотреть на рабочие подходы и понять, что стоит изучить уже системно.
Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты. Все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.
А в мае 2024-го репозиторий был закрыт. Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты, изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.
В этой статье попробую проанализировать, где вчерашние пользователи и контрибьюторы в Greenplum могут найти решения, у которых есть будущее.
Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.
Причина миграции — импортозамещение.
Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.
Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.
Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует.
Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.
Ожидания получения BufferPin включают в себя:
1) Конфликты BufferPin на репликах (recovery conflict). Процесс на реплике startup должен получить блокировку на буфер, чтобы проиграть (replay, apply, накатить журнальную запись) HOT cleanup блока, для этого startup должен дождаться pincount=0. Быстрая очистка (HOT cleanup) выполняется на мастере серверными процессами очень часто и процесс startup, если столкнется с блоком, закреплённым запросом на реплике, полностью приостановит накат и будет ждать снятия закреплений блока. Накатом занимается только один процесс startup и в один поток. Из-за частых ожиданий BufferPin отставание реплики растёт и кажется, что startup не справляется. Мониторинг таких ситуаций затруднён, так как в представлении pg_stat_database_conflicts отражаются только конфликты, которые привели к прерыванию запросов на реплике, то есть, когда startup приостанавливал работу более, чем на max_standby_streaming_delay (по умолчению, 30 секунд), а в pg_stat_activity поймать ожидание BufferPin, которое длится доли секунды, почти невозможно. Из-за таких конфликтов, компаниии выделяют одну реплику, которая не обслуживает запросы, чтобы она только синхронизировалась и не отставала от мастера. Например, OpenAI, помимо 50 реплик, обслуживающих запросы на чтение, использует реплику, не обслуживающую никакие запросы, чтобы можно было на неё быстро переключиться (упомянута в 6 пункте в статье)
2) конфликты с автовакуумом при заморозке страниц. Такие конфликты есть и на мастере и на реплике и начинаются через 100 миллионов транзакций (по умолчанию, до 18 версии PostgreSQL). При недолгих тестированиях приложений не отлавливаются, проблемы начинаются при эксплуатации. Это одна из причин, по которой нагрузочные тесты длятся долго. Зная, как работает PostgreSQL, можно использовать недолгие тесты и оптимизировать приложение и параметры экземпляра, используя результаты недолгих тестов для обратной связи при настройке.
Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами.
Лучше один раз разобраться, чем каждый раз сомневаться в выборе.
В первой части мы развернули инфраструктуру на базе PostgreSQL и VectorChord, настроили базовые CRUD-операции и запустили гибридный поиск с реранкингом.
В этой части мы заменим игрушечные компоненты на локальные SOTA-модели, сохраняя оффлайн-архитектуру и отказываясь от облачных API. Пошагово развернём llama.cpp-сервер для мультиязычного эмбеддинга Jina v4, поднимем нативный реранкер через transformers + PyTorch, подключим чанкер на базе chonkie и, наконец, оценим качество поиска.
Привет Хабр! Меня зовут Владимир и сегодня я буду развивать тему фишечки VectorChord про которую упомянул в предыдущей статье.
В данном материале я покажу, как поднять инфраструктуру с VectorChord, настроить VechordRegistry, написать пайплайны работы с БД, организовать гибридный поиск и добавить простейший реранкинг.
Поехали.
