Базы данных *

Я блокчейн разработчик, и в проекте у нас базы на сотни гигабайт с децентрализованных бирж. Чтобы строить аналитические отчеты и делать агрегации, такие как вычисления цен, биржевых свечей, объемов торгов, цен на токены, мы используем БД Clickhouse. До этого я работал только с Postgres (и давно с MSSQL), и хочу рассказать, как я вкатывался, что удивило – практический опыт и WTFы. Прочитав эту статью вам, возможно, захочется сделать аналитику по своим данным в Clickhouse – возможно, ищете, что полезного освоить на длинных выходных. Итак, поехали!

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

Вокруг ФНС в последнее время крутится слишком много мифов. Последний из них — история про новогодний стол, икру и якобы контроль налоговой через фотографии в соцсетях.

Этот инфоповод и стал причиной написать статью. Не для того, чтобы обсуждать конкретную «страшилку», а чтобы показать как на самом деле устроен налоговый контроль: что ФНС реально проверяет, на какие данные опирается и почему большинство популярных представлений не имеет отношения к практике.

Я опираюсь не на слухи и пересказы, а на реальный опыт работы с налоговыми проверками и понимание внутренних механизмов ФНС. За плечами — 12 лет работы в налоговой системе в разных направлениях: предпроверочный анализ, камеральные проверки, выездные проверки и курирование отраслевых направлений внутри региона.

Все любят безопасность, пока не приходится её настраивать. Первая версия нашего аудита напоминала пульт управления АЭС: бесконечно гибко, но без инструкции не взлетишь. Мы признали поражение, послушали стоны администраторов и сделали «версию 2.0» — с классами событий и логикой, понятной человеку, а не только компилятору. История работы над ошибками, которая превратила «полочный» софт в рабочий инструмент.

Начинаем серию самых интересных статей по докладам с ежегодной технической конференции Firebird Conf. Алексей Мараховец, продакт-оунер и сооснователь 10-Strike Software, рассказал об опыте применения Firebird в продукте для мониторинга сети. В своем докладе Алексей рассмотрел причины выбора данной СУБД, проанализировал преимущества и недостатки её применения, а также поделился техническими аспектами интеграции и эксплуатации.

...

Всем привет! Меня зовут Алексей Мараховец, сегодня я расскажу о применении Firebird в продукте для мониторинга сети, который мы выпускаем с 2015 года.

Наша компания называется 10-Strike Software, и мы специализируемся на решениях для системного администрирования. В 2003 году запустили наши первые продукты для мониторинга локальных сетей организаций. Одним из флагманских продуктов является Мониторинг Сети Pro – это система для мониторинга серверов и оборудования, которая позволяет своевременно узнавать о произошедшем сбое (разрывах связи, остановках служб и т. п.) и устранять проблему с минимальными потерями времени.

Привет, Хабр! Меня зовут Кирилл Курдюков, и мы с командой делаем YDB (СУБД Яндекса). Как и с языками программирования, популярность СУБД определяется не только их возможностями, но и экосистемой.

В предыдущей статье я рассказал о том, как разработать Java-клиент для распределённой СУБД и интегрировать его с популярными ORM. А из этой статьи вы узнаете, как под капотом работает ADO.NET, почему управление пулом сессий может сильно влиять на ваш код работы с базой данных и какой стратегии обработки ошибок можно придерживаться для разработки отказоустойчивых сервисов. Статья будет полезна тем, кто изучает особенности взаимодействия в распределённых системах или просто хочет научиться лучше писать клиентский код, работающий с современными распределёнными системами.

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

В этой статье мы постарались собрать добрую дюжину самых неочевидных и при этом действительно продакшн-критичных ошибок работы с Hibernate: как они проявляются в логах и метриках, почему возникают на уровне механики ORM, и какие предохранители помогут поймать их до релиза. Будет практично, предметно и с несколькими моментами, после которых захочется пересмотреть пару любимых паттернов в вашем проекте.

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

Эта статья предназначена для более быстрого запоминания/повторения паттернов микросервисов. Кое‑где я приводил кейсы, которые могут быть непонятны новичкам. Здесь нет подробных кейсов применения каждого паттерна так как иначе статья получилась бы на другую тему. Для удобства я приложил ссылки — чтобы избежать дублей.

В начале декабря я публиковал статью про Postgresus 2.0 — инструмент для резервного копирования PostgreSQL. С момента этой статьи пришло много запросов на добавление других баз данных, много положительной обратной связи от пользователей и набралось больше 1000 звёзд на GitHub.

А потом я узнал, что нарушил торговый знак 🥲. Оказывается, нельзя брать первое понравившееся название — и использовать его. Точнее можно, но с оговорками.

В итоге было принято решение о маленьком ребрендинге. Теперь Postgresus — это Databasus. И поддерживает другие базы: MySQL, MariaDB и MongoDB (при этом оставляя основной фокус на PostgreSQL).

Ниже — детальнее, что из себя представляет проект и почему произошло переименование.

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

На связи Дмитрий Ларин, руководитель продуктового направления по защите баз данных, компании «Гарда».

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

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

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

Привет, Хабр!  Меня зовут Юлианна Валиуллина и я главный эксперт по развитию BI в банке Уралсиб.

Для начала немного о нас: мы практикуем self-service подход, в банке более 200 разработчиков, из них 150 имеют опубликованные дашборды, остальные делают аналитику для себя. Более 1200 опубликованных дашбордов, MAU около 1500. Большая часть дашбордов в нашем банке работает в spider(extract) режиме, доля direct 15-20%.

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

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

В статье — пошаговый разбор создания и обновления материализованных представлений (MV) в StarRocks: от парсинга SQL (ANTLR) и инициализации свойств до сериализации метаданных (edit log, checkpoint, image) и планирования refresh. Разбираем синхронизацию партиций (range‑партиционирование), параметр partition_refresh_number и оптимизацию обновлений. Отдельный блок — поддержка нескольких выражений в UNION ALL и механизм VirtualPartitions из PR #60035, позволяющий корректно обновлять сдвинутые временными функциями (date_add/date_sub) диапазоны без пропусков. Материал будет полезен инженерам данных и тем, кто проектирует OLAP‑модели и MV под высокую нагрузку.

Привет Хабр! Меня зовут Михаил. Я backend-разработчик в команде Биллинга в Тензоре.

Эта статья — обзор вариантов индексации JSON и JSONB-полей и оптимального поиска текста в них, который мы проделали вместе с командой. Так как используем PostgresSQL, все варианты валидны для него.

Материализованные представления (MV) в StarRocks — это не просто кэш агрегатов, а полноценный механизм ускорения запросов с автоматическим переписыванием (query rewrite). На практических примерах разбираем, как движок сопоставляет поддеревья плана запроса со SPJG‑MV, как работают join/aggregate/nested/union rewrite, как обеспечивается строгая согласованность и настраиваемая устарелость данных (staleness), и за счёт чего достигается ускорение на SSB и TPC‑H.

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

Ответ: фундаментально изменилась парадигма хранения и обработки данных.

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

Ключевым отличием стал формат OTF — Open Table Format, через который удалось реализовать единый стандарт доступа к данным и 4 технологически-культурных сдвига. Перечислю их: ...

Привет, Хабр!
Команда CTSG запустила новый сезон подкаста Crosscheck. В одном из первых выпусков эксперты обсуждают актуальную, «горящую» на сегодняшний день, тему обезличивания баз данных: изменения в законодательстве, методы обезличивания, маскирование и многое другое.

Недавно у меня возникла задача по разбиению мульти-терабайтной таблицы на равные диапазоны по числовому полю id. Причём данные распределены по id крайне неравномерно, где-то есть большие "лакуны", где-то непоследовательная генерация и т.д., и т.п. Конечно, можно применить честное решение в лоб — использовать функцию NTILE, но я довольно быстро осознал, что это приведёт к многочасовому запросу с большой вероятностью упасть из-за недостатка TEMP. Но, к счастью, зачастую в таких задачах, как и в моём случае, идеальное разделение на диапазоны не требуется, достаточно более-менее приличного.

Я решил провернуть небольшой трюк для получения приблизительного разделения. Давайте посмотрим, что у меня получилось на модельном примере.

В архитектуре потоковой обработки данных Kafka, как высокопроизводительная очередь сообщений, обычно используется для агрегации данных, а StarRocks, как высокопроизводительная аналитическая СУБД, отвечает за хранение и анализ. С помощью Routine Load можно стабильно и эффективно загружать в StarRocks данные в форматах JSON и CSV из Kafka.

В начале 2010-х в профессиональном сообществе разработчиков и архитекторов распределенных систем широко обсуждалась идея, что мир баз данных вступает в новую эру. На фоне успехов крупных интернет-сервисов термин BASE начал использоваться как противопоставление классическому ACID. Хайп вокруг NoSQL, CAP-теоремы и масштабируемых систем породил лозунги вроде «SQL умер», «ACID — для банков, а мы делаем веб», «eventual consistency — это нормально».

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

Что же произошло? Была ли «битва ACID и BASE» реальным технологическим разломом или лишь отражала ограничения своего времени? 

В этой статье мы разберём, как возникли ACID и BASE, почему BASE быстро стал популярен и что на самом деле означает тезис «победил ACID» в 2020-е годы.