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

Это вторая часть разбора ошибок конфигурации MS SQL Server под 1С. Первая часть — про планирование и развёртывание: профили нагрузки, дисковая подсистема, баланс ресурсов, инсталляция и виртуализация, здесь первая часть. Там же была описана типичная история дефолтного развёртывания сервера на прод или «как не надо».

Побудившая меня написать всё это предыстория такова: сервером СУБД под 1С обычно занимается системный администратор в паре с 1С‑разработчиком или франчом, уровень СУБД теряется где‑то между их компетенциями. Первая часть была про то, как этот разрыв закладывает проблемы при развёртывании. Вторая (эта) — про то, как этот же разрыв в компетенциях мешает найти причину, когда система уже тормозит «и всё висит, и прод лежит».

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

Все звонки начинаются как под копирку

«База висит». «Окна не открываются». «К вечеру всё тормозит так, что документ не провести». Жалобы на сервер 1С звучат одинаково в рознице, в производстве и в бухгалтерии, но причины под одинаковыми симптомами всякий раз оказываются разными. Посмотреть, какие типы ожиданий превалируют на сервере, найти тяжёлые запросы, указать в каких местах и что можно поправить. За каждым этим шагом стоит достаточно узкая компетенция администратора баз данных, отдельная профессия — DBA. Разработчики этим навыком, как правило, не владеют, у них другая специализация, отсюда следствие: код, который прекрасно работает на тесте, в проде начинает работать очень тяжело. На тесте нет ни боевых объёмов, ни конкуренции за строки, ни сотни пользователей, проводящих документы одновременно. В проде есть всё и сразу.

Одной из сильных сторон Kafka Streams является возможность хранить состояние приложения локально. По умолчанию в качестве локального хранилища используется RocksDB — встроенная key-value база данных, расположенная на диске.

Но есть одна особенность, о которой редко задумываются в начале проекта. State Store отлично умеет хранить данные, но совершенно не знает, когда их пора удалить. Если приложение однажды записало объект в Store, он останется там до тех пор, пока приложение самостоятельно его не удалит. Никакого встроенного TTL для обычного State Store в Kafka Streams нет. На небольших объёмах это практически незаметно.

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

Когда компания растет, регламенты и инструкции быстро превращаются в «кладбище файлов», а новички всё равно идут с простыми вопросами к руководителям. Поэтому мы автоматизировали выдачу ответов на бытовые и организационные вопросы новичков, обкатав систему на сотрудниках бэк-офиса перед внедрением в IT-команды. В статье разбираем 5 шагов: от аудита реальных болей сотрудника до подключения умного ИИ-агента, который находит ответы за 30 секунд.

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

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

В кулуарах страховых форумов приходится слышать «технологии ИИ сильно переоценены», «мы поставили модель, но результата нет». Хотите об этом поговорить?

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

Двадцать лет я занимаюсь аналитикой в страховании, из них большую часть — в ДМС и андеррайтинге в том числе. И кажется, мне есть что сказать по вопросу: что на самом деле отличает ML от привычного GLM; и что стоит за модной темой каузальных моделей, которые сейчас показывают на каждом демо.

Речь пойдёт про массовые виды: ОСАГО, каско, розничный ДМС, имущество физлиц.

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

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

Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 (разбор на Habr), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir (бенчмарк VictoriaMetrics, замер вендора, 2022 год).

На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

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

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

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

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

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

У нас в публичном облаке VK Cloud у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.

В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.

Пригодится тем, кто держит прокси перед хранилищем и хочет перенести правила доступа в само хранилище, и специалистам по ИБ, которым нужно доказать разграничение доступа выгрузкой, а не скриншотом консоли. Для другого S3-совместимого хранилища применима основная часть: механика проверки и матрица тестов от платформы не зависят.

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

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

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

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

Если у вас когда-нибудь ломалась SD-карта, то вы знаете, как обычно решают эту проблему: снова попробовать вставить её в фотоаппарат, сменить кард-ридер, проверить на другом компьютере и, если вообще никто её не обнаруживает, признать карту мёртвой.

Но почему она умерла?

Это уже гораздо более интересный вопрос, потому что смерть SD-карты необязательно означает смерть памяти NAND, и совершенно не подразумевает потерю хранящихся на карте данных.

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

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

Когда компакт-диски только появились, их позиционировали почти как вечный носитель (не кварц, конечно, но близко к тому). И ведь логично - если не царапать поверхность, то работать такой диск должен действительно много, много лет. Многие считали, что информацию с лазерного диска, записанную в 2000-х, можно будет без проблем считать и через полвека. На практике все оказалось немного не так.

Срок службы конкретного диска предсказать невозможно. Даже два внешне одинаковых CD одного возраста могут стареть по-разному: один без проблем проработает несколько десятилетий, а у другого начнет разрушаться отражающий слой или мутнеть поликарбонатная основа. При этом первые повреждения часто остаются незаметными, а проявляются лишь зависаниями и ошибками чтения. Что происходит и как предотвратить потерю информации? Давайте обсудим.

«Ennyn Durin Aran Moria: pedo mellon a minno» — «Врата Дурина, Владыки Мории. Скажи „друг“ и войди».

Самый известный пароль в литературе — эльфийское mellon, «друг» — открывал Западные врата Мории любому, кто удосужился прочитать надпись прямо над ними. Удобно для своих. И, к сожалению, для чужих тоже.

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

Администратор правильно настроил политику паролей в домене: минимум 12 символов, три класса символов, история, блокировки. Но проверка показывает, что пароли учётных записей сотрудников есть в публичных дампах и словарях. «Сложные» пароли вроде Zima2025!, P@ssw0rd и Qwerty123! формально соответствуют политике, но злоумышленнику понадобится не так много попыток, чтобы подобрать такие пароли.

Проблема в том, что доменная политика проверяет пароль на соответствие правилам, но ничего не знает про его значение. Она не в курсе, что P@ssw0rd — самый заезженный «сложный» пароль на планете, а пароль из названия компании и года подбирается с трёх попыток.

Почему пароли — всё ещё слабое звено №1

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

А что стоит между учётной записью и злоумышленником? В большинстве инфраструктур — всё ещё только пароль: не аппаратный ключ, не биометрия и не второй фактор на каждом сервисе, а строка, которую сотрудник придумал сам и, будем честны, придумал так себе. Можно сколько угодно внедрять MFA, PAM и Zero Trust — пароль в AD остаётся фундаментом, на который всё это опирается. Скомпрометированная доменная учётная запись открывает вход злоумышленнику. В итоге — компрометация всего домена и громкая история: простой производства, отмены рейсов, утечки персональных данных…

Представьте, разработчики добавили прозрачное шифрование в файловую систему, собрали ядро и прогнали Fio — пропускная способность не изменилась. Однако после раскатки на продакшен производительность резко упала. Дело не в том, что бенчмарк ошибся: он честно измерил предел быстродействия жесткого диска, а накладные расходы на шифрование остались скрыты за дисковыми задержками. Так и возникает одна из самых типичных ошибок storage-бенчмаркинга.

Хранение до сих пор кажется многим инженерам простой подсистемой: файловая система, блочное устройство, метрика throughput. На практике это одна из самых коварных частей стека — с иерархией памяти в 4–8 порядков разницы между самой быстрой и самой медленной операцией, слоями виртуализации (LVM, программные RAID, NFS) и переключениями контекста между ядром и user-space.

Чтобы разобраться, как корректно измерять производительность систем хранения, обратимся к докладу Эреза Цадока, профессора Университета Стони-Брук, возглавляющего Лабораторию файловых систем и хранения данных.

Все подробности — под катом.

Привет, бойцы, вы готовы победить перенос данных?

Есть задача: перенести данные из PostgreSQL в Kafka. Первая мысль: написать небольшой сервис.

Он будет выполнять SELECT, превращать строки в сообщения и отправлять их через Kafka Producer. На схеме все выглядит почти безобидно:

Накопитель — это такой компонент ПК, который предпочитает разочаровывать постепенно. Ну, смотрите. Видеокарта либо тянет игру, либо нет. Процессор как считал, так и считает в течение всего срока эксплуатации. А вот SSD, который в день покупки перекидывал файлы со свистом, через год запросто может начать тормозить так, как Киа Оптима на шинах Gislaved. То есть не будет ни ошибок, ни предупреждений, ничего. Он просто станет медленнее, и все. Интересно, почему?

Привет, Хабр! На связи Александр Курносов, руководитель группы платформы данных, и Андрей Двинских, инженер больших данных. В ежедневной работе мы используем несколько инструментов. Чтобы разобраться с очередной задачей, приходится переключаться между ними, искать нужную информацию и собирать общую картину буквально по частям. В какой-то момент мы поняли, что большинство таких действий повторяются каждый день. Поэтому решили собрать самые востребованные сценарии в одном внутреннем инструменте. Так появился ETL log. В статье расскажем, почему решили его создать, какие задачи он помогает решать и как устроена работа с ним.

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

Начинал я как все, со связки Obsidian и Claude.

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

Как это у меня устроено сейчас и сколько токенов на это потрачено

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

Я поставил Obsidian, завёл хранилище, стал туда складывать заметки, документы, истории - да все подряд.

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

Из этого сбылось только то, что граф действительно приятно смотреть, и заметки удобно читать глазами. Но Obsidian это не база знаний. Для меня сейчас это программа для просмотра папки с текстовыми файлами. Она красивая, с графом и плагинами.

В один из дней в лаборатории раздался звонок. Звонил представитель организации, оказывающей услуги системного администрирования. Его первым вопросом было: «А вы умеете работать с ZFS?». Разумеется, мы пояснили, что у нас есть некоторые наработки в рамках собственных исследований, а также стандартные средства DR‑лаборатории, такие как PC-3000, где поддержка ZFS предусмотрена как минимум на базовом уровне.

Ответив на парочку каверзных вопросов клиента об устройстве ZFS, мы через некоторое время получили два SSD Samsung 870 EVO ёмкостью 2 ТБ, которые были объединены в зеркальный RAID‑массив (Mirror). Изначально комментарии сводились к тому, что оба диска рабочие, но один выпал из массива. Основная проблема заключалась в том, что был случайно удалён один из важных Zvol (блочный объект ZFS, используемый для виртуальных дисков). Клиент пояснил, что хотел откатиться к прошлой версии uberblock’а и получить снимок, когда этот Zvol ещё не был удалён, но у него это не получилось. Резервная копия сохранилась, но она была сделана ещё в апреле этого года.

Когда NAS ушёл, я перевёз свою домашнюю хранилку в корпус побольше и даже разжился hot-swap-салазками.

Только вот со временем пришлось выбирать — новая мебель или большая железка. И я выбрал — сделать железку поменьше.

Рассказываю, как смастерил компактное хранилище «а-ля NAS» из подручных средств.

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

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

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить