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

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

Большинство таких проблем можно предсказать и предотвратить ещё на этапе проектирования — об этом статья: как выбрать архитектуру для кластеров MIND uStor, посчитать ресурсы сервера, спроектировать сеть и настроить кластер так, чтобы он держал нагрузку предсказуемо и переживал отказы без драмы. Материал написан для инженеров, которые проектируют или сопровождают такие кластеры.

Недавно я рассказал, как держу долговременную память агента на обычных markdown‑файлах, без вектор‑базы и эмбеддингов. За кадром той статьи осталось главное: показал, к чему пришел, а вот от чего ушел и почему — нет. И еще одно, о чем стоит сказать прямо: у Claude Code есть своя встроенная память почти того же вида. Я про нее знаю — и сознательно держу свою, в проекте. Дальше объясню, почему.

Если совсем коротко, вот к чему сводится разница:

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

Теперь настало время ответить на практический вопрос: как все эти метаданные связать в единую систему, чтобы несколько движков могли работать с одними и теми же таблицами без хаоса. Помимо теории развернем HMS в Docker, настроим PyIceberg и разберем внутреннюю анатомию файла metadata.json.

Привет! Я Денис, старший бэкенд-разработчик в Selectel. Надеюсь, материал будет полезен инженерам данных и архитекторам. Мы рассмотрим Hive Metastore, AWS Glue, REST Catalog и Nessie и расскажем как выбрать подходящий инструмент под специфику проекта.

Локальный запуск больших LLM быстро упирается в память: веса не помещаются, оффлоад режет скорость, а красивые бенчмарки мало говорят о реальной нагрузке. Разбираем эксперимент с Kimi K3 на 2,8 трлн параметров и смотрим, как MoE, квантование, стриминг и иерархия памяти меняют пределы потребительского железа.

У меня восемь агентов с постоянной памятью: больше 360 файлов, около 1,4 МБ текста. Векторной базы нет ни одной, эмбеддинги я не считаю вообще. И это не “руки не дошли”: вопрос про вектор-БД я поднимал трижды, каждый раз с конкретным кандидатом на внедрение, и каждый раз закрывал его отказом.

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

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

Память снова в цене, причем буквально. За последний год цены подскочили так, что SSD от более-менее именитого производителя стал, скорее, предметом роскоши, чем «базовым минимумом». И в то же время на маркетплейсах можно найти сказочное изобилие: флешки известных брендов с огромным объемом продаются практически за бесценок. Кажется, здесь есть какой-то подвох…

Привет, меня зовут Денис Астафиев, я ведущий специалист аппаратных исследований в Бастионе. Конечно, про фейковые флешки писали уже не раз и на Хабре, и за его пределами, но по большей части рассматривая их со стороны потребителя: как вычислить контрафакт, как определить ее реальный объем и всё в этом же духе. Мне же более интересен другой подход: как недобросовестным производителям удалось достигнуть такого результата, и что они могут сделать, кроме изменения одного поля в конфигурации контроллера. И, как вы понимаете, был только один способ это узнать…

Агрегаты в PostgreSQL не очень-то эффективны. Это особенно заметно в сравнении с SQL Server в сценарии, где частичная агрегация не помогает: когда агрегация только подготавливает данные для запроса, обрабатывая большой поток строк и на выходе получая ненамного меньший набор групп и посчитанных по ним агрегатов. Хуже всего приходится типам переменной длины. И здесь характерный пример — SUM(numeric). Встроенные агрегаты обязаны обрабатывать значения в самом общем виде, тогда как на практике данные часто ограничены: например, в БД 1С все numeric имеют фиксированный масштаб.

Отсюда возникает идея оптимизировать агрегаты, подстроив их под конкретные условия эксплуатации. Раньше это было возможно только в форке PostgreSQL. Однако недавно David Rowley добавил в ядро любопытный инструмент расширения SupportRequestSimplifyAggref (коммит 42473b3b31, PostgreSQL 19): теперь можно предоставить планнеру кастомную логику трансформации агрегата через механизм функций поддержки планнера (prosupport). Сам механизм существует ещё с PostgreSQL 12, но до агрегатов добрался только сейчас. В ядре новый запрос применяется скромно: заменяет COUNT(1) и COUNT(col) по NOT NULL-колонке на COUNT(*). А вот расширению он позволяет сделать с агрегатом во время планирования практически что угодно. Это открывает пространство для интересных технических решений.

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

Объектные хранилища, работающие по протоколу S3, уже давно стали де-факто стандартом для работы с неструктурированными данными — от бэкапов корпоративных систем до наполнения озёр данных (Data Lake) для аналитики. Однако переход от простого использования API к построению на базе S3 отказоустойчивой и безопасной инфраструктуры часто оказывается сложнее, чем кажется на первый взгляд, а многие встроенные механизмы остаются невостребованными. И связано не столько с отсутствием бизнес-потребности, сколько с недостаточным пониманием того, как именно эти функции работают. 

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

Привет, Хабр! Понадобилось мне в 2026 году установить XPEnology на ESXi, но актуальных инструкций я не нашёл. Восполняем этот пробел.

Инструкция будет полезна администраторам или DevOps, начинающим своё знакомство с XPEnology.

Внимание: в статье очень много картинок.

Для чего это может потребоваться

Например, можно:

- Ознакомиться с функционалом NAS Synology перед покупкой дорогостоящего оборудования.
- Протестировать установку или настройку новых пакетов.
- Протестировать сценарии перед их реализацией на реальном железе. Например, замену, дисков меньшего объёма на больший. Или обновление DSM 7.2 на 7.3

Когда начинаешь выбирать оперативную память, сразу бросаются в глаза две главные цифры. Производители даже в маркировку обычно выносят тип-частоту и тайминги. Обычно это цифры вроде DDR5-6000 и CL30. Споры о том, что из них важнее для игр, идут уже не меньше 15 лет, и как правило, обе стороны в них не правы примерно одинаково. Частота и тайминги — это не два независимых параметра, они связаны между собой через длительность такта, но часто важнее оказывается другой фактор. Об этом сейчас и поговорим.

В старой резервной копии базы данных 0.mk хранится 657 958 ссылок, созданных с 2009 по 2014 год, а также количество нажатий на них. В августе 2026 года мы восстановили 657 607 из этих записей в виде ссылок до 2015 года и прошли по каждой из них. Из 655 178 безопасных записей ссылок с возможностью перехода 76,7% больше не возвращало загружающуюся страницу.

Большинство из пользователей 0.mk находится в Македонии, поэтому это исследование не отражает картину для всего веба. Это большой архив того, чем в тот период делилось одно онлайн-сообщество, в том числе сборник местных новостей, фотохостингов, форумов и популярных на то время платформ.

Основанный в 2009 году 0.mk был любительским проектом команды из трёх человек. Мы работали над ним в свободное от работы время, обычно по несколько часов в день. Спустя семнадцать лет один из нас нашёл на диске резервную копию базы данных и решил вернуть её к жизни.

Документация PostgreSQL по numeric содержит два плохо согласующихся утверждения:

«especially recommended for storing monetary amounts and other quantities where exactness is required» — и сразу же: «calculations on numeric values are very slow compared to the integer types, or to the floating-point types». То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.

Для меня, как разработчика СУБД это сигнал к действию. Если операции с типом заметно медленнее bigint, возникает соблазн: а нельзя ли хранить денежные величины целым числом копеек и округлять по стандартному правилу? Это бы прилично сэкономило вычислительные ресурсы наших серверов баз данных, разве нет? А что, если вообще использовать double precision?

Почти любой NVMe-диск сегодня выпускается в двух версиях: с радиатором и без. Разница в цене между ними выходит не такая уж и большая, поэтому многие не глядя берут более дорогую. Да и чего бы не взять? Доплата копеечная, зато на выходе получаешь диск, который точно не перегреется. Звучит логично, вот только чаще всего деньги улетают в трубу. Не потому, что есть сценарии, когда SSD не греется. Греется. Просто настоящая причина ставить радиатор лежит совершенно в другой плоскости, о которой почему-то почти не говорят.

Безусловно, главной функцией в работе любой системы хранения данных является сохранность этих самых данных. Следующим пунктом уже идет обеспечение доступа к ним. А применение различных технологий, многие из которых уже давно стали стандартом де‑факто, позволяет объединить эти важнейшие вехи. В данной статье мы поговорим об одной из таких технологий — метро‑кластере, поддержка которого появится в СХД Qsan начиная с FW 4.3.0.

Привет, Хабр! Это снова Денис — тимлид инфраструктурной Core-команды в Timeweb Cloud.

В прошлой статье я разбирал живые миграции: NBD, RDMA, switchover за сотни миллисекунд и прочий внутренний хардкор платформы. Там было вкусно инженерам. Сегодня — про другое удовольствие.

Вот у нас снова есть клиент. У него есть сервер. На сервере — жизнь бизнеса: сайт, база, файлы, пара скриптов «временно, но уже третий год». И где-то в голове тихо живёт мысль:

> «Бэкапы? Конечно. Сделаем. После релиза. И отпуска. И вот этого срочного.»

Знакомо до боли. Я как раз собрал сценарий для тех, кто уже устал откладывать и хочет нормальный бэкап без полугодового проекта внедрения. Открываете один файл настроек, запускаете Terraform — и получаете готовую систему резервного копирования в облаке.

Если ждали 40 экранов про внутренности Bareos — выдохните. Сегодня я буду продавать спокойный сон. Он, между прочим, тоже продукт.

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

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

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

Меня зовут Дмитрий, я руководитель службы поддержки виртуальной инфраструктуры в OXYGEN. В этой статье я рассказываю про личный опыт автоматизации мониторинга облака. Под катом разберу четыре задачи, которые мы последовательно автоматизировали — заглядывайте, если интересно.

Всем привет! На связи команда BI‑практики GlowByte.

У нас прошел внутренний хакатон AI Seasons. Он вдохнул жизнь в корпоративное обучение и дал участникам ощутимую бизнес‑ценность. Хочу поделиться этим опытом и подкинуть вам идею для масштабирования истории у себя. Ниже расскажу подробно, а пока вкратце опишу основную идею, как это реализовали у нас в GlowByte.

Итак, мы взяли вымышленную розничную сеть «МегаБайт» с сотнями магазинов и миллионами заказов. Поставили перед командами задачу реализовать DWH/BI‑кейс, решать задачки нужно было с помощью ИИ. На старте участвовали 28 команд, до финиша добрались три: было по‑спортивному напряжённо, горячо и энергично, так что не все смогли потянуть битву в таком темпе.

Под катом я расскажу:

— как устроен наш хакатон;
— как оценивались задания;
— какие ошибки мы допустили;
— что было ценного и что мы уже забираем в текущие рабочие процессы.

Будет здорово, если вам зайдет тема и организуете подобный «боевик» для специалистов у себя. Потом обязательно поделитесь в комментариях! 

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей.

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

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

У меня был iPhone и ноутбук на Windows, а хранилище Obsidian лежало в iCloud. Работаешь себе, всё нормально, и в какой-то момент заметка, которую ты правил, превращается в 10 копий с номерами в именах. Что-то потыкал, вроде исправилось. Несколько дней тишина, потом то же самое. А когда я наконец заглянул в служебную папку, там лежали сотни копий одного файла workspace.json: он размножался активнее всего, просто на глаза не попадался.

Кончилось тем, что я перешёл на технику Apple целиком. Я и так к этому шёл, но история с копиями решение заметно ускорила.

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