Базы данных *

На прошлой неделе мне предоставилась возможность прочитать научную статью 1986 года о создании Postgres как платформы и о исходных целях её проектирования. Меня поразила степень предусмотрительности её авторов и то, как цели проекта заложили фундамент создания системы управления базами данных, постепенно завоёвывающей мир.

Создатели PostgreSQL справились со своей задачей идеально. Они создали гибкий каркас для широкого спектра сценариев использования в бизнесе системы, которая спустя тридцать лет стала самой популярной СУБД.

В статье перечислены следующие шесть целей проекта:

1. улучшенная поддержка сложных объектов, расширяющих сценарии использования в бизнесе и разработке

2. обеспечение возможности расширения типов данных, операторов и способов доступа для пользователей

3. предоставление средств для активных баз данных (например, уведомлений и триггеров)

4. упрощение процесса восстановления после сбоев

5. использование преимуществ нового оборудования

6. применение реляционной модели Кодда

Давайте рассмотрим их с точки зрения современных возможностей Postgres.

В мире баз данных, где каждая миллисекунда на счету, а объемы информации растут как на дрожжах, выход PostgreSQL 18 стал настоящим подарком для разработчиков и администраторов. Это не просто косметический апгрейд, а глубокая перестройка подкапотных механизмов, от облачных хранилищ до высоконагруженных OLAP-систем. Давайте разберемся, что там в этом релизе появилось и/или изменилось.

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

Привет, Хабр! Я — Калашников Сергей, DevOps‑инженер в Центре Перспективных Разработок (ex. R&D) компании Bercut. Cегодня поделюсь опытом внедрения систем на базе Tarantool и Tarantool Vshard в оркестратор Kubernetes.

Tarantool — платформа, которая включает в себя in‑memory базу данных, а также встроенный сервер приложений. На базе этой платформы наша команда разрабатывает различные информационные системы, расширяя функциональность с применением языков Lua, Rust, C\C++.

Несмотря на все очевидные плюсы Tarantool, он не является тривиальным в части конфигурирования и bootstrap. Это привело нас к разработке Operator для Kubernetes, который обеспечивает развертывание и конфигурирование кластеров на базе Tarantool и Tarantool Vshard.

Вот скажите мне, хабравчане, в чём сила? Разве в деньгах? Вот и финдиректор говорит, что в деньгах. А я вот думаю, что сила в данных: у кого данные, тот и сильней!

Техгиганты, вроде Google (Alphabet), Meta (признана экстремистской в России) и Яндекса, получают огромную прибыль с монетизации пользовательских данных; менее очевидные Spotify, OZON и т.п. тоже неплохо зарабатывают на данных и рекламе. Банки каждую секунду проводят сотни тысяч транзакций, небольшие интернет-магазины собирают кучу телеметрии, а социальные сети крутят бесконечные алгоритмические фиды, чтобы вы смотрели свою персональную ленту с котиками и мемами.

Каждый клик, каждое движение мышкой, каждый свайп или тап по экрану — это запись в базе данных. И да, серверы давно умеют с этим всем работать.

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

А вот зачем

Для транзакций в реальном времени нужна одна система — OLTP (Online Transaction Processing), а для аналитики другая — OLAP (Online Analytical Processing). OLTP похож на Соника — он всегда в движении, стремительно мчится вперёд, реагирует на каждое препятствие и собирает колечки. А OLTP — отрабатывает каждую транзакцию быстро и предсказуемо. OLAP же напоминает Кирби — он втягивает в себя всё, что попадётся — горы предметов, врагов, целые миры. А OLAP поглощает массивы данных — миллионы и миллиарды строк, чтобы потом переварить их и превратить в осмысленный отчёт.

Запускать в 2025 году свой майнинг-пул? Серьёзно? Все крупные игроки уже поделены, битва за хешрейт давно закончилась. Но наш клиент пришёл не за «очередным пулом». У него был парк в десятки тысяч ASIC-ов, разбросанных по разным уголкам планеты, и конкретная бизнес-задача — не просто майнить, а делать это с максимальной эффективностью и контролем. И он понимал, что типовые решения его не устраивают. Вот тут-то и началось самое интересное.

Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.

Брокер сообщений YDB Topics во многом вдохновлялся Kafka: в нём также есть топики, партиции и аналогичные способы работы с данными. Но есть и существенные отличия, о которых в конце прошлого года я рассказал на московской конференции HighLoad. Под катом — адаптированная для Хабра статья по мотивам этого доклада: про архитектуру транзакций в обеих системах и интересные для разработчиков детали и нюансы, которые мы обсуждали на конференции.

Команда Python for Devs подготовила перевод статьи о том, как найти самый быстрый способ загрузки данных в PostgreSQL с помощью Python. Автор пошагово сравнил разные методы — от построчных вставок до COPY с потоковой генерацией CSV — и показал, как ускорить процесс более чем в 250 раз при нулевом потреблении памяти.

Недавно я выпустил StringZilla v4 — первый релиз с поддержкой CUDA моей библиотеки для обработки строк. нацеленной в первую очередь на SIMD. Это означает, что теперь она стала быстрой не только на CPU, но и на GPU!

• Я хотел добавить ускорение ROCm для GPU AMD
• Я хотел добавить параллельный мультипаттерновый алгоритм поиска
• Я хотел опубликовать всё это ещё в декабре 2024 года

Итак, не всё пошло по плану, но StringZilla 4 CUDA наконец-то здесь, и она добавляет 500 с лишним GigaCUPS вычислений редакторского расстояния; при этом пакет можно установить через pip install. Также в ней есть некоторые другие трюки, предназначенные для крупномасштабных систем извлечения данных, баз данных и озёр данных, а также биоинформационных задач. И всё это под разрешительной опенсорсной лицензией Apache 2.0, позволяющей свободно использовать библиотеку в коммерческих целях. В этом посте я рассмотрю самые интересные части релиза, и в том числе:

• Быструю оценку алгоритмов динамического программирования на GPU,
• Хэширование CRC32, MurMurHash, xxHash, aHash и не только, а также
• Фингерпринтинг биологических последовательностей 52-битными целыми числами

Можно ли перейти с Oracle или MS SQL на СУБД из Реестра российского ПО без переписывания всей хранимой логики?
Один из возможных подходов к решению этой задачи.

Один из моих коллег сказал когда‑то, что «база данных — это хранилище, а не считалище!». Эту фразу я вспоминал регулярно, пока проводил свое маленькое исследование. Целью данной статьи является описание практического опыта эффективного решения одной из задач ML на существующих аппаратных ресурсах, без аренды/покупки дорогостоящих GPU.

Первого июля 2025 года для российских операторов персональных данных произошла точечная, но важная корректировка правил. Закон № 23-ФЗ, который подписали в феврале, расставляет новые акценты в старой теме — локализации. Речь идёт о том, как именно можно собирать и обрабатывать данные о россиянах.

Любите ли вы SQL так же, как и я? Недавно, собирая огромный SQL‑запрос, я понял, что надо что‑то менять.

Логическим блоком в SQL является подзапрос или CTE и вроде бы можно разбивать запрос по блокам и работать с ними отдельно, как строится по кирпичикам любое приложение.

Однако когда весь текст запроса идет сплошняком на многие экраны, сложно и разрабатывать, и через длительное время понимать алгоритм запроса.

А что, если не надо писать SQL? В SAP мы не писали запросы, мы создавали Calculation View, и работать с ними было на порядок быстрее и приятнее.

Перефразируя диалог из Матрицы:

— Когда я стану избранным, я смогу писать длинный SQL?
— Тебе не надо будет писать SQL.

Работаете с PostgreSQL и хотите попробовать MongoDB? Я спроецировал опыт работы с реляционными БД на NoSQL и собрал два чек-листа: проверенные практики для PostgreSQL и их аналоги для MongoDB.

Без воды, только ключевые пункты чтобы быстро стартовать и не наступать на типичные грабли.

Нормализация vs Денормализация: Mongo, Postgres и реальная жизнь. Почему у нас вырастает 160 таблиц там, где мог быть один jsonb? И как понять, когда денормализация — это костыль, а когда осознанный выбор?

Если при слове «нормализация» у тебя начинается зевота, а менеджер с порога предлагает «спроектировать базу» — этот текст для тебя.

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

Меня зовут Алексей Гуляев. Я архитектор решений в команде VK Tech. В этой статье я расскажу об онтологии в ИТ, вариантах ее использования и нашем кейсе применения онтологического подхода для решения внутренней задачи.

В конце августа вышел релиз распределённой СУБД Apache Cloudberry 2.0.0 — опенсорс‑проекта, который в режиме инкубации находится в Apache Soft Foundation (ASF). В новой версии состоялся переход на кодовую базу PostgreSQL 14, а также было добавлено множество улучшений.

При этом на Хабре до сих пор незаслуженно мало статей, посвящённых этой СУБД. Мы решили исправить это совместно с Максом Янгом, техническим лидером и участником PPMC Apache Cloudberry (Incubating). Эти статьи созданы по материалам совместного митапа Yandex Cloud Data Platform — про Greenplum® и не только. В этот раз пройдёмся по базовым особенностям и функциям этой СУБД, а в следующий — доберёмся до advanced‑возможностей.

Мы рады представить новую возможность, которая делает создание приложений с семантическим поиском таким же простым, как написание SQL-запроса: Автоэмбеддинги. Теперь Manticore Search берёт на себя генерацию эмбеддингов — без дополнительных пайплайнов, внешних сервисов и лишней мороки.

Всем привет! Пополняю интернеты «еще одной» статейкой с бенчмарками популярных СУБД. Захотелось выяснить, каков оверхед на протокол, работу с сетью и клиентскими соединениями в самом простом кейсе — когда таблица либо совсем пуста, либо данных так мало, что все они в памяти.

Бенчмарк на Rust. Я попросил написать его Chat‑GPT, и он отлично справился.

Исходник здесь

Сравнивал с официальными scylla‑bench и redis‑bench — результаты схожи.

Для теста я специально использовал слабую железку — Orange Pi 3b. Это китайский аналог малинки. Захотелось узнать, на что она способна.

Всю свою карьеру инженеры строят системы, которые бережно хранят данные и защищают их от искажений. А что если мы скажем, что иногда правильнее всё делать наоборот: намеренно портить данные, генерировать их из воздуха и создавать неотличимые от настоящих подделки? Системный аналитик Postgres Professional Максим Грамин расскажет, почему создание фейковых данных — это критически важный навык для тестирования, безопасности и разработки, и как научиться делать это правильно, не превращая базу в свалку из «Иванов Ивановых».