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

Посмотрите на эту беседу с Claude. Заметили что-нибудь подозрительное?

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

$ bun dev

Exfiltrating data...

Name: Ayush Paul

Company: Beem

Hometown: Charlotte, NC

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

Учтя всё это, я решил присмотреться к Claude, и в частности к основному повседневному помощнику (claude.ai, не Claude Code). Claude имеет функциональную, но наивную систему памяти из двух частей. Первая — это генерация сводки за день: недавние беседы кратко излагаются в нескольких параграфах о пользователе и вставляются в каждую беседу, чтобы Claude не приходилось каждый раз начинать с нуля. Вторая — это инструмент извлечения conversation_search, позволяющий по запросу выполняют поиск по всей истории бесед.

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

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

Меня зовут Алексей Свиридов, в InfoWatch я уже 12 лет, начинал как инженер, теперь отвечаю за проекты внедрения на территории СЗФО. В этой статье расскажу о том, как Immich помогает мне в работе с корпоративным фото/видеоархивом. 

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

При чём тут вообще фотоархив? 

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

Так вот, про фото. После любого такого события появляется пара сотен фотографий. А иногда и тысяч, если фотограф попался выносливый, а мероприятие было масштабным. Немного спойлерну — сейчас в архиве компании насчитывается более 50 000 фотографий и 1000+ видеороликов.

Само собой, когда мероприятие проходит, фотограф присылает внутрикомам все фотографии, которые они затем и размещают на внутренних ресурсах. А потом присылают ссылку в рабочий чат — мол, спасибо всем, кто пришёл, вот тут ваши фото.

И всё бы ничего, если бы не один нюанс. Фотографии лежат на сетевой шаре в виде файлов, для их просмотра есть простенькая галерея. Что хочется сотруднику после получения ссылки? Правильно, быстренько забрать все свои фоточки и сохранить куда-то в домашний архив, либо поделиться ими в соцсетях. И вот с «быстренько» возникают проблемы

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

Привет, Хаброжители! «Книга с кабанчиком» — вы наверняка слышали о ней? Бестселлер Мартина Клеппмана, изданный почти 10 лет назад, знают и любят все, кому приходится строить высоконагруженные системы, обрабатывающие огромное количество запросов.

Хотим сообщить всем заинтересованным: мы открыли предзаказ на книгу «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд.». Новое издание значительно переработано под современные реалии. Наибольшие технические изменения связаны с развитием ИИ и облачных архитектур. Хотите узнать, что в нем изменилось? Расскажем коротко.

Недавно мне понадобилась старая заметка. Я точно помнил, что записывал её: там былы креды от сервиса (да, знаю надо хранить все в пароехарилках, но я записал как записал).

Не помнил я только, где именно это записал(

В Notepad++? В Obsidian? В сообщении самому себе? В папке проекта? Минут двадцать я перебирал места, и к концу уже не столько искал заметку, сколько пытался воскресить в памяти тот день что бы понять ход собственных мыслей

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

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

Всем привет. Меня зовут Василий Гуров, я занимаюсь задачами оптимизации в ML Research Lab MAGNIT TECH. В этом материале разберу два промышленных кейса из крупного ритейла – планирование смен сотрудников магазинов и сглаживание нагрузки на распределительные центры.

На поверхности это разные задачи. В первой нужно построить график работы сотрудников по ролям и временным интервалам. Во втором кейсе стоит задача перераспределения логистических потоков так, чтобы снизить пики нагрузки на распределительные центры (РЦ). Но инженерная проблема у них оказалась общей. Прямая time-indexed постановка быстро раздувала модель до сотен тысяч и миллионов бинарных переменных, давала нестабильные рекомендации и плохо укладывалась в SLA.

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

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

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

Не будем объяснять базу, но все знают, что магнитные головки HDD, прицепленные с одного конца "коромысла", приводятся в движение магнитной катушкой "Voice Coil" зажатой между двух неодимомых магнитов с другой стороны (а в современных дисках есть ещё и точный "доворот" пьезоэлементами на конце, недалеко от самих головок). Когда HDD надо переместить БМГ (Блок Магнитных Головок) на другую далёкую дорожку, он подаёт на Voice Coil резкий импульс тока, чтобы сорвать массивную металлическую конструкцию с места в нужном направлении, а потом ещё один обратный импульс тока для резкого торможения. Если посмотрите на фото БМГ, то поймёте как велика Voice Coil во всей этой конструкции и что ускорения и торможения происходят с довольно большими перегрузками. Это как если бы автомобиль весом 1.5 тонны разгонялся до 100 км/ч за 0.05...0.1 сек, а тормозил со скорости 100 км/ч на дистанции 1 метр и человек массов 80 кг потяжелел бы до 4 тонн. Если головки нужно перемещать в диапазоне до 50 дорожек, то Voice Coil не работает, достаточно пошевелить кончиком с головками с помощью пьезо-актуатора, который умеет гнуть металлический конец "коромысла" на 1...5 микрометров. И прыгать за 8 миллисекунд нужно не между тысячами дорожек, а по всей поверхности блина от края до края.

Год назад я уже делал обзор на девайс TerraMaster F8 Pro, если интересно то эта статья есть в моем профиле. Это довольно необычный NAS, полностью построенный вокруг NVMe-накопителей. Устройство получилось действительно быстрым, но после публикации обзора многие читатели задали вполне закономерный вопрос:

«СХД для ИИ» - маркетинг. На деле у склада три потребителя с конфликтующими требованиями: обучение (полоса и p99 потока), инференс/RAG (хвосты латентности) и чекпоинты (burst-запись). На примере реальной HA-пары NVMe-oF/TCP и арифметики тракта данных ответим на главный вопрос.

Почему RDMA и Gen5 часто не дают эффекта?

Где микросекунды протокола реально съедают SLA?

В каком порядке апгрейдить: сначала ворота фронта, потом плазму, и только потом реликвии бэкенда?

Что такое электронная таблица, объяснять не надо. Все знают Excel, и многие хоть раз им пользовались. История создания электронных таблиц тоже, на первый взгляд, незамысловатая и сравнительно недолгая: как только появились первые ПК, сразу началась разработка ПО для выведения на экран их монитора интерактивной таблицы, которая сильно облегчила бы работу бухгалтеров и менеджеров. IT-инженеры уложились в 15 лет, с конца 60-х до середины 80-х, чтобы создать электронную таблицу от начала и до конца – от разработки самого принципа ее программирования до появления первых электронных таблиц (от VisiCalc до Excel) на экране ПК, сильно порадовав тем самым белых воротничков (и не только их). Дальше шло лишь усовершенствование электронных таблиц.

С чего вдруг IT-инженеры и изобретатели озаботились бухгалтерскими проблемами, тоже понятно. Люди старшего поколения помнят, что можно было делать на первых ПК 70-х и 80-х годов, еще до эпохи интернета. Если оставить в стороне возможность самостоятельно заняться программированием и обмениваться файлами с такими же энтузиастами, что сейчас часто ставят в заслугу первым ПК (для этого все-таки надо было в душе быть айтишником), то на этих ПК можно было играть в интерактивные игры (правда, на игровых приставках к телевизору это обходилось дешевле) и можно было использовать ПК как пишущую машинку, при пользовании которой не надо было замазывать белилами ошибки и ждать, когда те высохнут, чтобы напечатать поверх правильную букву. Сказать, что это сильно порадовало писателей и редакторов бумажных СМИ значит ничего не сказать, это была настоящая революция в писательском и издательском деле, сравнимая разве что с изобретением печатного станка Гутенбергом в XV веке. А когда к этому добавились еще электронные таблицы для сведения дебета с кредетом в интерактивном режиме, это была еще одна революция в бухгалтерии того же масштаба, если не большего.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

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

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

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

Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?

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

Нельзя не отметить, что в последнее время Qsan рьяно взялся за углубление различного функционала своих продуктов в отношении темы резервного копирования. В целом здесь нет ничего удивительного, т.к. сохранность данных для производителя СХД – приоритетная цель. И хотя резервное копирование все же больше относится к классу прикладных задач и зачастую производится с помощью специального ПО, наличие дополнительных способов, предоставляемых в том числе производителем СХД, лишними точно не будут, так как еще одна резервная копия никогда не будет лишней. Так что предметом данной статьи будет обзор ПО резервного копирования от Qsan – XVault.

Представим типичную инфраструктурную задачу. В компании для хранения артефактов сборки, бэкапов сервисов или пользовательских файлов применяется 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.