Coolify это бесплатный инструмент, который позволяет легко запускать приложения на ваших серверах и управлять ими через визуальный интерфейс.
В прошлых статьях мы уже разобрались, как подготовить сервер, затем установить на нём Coolify и запустить простые приложения из GitHub.
А сегодня посмотрим, как с помощью Coolify создать базу данных на своем сервере и какие преимущества это даёт.
Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты. Все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.
А в мае 2024-го репозиторий был закрыт. Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты, изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.
В этой статье попробую проанализировать, где вчерашние пользователи и контрибьюторы в Greenplum могут найти решения, у которых есть будущее.
В крупных корпорациях большинство инновационных разработок защищены даже не столько патентами, сколько внутренней документацией, относимой к категории «коммерческой тайны». Если сотрудник заберет для своих целей эти материалы и использует их, то его точно привлекут к ответственности. Примеров — масса. Вспоминаем самые громкие процессы.
Я постараюсь, не углубляясь в технические дебри, в научно-популярном ключе рассказать о распределенных KV-хранилищах: что это вообще такое, где применяется и почему мы выбрали именно etcd.
Если вы администрируете системы хранения данных, наверняка сталкивались с ситуациями, когда стандартных средств Device Manager оказывается недостаточно. Может потребоваться более глубокая диагностика, сбор расширенных логов или подготовка компонента к замене. Именно для таких случаев предусмотрен режим Minisystem — специальная сервисная среда с расширенным набором команд. В этой статье в блоге ЛАНИТ мы собрали наиболее полезные из них.
Вы пришли из мира PostgreSQL, Oracle или MSSQL. Вы знаете: материализованное представление — это «замороженный» результат запроса. Удобно. Предсказуемо.
Вы открываете документацию ClickHouse. Видите знакомые слова. Радуетесь. Пишете свой первый MATERIALIZED VIEW. Запускаете. И... получаете не то, что ожидали.
Потому что в ClickHouse материализованные представления работают СОВСЕМ не так, как везде.
Привет, Хабр! Меня зовут Даша Александрова, я 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, можно использовать недолгие тесты и оптимизировать приложение и параметры экземпляра, используя результаты недолгих тестов для обратной связи при настройке.
Конференция прошла 23-24 марта в московском Центре Международной Торговли, а на днях для участников выложили видео, презентации и фото. В этом году конференцию посетило примерно 1300 очно и 800 заочно. По сравнению с прошлой конференцией она немного подросла: на PGConf.Russia 2025 было 1120 очных, в сумме около 2 тыс. человек. Конференция претерпела лёгкий ребрендинг: PGConf.Russia => PGConf.Россия (переход плавный: PGConf.СПб 2025, а не SPb). Доклады на этот раз проходили в 4 залах (на прошлой - в 3): главный - сдвоенный и 3 зала поменьше. Один из них был отдан целиком Postgres Pro. Ещё в 2 залах проходили мастер-классы.
EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.
Архитектурный принцип Lakehouse предполагает, что вы оперируете всеми данными, загруженными в систему. Но иногда нужно выполнить ad hoc анализ за ее периметром, потому что необходимых данных по каким-либо причинам нет в Lakehouse-платформе. В этом случае на помощь приходит федеративный доступ. Стандартом для такой задачи является движок Trino. Он умеет извлекать данные из внешних СУБД и даже в некоторых случаях может делать push-down определенных вычислений на сторону системы-источника. Главное, чтобы под рукой был подходящий connector для нужной СУБД, который умеет эффективно с ней работать.
Недавно в состав Data Ocean Nova был добавлен новый Trino Teradata Connector. Он позволяет пользователям «подтягивать» необходимые срезы данных из Teradata в рамках ad hoc запросов и решает задачу эффективной передачи данных: можно передавать терабайты в несколько потоков без существенного увеличения нагрузки на источник.
В данной статье разберем:
• Как организовать эффективную многопоточную работу с Teradata: где часто допускают ошибки, как должно выглядеть правильное решение;
• Какие возможности дает Nova Trino Teradata Connector: многопоточная передача, push-down оптимизации.
Привет! В этой статье мы, Павел Лобанов — старший инженер в платформе отправлений и Дмитрий Сидоренко — старший инженер в логистической платформе доставки Авито, расскажем, как решили проблему раздувания размера данных в хранилище без прерывания работы сервиса, сохранив лояльность пользователей и деньги компании.
Эта история о том, как мы придумали и реализовали свой собственный метод, когда никакие другие сторонние инструменты не позволяли сохранять работоспособность сервиса и гарантировать надёжность. Его можно применять во всём мире, где используются платформы на базе PostgreSQL.
Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось.
Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже начали жаловаться, что поиск тормозит.
Так обычно и проявляются проблемы с поиском в продакшене. Не как драматичный сбой, а как медленное, ползучее ухудшение. Чуть больше трафика здесь, чуть больше индексации там, и прежде чем вы это заметите, производительность уже просела.
К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?
Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.
CSV-файлы редко бывают такими простыми, какими кажутся на первый взгляд. За внешней структурой часто скрываются проблемы с типами, разделителями, схемами и «сломанными» строками, из-за которых загрузка данных превращается в цепочку костылей и ручной предобработки. В этой статье — практический разбор того, как DuckDB позволяет диагностировать и обрабатывать такие случаи прямо в SQL: от понимания того, как система интерпретирует файл, до устойчивой загрузки и работы с неконсистентными данными.
Человек — все-таки существо бренное. А наследие, созданное им, может пропасть навсегда. В истории уже были примеры полного или частичного уничтожения объектов исторического и культурного наследия. В том числе печатного. Чтобы не терять основы прошлого — созданы несколько цифровых библиотек, цель которых — сохранение и распространение бесплатных книг. Об этих проектах подробнее в нашей статье.
Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3.
Продолжая тему инструментов, интегрированных в среду разработки, сегодня мы рассмотрим клиент для работы с базами данных, доступный пользователям GigaIDE. Для пользователей Community-версии доступен open source-плагин DB Navigator, который хорошо описан, например, здесь. Пользователям PRO-версии доступна пара расширений:
SQL — синтаксическая поддержка и форматирование SQL-кода;
Database — клиент баз данных с широким набором возможностей.
В статье - обзор доклада Алексея Копытова (автора sysbench) на конференции PG BootCamp 2026.
Доклад заинтересовал меня тем, что я только после конференции узнал, что Алексей - создатель утилиты sysbench, работал в MySQL AB (High Performance group within the MySQL Support Team) и Percona. MySQL используется в больших компаниях там, где нужна большая производительность. Это значит, что в мире MySQL есть разработчики, которые хорошо понимают архитектуру реляционных баз данных, то есть могут быстро внести в PostgreSQL программные решения из MySQL, которые повысят производительность и отказоустойчивость PostgreSQL.
Доклад Алексея Копытова шёл за докладом Вадима Яценко, чей доклад представил слушателям новую СУБД Tantor Polar. На момент доклада, за две недели до конференции, была опубликована статья, где подробно описывалась новая архитектура, поэтому выступление Яценко вызвало особый интерес и явилось публичной презентацией этих наработок.
Начиная с Manticore Search 24.4.0, компактизация RT-таблиц использует более эффективную модель выполнения. Вместо последовательного слияния пар чанков оптимизация теперь поддерживает два важных улучшения:
Из этого материала вы узнаете о том, как работают векторные базы данных, разобравшись с широким диапазоном тем — от основ поиска по сходству, до стратегий индексирования, которые позволяют применять на практике крупномасштабный поиск данных.
