Базы данных *

Это первая статья из цикла, рассказывающая о практике развёртывания небольшого кластера Cassandra: от дефолтного деплоя «из коробки» до готовности к производственной эксплуатации.

Apache Cassandra — это распределенная высокомасштабируемая NoSQL СУБД, предназначенная для надежного хранения огромных массивов данных. Cassandra используют такие гиганты как Netflix, Apple, Instagram*, Twitter* (*Запрещены в РФ), Spotify и множество других известных компаний и брендов.

Здесь не будет рассказа об архитектуре Cassandra — о ней опубликовано очень много статей и снято настолько же много видео. Особо отмечу суперский «Cassandra Day Russia» на Youtube на русском языке, записанный нашими соотечественниками из Datastax. Поэтому, если вы вообще ничего не знаете о Cassandra, то посмотрите, например, вебинар «Введение в фундаментальные принципы и основы Apache Cassandra», а уже затем добро пожаловать в подготовку боевого кластера.

Что касается самого кластера, который мы будем разворачивать, то мне достался раскатанный через Ansible деплой на 5 хост‑машин с единственным образом Cassandra 4.0 в docker‑compose и дефолтными настройками. Пятерка хост‑машин представляет собой Core i5 / 64 GB RAM / 2 x 512 GB NVMe SSD / 16 TB SATA c Debian 11.

Пожалуй, это небольшой кластер (большие кластера Cassandra могут включать десятки и сотни нод, раскиданных по многим ДЦ в разных странах мира), однако для наших задач он вполне достаточен и главное решает потребности бизнеса.

Приступим?

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

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

Привет, Хабр!

Сегодня рассмотрим, как работает fillfactor в PostgreSQL — тот самый параметр, который никто не трогает, пока таблицы не начинают раздуваться как на дрожжах. Разберём, зачем он нужен, что происходит при UPDATE, когда стоит менять его вручную и как не наломать дров.

Переезд крупных, высоконагруженных систем с одной СУБД на другую — всегда вызов, сравнимый с хирургической операцией на работающем сердце. Компания ОТР поделилась уникальным опытом миграции одной из таких систем с Oracle на отечественную Postgres Pro. Ирина Токарева и Сергей Кузнецов из ОТР рассказали о тернистом пути, противостоянии росту энтропии больших объёмов поступающих и изменяемых данных, достигнутых результатах.

Мечта собственника — сильная команда и высокая производительность. Но риски для компании мало кто осознает. Рассказываем, как предпринимателю понять мотивы сотрудников, есть ли угроза мошеннических схем, подделок документов, утечек информации и финансов.

Привет, Хабр! Мы продолжаем цикл статей о нововведениях СУБД Tantor Postgres 17.5.0, и сегодня поговорим о поддержке авторизации через OAuth 2.0 Device Authorization Flow — это современный и безопасный способ предоставления доступа, который позволяет приложениям запрашивать доступ к PostgreSQL от имени пользователя через внешнего провайдера идентификации и управления доступом, например Keycloak, что особенно удобно для облачных сред и микросервисных архитектур (функция будет также доступна в PostgreSQL 18). В статье пошагово разберём настройку OAuth-авторизации в PostgreSQL с использованием Keycloak: настроим Keycloak, подготовим PostgreSQL, напишем валидатор токенов OAuth в PostgreSQL и проверим успешную авторизацию через psql с использованием Device Flow.

Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных.

Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например:

timestamp without time zone может ломать логику расчёта интервалов;

money — это не то, чем кажется (и почему он опасен);

char(n) и varchar(n) не дают ожидаемой экономии и даже вредны;

serial — это прошлый век, а identity — настоящее.

Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.

Побывав на PGConf.DE’2025 и обсуждая там практику применения Postgres на больших базах данных, я к своему удивлению регулярно слышал мнение, что проблемой является время планирования запроса. Как разработчику, мне было странно узнать, что этот фактор может, например, тормозить принятие решения о переходе на партиционирование, что казалось бы естественный шаг, когда количество записей в таблице переваливает за сотню миллионов. Что ж, давайте разбираться.

Меня зовут Екатерина Петрова, я автор медиа «вАЙТИ» и аналитик. Перечитывая свой любимый роман И. Ильфа и Е. Петрова «Двенадцать стульев», а именно сцену с архивариусом Коробейниковым, я вдруг поняла: его бумажный архив ордеров на имущество бывших дворян не что иное, как идеальный пример реляционной базы данных. Алфавитные указатели — это индексы, книги учета — таблицы с первичными ключами, ордера — настоящие транзакции.

YDB — это разработанная в Яндексе распределённая СУБД с открытым исходным кодом, предназначенная для построения высоконагруженных систем. Разработка СУБД, особенно таких масштабных, как YDB, считается одной из самых сложных и ресурсоёмких задач в IT-индустрии. Для её решения от программиста требуется большой опыт и разносторонние знания в области алгоритмов, операционных систем и компьютерного железа. Тем не менее у студентов есть возможность внести свой вклад в развитие различных подсистем YDB. 

Меня зовут Виталий Исаев, я занимаюсь разработкой федеративных возможностей YDB — в этой области вклад студентов в развитие YDB чувствуется особенно сильно. В статье я расскажу о том, как в Яндекс Образовании удалось выстроить процесс совместной работы со студентами: они получают ценный, реальный опыт работы над сложным продуктом, а опенсорс-сообщество YDB — новые фичи. А ещё опишу задачи, которые им приходится решать, и, конечно, поделюсь наиболее яркими их результатами. 

Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.

С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.

Нет, речь не про кэш в памяти. Так было бы слишком просто. У нас сегодня будет препарирован ORM, который честно запрашивает данные у реляционной СУБД, маппит в объекты, подключает связи и отдаёт в логику приложения в виде объектов. И всё на порядки быстрее, чем прямой запрос из кода приложения.

Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.

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

Часто начинающие разработчики сталкиваются с проблемой непонимания принципов работы устоявшихся решений или технологий. А старшие товарищи простыми словами не могут объяснить, как им кажется «простых истин». Это произошло и с OLTP, так что я решил простыми словами объяснить принципы работы важнейшей для современной экономики технологии.

Я провел небольшое исследование и выявил основные проблемы основные проблемы с которыми сталкиваются Джуны (новички) в 1С.

Основные проблемы джунов (новичков) в 1С.

Технические сложности

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

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

Также распространены ошибки формата потока, недостаточности памяти и проблемы с доступом к системе.

Концептуальные трудности

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

Джуны (Новички) часто делают запросы в циклах и обращения через точку, что является грубой ошибкой с точки зрения производительности.

Рассмотрим на примере:

Конструкция типа “Пока Выборка.Следующий() Цикл А = Выборка.Ссылка.Договор;” создает неявные запросы в каждой итерации цикла.

Бизнес-процессы и контекст

Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.

Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.

Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.

Выкатили новый проект. База — на PostgreSQL. Все работает. DBA в штате нет, база крутится на виртуалке, обновления никто не трогал, мониторинга нет. И вот ночь, все падает. Начинается экстренный чат, поиск багов, попытки восстановиться из бэкапа… если он вообще был.

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

На связи продуктовая команда РТК-ЦОД, и в этой статье мы расскажем, как устроены облачные базы и зачем они бизнесу.

pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.

Всем привет! На связи снова Илья Криволапов — системный аналитик в SENSE, где мы трудимся на проекте одного из цветных банков РФ. Работаю в профессии уже пятый год и, несмотря на мою фамилию, с продом у нас в целом тёплые отношения. 

Помимо боевых задач, я преподаю курс «Хранение и обработка больших объемов данных» и за это время накопил немало практических кейсов и наблюдений. Всё это добро я решил не держать при себе и собрал самое полезное в виде ультимативного гайда по оптимизации и грамотному проектированию баз данных с расчетом на масштабирование, который сейчас публикую на Хабре.

Цикл состоит из 3 частей. В первой мы обсудили два базовых подхода к масштабированию БД: вертикальный и горизонтальный. Поговорили о плюсах, минусах и о том, как делать точно не стоит. 

Во второй части – то есть сейчас – мы нырнём глубже в мир горизонтального масштабирования и разберем три первых способа шардирования: по диапазону, по хэшу и по географическим зонам. Я расскажу, как каждый из них работает, где пригодится и в каких случаях может дать сбой.

Материал по-прежнему будет полезен всем, кто заботится о «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Готовы продолжать? Тогда поехали!