Хранение данных *

Представим типичную инфраструктурную задачу. В компании для хранения артефактов сборки, бэкапов сервисов или пользовательских файлов применяется S3‑хранилище. Развернуто оно в основном контуре — например, в продакшен-кластере.

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

Привет, Хабр! На связи Сергей, проектировщик интерфейсов в Selectel. В этой статье разберем, как настроить клиентскую синхронизацию между двумя хранилищами с помощью MinIO Client. Рассмотрим все шаги для подготовки окружения, установки клиента и настройки автоматического запуска, — чтобы объекты регулярно копировались из одного бакета в другой.

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

v1.1.0: убрали HTTP-костыль для sink’ов, закрыли /metrics, Teams в UI, trusted clusters. Про v1.0.3 и типичный «pairing failed» на Docker — внутри. Продолжение серии.

Статья "LLM free" - все изображения и текст органического происхождения. :)

В январе выкладывал пост, в котором рассказывал о ходе эксперимента с 2 флешками - насколько долго они могут сохранить данные в обычных домашних условиях. На сегодня прошло уже 2 года с момента, когда флешки были заполнены данными и отложены в темное сухое место.

Этот эксперимент не претендует на какую-либо научность и практическую значимость. Всё делается просто ради прикола. Just for fun.

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

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

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье разберем, почему каталог — это не первый шаг к порядку, а скорее мультипликатор уже существующей зрелости и что необходимо сделать, чтобы его внедрение принесло реальную пользу.

Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

Серия: redb ecosystem / redb.Route deep-dive

Очередная статья из цикла про redb.Route — наш Apache Camel под .NET. Если вы только подключились, вот предыдущие на Хабре:

redb.Route — Apache Camel для .NET, который мы написали потому что выхода другого не было — с чего всё началось;

redb.Route изнутри: четыре in‑memory канала и Exchange, который их связывает;

redb.Route 3.0.1 — плоская навигация по DSL, рефакторинг CRTP и тихий null;

Apache Camel под .NET, разбор по косточкам: HTTP‑коннектор без ASP.NET MVC + паттерн Content‑Based Router — предыдущая «EIP + коннектор».

Сегодня заходим с Kafka‑коннектора — разбираем его по косточкам, как делали с HTTP, — а потом сажаем на него два EIP‑паттерна: Scatter‑Gather и Aggregator. И главное — разбираем то, о чём в туториалах молчат: как это живёт под транзакциями. Заодно вышел 3.2.0.

Через несколько лет после сдачи проекта новая команда открывает модель. Формально всё на месте: проектная документация сохранена, каталоги и базы данных переданы, архив доступен. Но как только нужно продолжить работу — внести изменение, проверить выпуск или подключить нового подрядчика, — появляется главный вопрос: можно ли понять, почему данные устроены именно так?

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

Меня зовут Алексей Баранов, я — руководитель направления Data Storage Systems в MWS Cloud Platform, и в этой статье я расскажу, как строим блочное хранилище в нашем облаке, с какими вызовами встречаемся и как их решаем.

Пару дней назад я собрал сводку новостей по lakehouse и закончил её обещанием: разберу каждый громкий анонс по отдельности. Выполняю - и начинаю с самого шумного.

На своём июньском саммите Databricks вышел на сцену с заявлением масштаба смены эпохи: отдельные быстрые базы под витрины больше не нужны, перекачка данных между системами умерла, а всё хозяйство теперь живёт в едином озере, готовом под ИИ-агентов. Звучит так, что хочется встать и поверить.

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

Иногда legacy живёт в компании годами не потому, что он плох, а потому что «работает — не трогай». Но однажды появляется триггер, который заставляет переосмыслить подход. В нашем случае таким триггером стала миграция на Kafka 4.0.

Привет! Меня зовут Роман, я инженер данных в компании CDEK и занимаюсь разработкой платформы данных и внедрением self‑service инструментов. В этой статье расскажу, как мы обеспечиваем Event Sourcing подход в платформе больших данных, с какой болью столкнулись при переходе на Kafka 4.0 и как решились отказаться от JSON‑формата.

Что происходит под капотом корпоративного мессенджера, когда нагрузка пробивает отметку в 650 000 запросов в секунду? Обычно в этот момент архитектура распределённых хранилищ начинает проверять на прочность не только диски и сеть, но и нервы команды эксплуатации.

В бэкенде чатов Телемоста за доставку и историю сообщений отвечает отказоустойчивая YDB. Но сообщения — это лишь верхушка айсберга. Помимо них системе нужно ежесекундно проверять составы чатов, актуализировать их названия, сверять права доступа и обслуживать десятки внешних интеграций. И вся эта огромная, динамически меняющаяся масса метаданных живёт в PostgreSQL.

Первый публичный релиз DataSafeS3 (v1.0.0) вышел 24 июня 2026. За несколько дней после него — v1.0.1 и v1.0.2. Оба патча про исправления: для тех, кто уже крутит своё S3-хранилище не только на ноутбуке, но и в тестовом или боевом контуре.

DataSafeS3 — молодой open-source проект небольшой команды: своё хранилище файлов с S3 API, веб-консолью, пользователями, ролями и журналом действий — всё на вашем железе. Мы не MinIO и не конкуренты им — стремимся к доступному open source, который может поднять любой, кто умеет Docker и Linux. Зато честно пишем, что сломалось, что закрыли и что пока не успели.

Ниже — не CHANGELOG. Для каждого изменения: что болело, как это выглядело у вас, что мы поменяли.

Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.

В статье - краткий разбор некоторых принципов моделирования данных простыми словами.

- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth

За то время, пока вы читаете этот абзац, будут отсканированы несколько сотен тысяч штрихкодов. Упаковка молока в Мехико, посадочный талон в Сочи, образец крови в больнице Берлине - все это регистрируется с помощью одной и той же системы. Черно-белый символ сканируется миллиарды раз каждый день, что делает его с большим отрывом самым читаемым элементом дизайна на планете. Его печать ничего не стоит, он не защищен патентом и никому не принадлежит. Тем не менее, он лежит в основе практически всей современной розничной торговли, логистики и мировой торговли. Уберите его завтра, и мировая торговля рухнет за считанные минуты. Это история штрихкода: кто его изобрел, почему он поначалу был бесполезен и как в конечном итоге стал связующим звеном мировой экономики.

В прошлой статье я рассказывал про свой пет-проект qrrot. Тогда это была in memory база данных на Go с TCP-интерфейсом и встроенным ИИ-ассистентом. Идея казалась забавной, но на практике оказалась бесполезной вещью, поэтому я просто продолжил ее ковырять и пробовать сделать из нее что то интересное и быстрое. В процессе ковыряния в своем проекте я полностью перевернул его суть и идею, и вышло это.

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

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

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

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

Если не сразу – эта статья для вас.

Автор без воды, со скриншотами и примерами заполнения описывает полностью путь по заполнению уведомления в Роскомнадзор о начале обработки персональных данных.

В текущий момент каждый IT-бизнес должен подавать такие уведомления после начала деятельности:

а) У Вас есть хотя бы один сотрудник или контрагент - физическое лицо?

б) У Вас есть сайт, мобильное приложение или любой программный продукт, в котором лицо указывает свое ФИО или номер телефона? адрес электронной почты при регистрации?

Вы уже оператор обработки персональных данных.

За отсутствие уведомления административная ответственность - ч. 10 ст. 13.11 КоАП РФ, штраф для физических лиц от 50 000 до 100 000, для организаций 100 000 до 300 000 руб.

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

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

На тот момент аналитика уже работала через ETL: раз в сутки Airflow восстанавливал общую PostgreSQL из ежедневных бекапов, а Redash выполнял запросы уже к ней. Решение было надежным и не требовало нагрузки на production, но для real-time оно не годилось — в лучшем случае отчеты показывали состояние системы на начало дня.

Всем доброго времени суток! Мы — Руслан Алиев, главный эксперт, и Михаил Калганов, начальник отдела вычислительных комплексов Лаборатории R&D «РТК-ЦОД». Наш отдел проводит испытания различного вычислительного оборудования и программных решений.

Основная задача испытаний — определение степени соответствия СХД требованиям проектов, в которых предполагается ее использовать.