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

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

Всем привет! Меня зовут Александр Пивкин, я ведущий SRE-инженер в MWS Cloud Platform. Сейчас Ceph — основная технология хранения данных в MWS Cloud Platform, и поэтому она должна работать хорошо. 

Сегодня сфокусируемся на инструментах диагностики и устранения проблем производительности в Ceph-кластерах.

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

Масштаб проблемы хорошо иллюстрируют оценки International Data Corporation: рост мировой датасферы с 33 зеттабайт в 2018 году до 175 зеттабайт к 2025-му.

Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это бонусная статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом до 1,5 млн рублей. Сегодня разбираем не BI-систему, а инструмент, без которого многие BI-проекты в России буксуют, – экстрактор данных из 1С от компании «Денвик-Аналитика».

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

Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.

Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.

Apache Doris 4.1 добавляет UPDATE, DELETE и MERGE INTO на Iceberg-таблицы прямо из SQL-клиента — без отдельного Spark job. Iceberg V3 Deletion Vectors и Row Lineage делают этот DML архитектурно здоровым: нет линейной деградации от delete files, нет false positives в CDC после compaction. Перевод и адаптация статьи Mingyu Chen (CC BY 4.0) с бенчмарками, SQL-примерами и Quick Start.

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

Цель - протестировать производительность трёх систем объединения физических устройств в одно логическое систем при использовании iSER и NVMe-oF. Так как статья получилась объёмная, она поделена на 2 части. В этой части - тесты с использованием HCIbench и iSER\NVMe-oF

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

Цель - протестировать производительность трёх систем объединения физических устройств в одно логическое систем при использовании iSER и NVMe-oF. Так как статья получилась объёмная, она поделена на 2 части, в первой идут тесты на уровне локального устройства + вступление. Во второй уже тесты с использованием HCIbench и iSER\NVMe-oF

Всем привет! Храню 7 терабайт фото и видео у себя дома на Synology DS224+ с DSM 7.3+

Это сетевое хранилище поддерживает Docker. Я дополнительно установил плашку памяти и теперь у меня 18 ГБ ОЗУ.

Но суть в том, что ночами я слышу "булькание" и "шуршание" дисков, кстати диски красные, прямо созданные под сетевые хранилища: WD120EFBX-68B0EN0 две штуки по 12 ТБ с зеркалированием.

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

Выложил проект в репозиторий

Привет, Хабр! На связи Даша Косова, я продакт менеджер Рег.облака.  Представим знакомую многим ситуацию. У компании есть сервер. Он работает уже несколько лет. На нем крутятся базы данных, backend-сервисы, cron-скрипты, система мониторинга. Всё настроено, всё работает, и трогать это никто особенно не хочет.

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

Ситуация до боли знакома каждому, кто регулярно арендует выделенные серверы: вы оплачиваете счет, заходите по SSH и видите, что ОС установлена на /dev/sda, а второй диск просто болтается пустым. Никакого RAID, никакой отказоустойчивости. Умрет первый диск — ваши данные исчезнут. Мы в SoftStore идем по пути полного контроля над процессом. В этой статье разбираем пошаговый протокол: как собрать программный RAID 1 и LVM прямо на живой, работающей операционной системе без использования Rescue-режима и переустановки. В качестве бонуса — практика по управлению квотами, снапшотами и замене дисков в Production.

При масштабировании инфраструктуры вчерашние рабочие процессы часто превращаются в архитектурные. Линейный рост затрат на хранение, проблемы консистентности СУБД при восстановлении из снапшотов и зависимость от закрытых API — это реальность, в которой живут многие команды. Ситуация усложняется, когда бэкапы становятся целью для атак, а стандартного контроля доступа оказывается недостаточно. В релизе Хайстекс Акура 4.5 мы собрали инструменты, которые делают инфраструктуру по-настоящему автономной и защищенной. Под катом — подробнее о каждом из них.  

Самая опасная угроза — внутри

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

Меня зовут Андрей Рыжик, я разработчик BI в компании «Белый код». Это четвёртая статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом 1,5-2 млн рублей. Сегодня разбираем Biplane24.

Прывітаначкі, похоже с одной стороны сегодня программистов нужно меньше чем раньше, с другой стороны — благодаря LLM действительно можно делать задачи на порядок быстрее. Предполагаю, что в ручную этого бота я бы делал месяц, через Codex gpt-5.5 xhigh — часа три.

В Evernote у меня записано много идей. Хорошо бы то, хорошо бы это. И таки некоторый прогресс в их реализации есть. И вот недавно — открываю официальное приложение Evernote на iPhone, а заметки не загружаются. У меня самый дорогой премиум аккаунт. Вот так стало понятно — надо делать.

Про другие неофициальные клиенты:

Я мантейнер Geeknote — неофициальный CLI на Питоне, он внутри моего бота.

NixNote на C++

CliNote на Go — недавно заархивирован — feel free to форкнуть и починить.

И вот теперь я сделал Телеграм бота https://gitlab.com/vitaly‑zdanevich/bot_telegram_evernote

На Питоне — хотя я предпочитаю Go — но Geeknote зависимость на нём, так что для единообразия.

Quest For The Holy Memex: Часть 3 или обзорная

Mundaneum, Memex, Zettelkasten, Catalyst, Palantir, Maltego

1. Mundaneum Поля Отле

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

Из личного опыта вспоминались только обычные библиотечные указатели по алфавиту, которые мягко говоря проблему не решали от слова совсем. Если проблема давняя, и на нее уже давно обращали внимание, то должно уже было быть хоть какое‑то решение, так почему же мы до сих пор используем только эти примитивные библиотечные указатели? Ладно, есть еще Google, но у него свои ограничения.

У меня не было задачи найти и изучить ВСЕ подходы к организации и работе с большими объемами информации (эта тема потянет на полноценное научное исследование), также я не буду рассматривать сугубо теоретические концепции (как например «Мировой мозг» Герберта Уэллса), остановлюсь только на самых интересных по моему мнению проектах, которые пытались сделать практическую реализацию, хотя бы в виде спецификаций.

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

Меня зовут Джер Крейн, я основатель PocketOS. Мы делаем ПО для прокатного бизнеса — в первую очередь для аренды автомобилей: бронирования, платежи, управление клиентами, отслеживание транспортных средств. Некоторые наши клиенты с нами уже больше 5 лет и они буквально не могут работать без нас.

Вчера днём ИИ‑агент на базе Cursor с Claude Opus 4.6 от Anthropic удалил нашу продакшн‑базу данных и все резервные копии на уровне тома одним API‑вызовом к Railway, нашему инфраструктурному провайдеру.

На это ушло 9 секунд.

Затем агент, когда его попросили объяснить произошедшее, написал признание — с перечнем конкретных правил безопасности, которые он нарушил.

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

Практическое пособие по устройству production‑ready агента.

Поскольку последнее время я плотно занимаюсь разработкой ии‑агента, и, по прогнозам директора, должен скоро все сдать (лол), то я решил описать в первую очередь для себя кое‑какие моменты, которые стоит учесть при разработке агентской системы в 2026 году. Я планирую серию статей на основании своего опыта. Не судите строго, на платных курсах расскажут гораздо лучше. Накидать в комменты приветствуется. Перевод терминологии вольный.

Сейчас мне кажется, что весь софт, который последнее время делается — это один сплошной ии‑агент, который потенциально должен уметь всё на свете. При этом пользователи в 2026 году не готовы ни к какой другой форме отношений с приложениями, кроме как промптинг. Если во время презентации продукта они видят больше одной кнопки «отправить промпт», то сразу заявляют, что им сложно, а у тебя появляется чувство, словно ты им должен заплатить за то, чтобы они осилили твой софт. Ну ладно, мобильные телефоны в итоге ведь превратились в прямоугольники с экранами. Может, и у софта есть «финальная форма» в виде ии‑агента с интерфейсом. 

Quest For The Holy Memex: Часть 2 или Вавилонский синдром...

Хорошо, у нас есть “имя зверя” - информационные перегрузки, и есть гипотеза, что именно эта штука на самом деле сильно портит мне жизнь (и не только мне), как это проверить и доказать? Как можно вообще “отдебажить” реальность? Мы не можем изолировать эти сценарии, погонять тесты - даже в естественных науках это не всегда возможно, в социальных “искусствах” вообще все очень плохо даже с воспроизводимостью опытов.