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

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

Я Владислав Доронин — Go-разработчик в команде S3 облачной платформы Cloud.ru Evolition. Хочу рассказать про подход к управлению отказами реплик, который мы кристаллизовали опытом выхода из строя разных частей системы. Практика показала, что массовые и не очень отказы приводят к взлету задержки ответов и увеличению количества client-side повторов, которые тоже висят. Пускай на уровне записи из-за требований репликации и гарантии мы много поделать с ситуацией не можем (хотя и там не все безнадежно), то вот чтение гораздо более гибкое. У нас получилось сделать retry на чтении красивыми, об этом сегодня и поговорим.

Всем привет. Я — Дмитрий Шапошников, Tech Lead в команде Object Storage в MWS Cloud Platform. Сегодня мы поговорим о том, как устроено наше объектное хранилище.

В этой статье я объясню, что такое Object Storage, и поделюсь нашим опытом создания сервиса. Расскажу о преимуществах и недостатках работы с Ceph, на котором базировалась предыдущая версия нашего объектника, и подробно опишу архитектуру нового сервиса Object Storage, его масштабируемость и надёжность.

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

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

Вы настроили retention.ms = 86400000 (24 часа) и отправили тестовое сообщение. Через сколько времени реально удалится сообщение?

ПД — персональные данные.

Одни бизнесы пользуются услугами других бизнесов или частных исполнителей. Это база. 

Пример: обучающий центр хранит данные работников и учащихся в CRM.

Другой пример: флористическая студия пользуется услугами курьерской компании (или самозанятого курьера) для доставки букетов.

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

Решил я тут, что будет удобно иметь S3 бакет как диск в системе для всякого. Так как я плотно работаю с Yandex Cloud, то и использовать буду их бакет.

У них довольно щедрые тарифы и достаточно большие бесплатные лимиты.

Я сижу на Федоре. Для подключения бакета буду использовать GeeseFS - - высокопроизводительная файловая система S3 ( Яндекс , Amazon ), соответствующая стандарту POSIX и написанная на языке Go.

GeeseFS позволяет монтировать S3 бакет как файловую систему. Файловые системы FUSE на основе S3 обычно имеют проблемы с производительностью, особенно при работе с небольшими файлами и операциями с метаданными. GeeseFS пытается решить эти проблемы, используя агрессивный параллелизм и асинхронность.

Будет работать кстати и на винде.

Естественно нужно иметь аккаунт в яндекс облаке. У меня он есть. Создать новый не представляет сложности. Там ещё и грант 4000 рублей дадут. Поэтому переходим к делу.

В облаке нужно будет создать бакет. А так же статические ключи доступа.

Скачиваю бинарник https://github.com/yandex-cloud/geesefs/releases/latest/download/geesefs-linux-amd64. Кстати должна быть установлена ещё fuse, в федоре она предустановлена.

В профиль aws нужно добавить созданный ранее статический ключ доступа. Если вы не пользовались aws cli, то нужно создать файл ~/.aws/credentials, если пользовались то файл уже есть. В него нужно добавить профиль

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

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

Команда Deckhouse Storage рассказала о поддерживаемых в наших платформах CSI с использованием реализаций от вендора (для платформ Huawei, HPE, NetApp и Yadro), а также о собственном универсальном CSI-драйвере csi-scsi-generic, который поддерживает интеграцию с любыми системами хранения данных.

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

Геопространственные данные быстро перестают быть «слоем на карте», когда их нужно свести с другими источниками, регулярно обновлять, масштабировать запросы вроде «точка в полигоне» и отдавать результат в BI или GIS без ручной сборки артефактов. В статье разбирается практичный способ собрать геопространственный lakehouse на Databricks и открытых инструментах поверх Spark: как приземлять разные форматы в Delta, где чинить системы координат и некорректные геометрии, чем ускорять тяжёлые геоджойны и как организовать слой представления под разные потребители — от Power BI до облачных ГИС.

Привет, Хабр! Это Настя из Selectel. В очередном дайджесте расскажу, как мы улучшили продукты в ноябре. Новинок достаточно: добавили ледяной класс хранения S3, новые расширения в PostgreSQL и прерываемые ВМ во все регионы. Велкам под кат!

«Обучил, запустил и забыл» — плохая стратегия работы с ML‑моделями, но она часто встречается после удачного тестирования. Качество моделей может незаметно снижаться, и если пропустить этот момент — последствия могут дорого стоить. Когда мы начали задумываться о системе мониторинга, одна из наших моделей начала выдавать предсказания, которые требовали незамедлительного вмешательства в выстроенную работу. Но разум подсказывал, что проблема не в процессе, а в модели. О том, каким трудоемким оказалось наше расследование, и как мы восстанавливали и изучали каждую составляющую процесса почти вслепую, читайте по ссылке.

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

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

Всем привет! Меня зовут Михаил Синельников, я лидер кластера импортозамещения аналитической отчетности в ВТБ. Вместе с моим коллегой Владимиром Ведяковым, ИТ-лидером проекта со стороны компании «Сапиенс Солюшнс», мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами.

Я занимаюсь технической поддержкой и сопровождением в компании «Онланта». Сегодня в блоге ЛАНИТ я расскажу о решении реального кейса по замене ОЗУ (оперативной памяти) в СХД Huawei.    

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

Однако на практике при детальной диагностике зачастую можно выявить конкретный неисправный компонент — например, модуль оперативной памяти (ОЗУ) — и заменить только его. Это позволяет значительно сократить затраты по сравнению с заменой всего контроллера, стоимость которого может быть в разы выше стоимости отдельных комплектующих.

Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.

В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.

Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.

Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.

Привет!

Перед вами новое исследование, посвящённое одной из ключевых технологий управления данными — процессам извлечения, преобразования и загрузки данных (ETL). Оно стало логическим продолжением первого обзора рынка ETL-решений, выпущенного нашей командой три года назад.

За это время многое изменилось. Если в 2022-м рынок опирался на зарубежные платформы, то сегодня акценты сместились в сторону отечественных продуктов. Причины очевидны: уход иностранных вендоров, трудности с продлением лицензий, обновлениями и поддержкой. Импортозамещение из формальности превратилось в стратегическую задачу, а потребность в надёжных российских инструментах — в вопрос технологической безопасности.

Одновременно усилились и глобальные вызовы: рост объёмов данных, переход бизнеса к моделям прогнозной аналитики и управлению на основе данных. ETL-системы в этой экосистеме занимают фундаментальное место — именно они превращают разрозненные источники в согласованный поток информации, на котором строятся аналитика, модели машинного обучения и управленческие решения.

Компании ежедневно генерируют большие объемы данных, но далеко не вся информация одинаково важна: со временем многие данные становятся менее востребованными, продолжая занимать дорогие и высокопроизводительные накопители (SSD, RAM). В результате хранение таких «холодных» данных обходится неоправданно дорого, поскольку потребность в постоянном доступе к ним минимальна.

Решение проблемы — технология охлаждения данных, которая предполагает перемещение редко используемой информации на более дешевые и емкие носители, то есть файлы остаются доступными, но перестают нагружать дорогие и быстрые устройства. Именно такой механизм охлаждения данных мы добавили в Tarantool DB 3.0.

Привет, Хабр. Меня зовут Сергей Фомин. Я старший менеджер продукта Tarantool DataBase. В этой статье я расскажу, как именно мы реализовали механизм охлаждения и какие бизнес-выгоды могут получить компании при его использовании.

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

Строительство этих дата-центров обеспечили 92% роста ВВП США в I кв. 2025 года, то есть без ИИ экономика сразу скатится в рецессию. Стройки ЦОДов, как строительство автобанов или небоскрёбов во времена великой депрессии, дают рабочие места и поддерживают экономику. С другой стороны, они потенциально ущемляют остальные сектора экономики, перетягивая рабочие места и инвестиции (это уже другая тема, которую мы здесь обсуждать не будем).

Где же взять столько энергии, ведь текущих ТЭС никак не хватит на 280 гигантских ЦОДов, которые построят в ближайшие три года только в США. Один из выходов — установка модульных ядерных реакторов непосредственно возле ЦОДов, в этом направлении сейчас идут перспективные инженерные разработки.

Но есть и другие варианты.

Всегда, когда речь идет и разработке отчётов, дашбордов,витрин данных, в принципе любой системы, сначала нужно сформулировать требования совместно с бизнес-подразделениями. Я Кристина Проскурина, руковожу управлением бизнес-анализа данных в РСХБ.Цифра. В этой статье расскажу, как выглядят основные этапы процесса сбора и формирования требований.

В этом тексте я написал про некоторые особенности работ c SD картами при соединении их с микроконтроллером по интерфейсу SPI.