P.S. Если захочешь развить идею с анализом новостей по криптовалютам, прикладываю файл с воркфлоу из видео. Это лишь базовый пример, который можно и нужно улучшать. Может кому-нибудь будет полезно чисто для себя 🥃

#опытным #системное_программирование

Представь: ты пишешь на C++. Твой коллега на Rust. А в соседней команде пишут на Swift.

Код выглядит по-разному, инструменты разные, даже культура другая…

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

Почему? Потому что под капотом у этих языков используется один и тот же набор оптимизаций, работающих не с исходным кодом, а с его промежуточным представлением или IR (Intermediate Representation).

Дисклеймер: это работает только для компилируемых языков. Тех, что превращаются в нативный код до запуска. Интерпретируемые (Python или Ruby) или JIT-языки(Lua или старый JavaScript) устроены иначе.

Что такое IR?

Когда компилятор получает твой код, он сначала парсит синтаксис (это делает фронтенд: Clang для C++, rustc для Rust и т.д.). Затем он превращает его в IR - низкоуровневое, но архитектурно-независимое представление программы. Это представление было специально спроектировано таким образом, чтобы на нем было удобно реализовывать оптимизации.

Сегодня самый популярный IR - LLVM IR.
Он используется, например, в Clang (C/C++), rustc (Rust), Swift, Kotlin, CUDA

Как оптимизации ускоряют мою программу?

Разберем несколько ключевых оптимизаций:

1. Constant Folding

Вычисляет константные выражения на этапе компиляции.

До:

int x = 17 * 4 + 100 / 2;

После:

int x = 118;

Почему ускоряет:
Убирает арифметику из рантайма особенно критично в "горячих" циклах или hot paths.

2. Dead Code Elimination (DCE)

Удаляет код, результат которого нигде не используется.

До:

int a = heavy_computation(); // a не используется дальше!
int b = 42; 
return b;

После:

return 42; 

Почему ускоряет:
Вызов heavy_computation() полностью исчезает. Экономит CPU-время, память кэша.

3. Loop Invariant Code Motion

Выносит неизменяемые вычисления из цикла.

До:

for (int i = 0; i < n; ++i) {
    y[i] = x[i] * strlen(name); // strlen(name) вызывается 1000 раз!
}

После:

int len = strlen(name); // один раз
for (int i = 0; i < n; ++i) {
    y[i] = x[i] * len;
}

Почему ускоряет:
Сокращает работу в теле цикла → меньше инструкций на итерацию → выше IPC (инструкций за такт).

4. Function Inlining

Заменяет вызов функции её телом.

До:

int square(int x) { return x * x; }
...
total += square(i);

После:

total += i * i; // вызова нет!

Почему ускоряет:
Убирает overhead вызова (сохранение регистров, прыжок) + открывает новые оптимизации (например, DCE или constant propagation).

Как не мешать компилятору?

Компилятор может применять агрессивные оптимизации только если уверен, что поведение кода не изменится. Чтобы дать ему эту уверенность:

- Пиши чистые функции в hot paths: без I/O, глобальных состояний и побочных эффектов:

fn square(x: i32) -> i32 { x * x } // без I/O, глобалов, побочек

- Передавай данные явно, а не через глобальные переменные:

int process(int config) { return config * 2; } // вместо чтения global_config

- Не прячь побочные эффекты в методах вроде size():
Если data.size() вызывает блокировку, компилятор не вынесет его из цикла.

Вывод:

Синтаксис языка - это обёртка. Настоящая магия оптимизаций происходит глубже - в промежуточном представлении, где границы между Rust, C++ и Swift стираются.

Поэтому после выбора алгоритма, твоя задача написать код, который чётко выражает твои намерения и не мешает анализу компилятора. Тогда оптимизации вроде свёртки циклов, векторизации и инлайнинга заработают, и твой O(n) будет не просто асимптотически правильным, а максимально быстрым на практике.

P.S. Не забудь включить максимальный уровень оптимизаций (-O2 или -O3) в релизе. Иначе весь этот потенциал так и останется нереализованным😎

#ии #ии_агенты #начинающим #n8n

AI-агенты, часть 3: Собираем своего первого агента в n8n

Делаем следующий шаг в изучении AI-агентов (шаг №1, шаг №2). В прошлый раз я разобрал основы n8n, а сегодня заценим главную ноду AI Agent.

В чем разница между обычной нодой LLM-модели и нодой агента?
Модель: получила данные → обработала → отдала результат → забыла.
Агент: получил задачу → подумал → использовал инструмент → получил данные → снова подумал → (сжег все токены) → использовал другой инструмент. И так по кругу, пока не достигнет цели.

Итог: агент это что-то, что умеет действовать исходя из своих рассуждений.

------------------------------

Ядро: ИИ-модель 🙄

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

Для тех, кто хочет попробовать что-то собрать, поделать автоматизации для себя и близких, мой совет- Gemini через Google AI Studio. Почему?
Это бесплатно - там довольно много бесплатных запросов каждый день. Плюс можно использовать несколько акков и менять api ключи, если вдруг не хватит.
Легко подключается - заходишь в AI Studio (понадобится VPN), регаешься, жмешь "Get API Key", получаешь ключ и вставляешь в n8n ноду модели. Вуаля!

Да, стабильность может плавать, и есть лимиты, но камон, это одна из лучших моделей на рынке, доступная бесплатно. Для личных автоматизаций топ, по лимитам, мне с нескольких аккаунтов для личных целей с головой хватает сразу на несколько автоматизаций (как дойдут руки - поделюсь ❤️). А еще есть большой выбор моделей - есть побыстрее, а есть поумней.

------------------------------

Инструменты 🔧

Это самое интересное. Инструменты это любые действия, которые агент может выполнить. И тут смотришь на имеющийся список и глаза разбегаются: можно подключить Google Calendar, чтобы агент управлял вашим расписанием, GitHub для ревью пиаров и создания новых ишью, Execute Command для выполнения команд на сервере, Telegram для управления группой или универсальный HTTP Request для работы с любым API в интернете. Обязательно зацени, если цепляет эта тема.

Но как агенту понять, какой инструмент использовать? Он не читает твои мысли, он читает описание, которое ты даешь каждому инструменту. И важно его сделать максимально понятным, иначе агент просто не сможет правильно воспользоваться ими.

Мини-туториал: Как правильно описывать инструменты

1. Пиши просто и понятно. Представь, что даешь инструкцию стажеру. Вот как бы ему описывал задачу, так сделай это и для модели. Чем подробнее и понятней сделаешь, тем меньше шансов, что набедокурит. Русский язык подойдет, но английский все же лучше (даже для отечественного ГигаЧата🍊).
2. Используй четкую структуру. Идеальное описание отвечает на три вопроса:
* Что делает? - "Этот инструмент ищет информацию в Википедии Грокопедии" (мы на волне трендов)
* Когда использовать? - "Используй его, когда пользователь спрашивает о людях, местах, событиях или просит дать определение какому-либо термину"
* Какие данные нужны? "На вход ему нужно подать поисковый запрос в виде строки. Строка на русском, без спец символов."
3. Приводите примеры. Модели обожают примеры. Это помогает им лучше понять контекст. Вообще это золотое правило при работе с ИИ моделями.

📉**Плохое описание:** "Википедии Грокопедия. Вход: query."
*(Агент не поймет, КОГДА это использовать).*

📈**Хорошее описание:** "Ищет статьи в Википедии Грокопедия. Используй, если нужно проверить информацию о событии, цитатах и терминах. Пример запроса от пользователя: "Кто такой Илон Маск?"."

------------------------------

Память 🐹

Чтобы агент помнил ваши прошлые сообщения, ему нужна память.
* Для простых задач можно использовать встроенную опцию Simple Memory- история будет храниться прямо в n8n.
* Для сложных ботов можно подключить внешнюю базу данных, например, Redis.

Чем больше контекста, тем точнее ответы. Но не перебарщивай: у каждой модели есть лимит длины контекста. Если его превысить, модель может начать вести себя как дурик (да, ответы на испанском из ниоткуда это как раз отсюда).

Продолжение ⬇️

------------------------------

С чего начать?

Конечно, можно сидеть и собирать всё с нуля. Но я советую брать готовые воркфлоу как шаблоны и адаптировать под себя (я так и делаю). Вот несколько ссылок на базы с примерами: база_самого_n8n, хороший_гит_с_workflows, еще_один_хороший_гит.

Мой главный совет: бери и пробуй 💪. Сначала кажется, что всё сложно, но через пару вечеров экспериментов всё станет гораздо проще. Если что-то непонятно, на YouTube есть куча роликов, но я часто просто спрашиваю у той же Gemini, как что-то сделать, в 90% случаев она реально помогает (но эти 10% галюцинаций, мммм).

------------------------------

Вместо вывода:

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

#виртуальная_память #системное_программирование

Когда ты запускаешь Chrome, VS Code и, скажем, компиляцию большого проекта, то у каждого процесса полное 48-битное адресное пространство (до 256 ТБ). А на твоей системе всего 16 или 32 ГБ оперативы (RAM).

Как тогда это все работает? 🤔

Все дело в том, что адреса, которыми оперирует код, на самом деле виртуальные (VA).
Один и тот же VA, например 0x7fff0000, у разных процессов - это разные места в RAM.

Это возможно благодаря MMU (Memory Management Unit) - аппаратному блоку внутри CPU, который переводит VA в физические адреса (PA): реальные номера байтов в оперативной памяти.

Зачем это нужно?🤔

- Изоляция: MMU гарантирует, что один процесс не может прочитать или испортить память другого, VA разных процессов могут совпадать, но PA никогда.

- Экономия: одна физическая страница (например, с кодом какой-либо библиотеки) может быть отображена в VA многих процессов, но В RAM будет находиться только одна копия.

- Ленивость: выделение 1 ГБ оперативы лишь резервирует диапазон VA. Физическая память выделяется по факту первой записи через page fault.

Как происходит трансляция VA → PA: аппаратный перевод, который почти никто не видит 🙈

На архитектуре x86-64 виртуальный адрес (48 бит) разбивается на уровни:

[9 бит] → PML4  
[9 бит] → PDPT  
[9 бит] → PD  
[9 бит] → PT  
[12 бит] → offset внутри страницы (4 КБ)

Что это за аббревиатуры?🐱

- PML4 (Page Map Level 4) - корневая таблица отображений: массив из 512 записей. Каждая запись - это указатель на следующий уровень.

- PDPT (Page Directory Pointer Table), PD (Page Directory), PT (Page Table) - следующие уровни иерархии. Каждая запись в них тоже указывает на таблицу ниже, а в PT уже на физическую страницу.

- В PT лежит PFN (Page Frame Number) — номер 4-КБ страницы в физической памяти.

Физический адрес вычисляется по формуле:

 PA = (PFN << 12) + offset.

Итого, для перевода одного виртуального адреса в физический MMU читает до 4 записей из оперативной памяти.

На DDR4 (стандартной RAM в большинстве ПК/ноутбуков) доступ к памяти стоит порядка 100 тактов, а page walk может занять 200–300 тактов.

Что придумали: TLB - кэш прямо в CPU 🤓

Чтобы не делать page walk каждый раз, MMU кэширует переводы в TLB (Translation Lookaside Buffer) - маленьком, но очень быстром кэше внутри процессора. Кстати, мы уже упоминали этого товарища в одном из предыдущих постов.

Есть два основных уровня TLB:

- DTLB (Data TLB) - маленький (~64 записи), быстрый, для данных.

- STLB (Second-Level TLB) - побольше (~1024–2048 записей).

Таким образом, если VA есть в TLB, то перевод делается за 1 такт.
А если нет, то TLB miss → page walk → 100–300 тактов.

То есть, если в горячих участках кода, где много итераций, ты работаешь с данными, разбросанными по тысячам страниц, а TLB вмещает лишь тысячу, то ты платишь за page walk почти на каждом доступе.😣

Вывод: как не убить перформанс

Виртуальная память - очень мощная абстракция, но она не прощает плохую локальность here we go again:

- Делай доступ к памяти последовательным, минимизируй число страниц в горячих участках.

- Избегай мелких аллокаций в циклах, каждая новая страница давит на TLB.

- Не прыгай по памяти, random access по большому диапазону почти гарантирует TLB thrashing.

Помни, что компилятор может векторизовать, инлайнить, убирать мёртвый код, но он не может увеличить размер TLB😎

#операционные_системы #системное_программирование

Представим мир до операционных систем.

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

Один баг и машина зависает😵

Ну и как в такой обстановке писать Telegram бота? Так не пойдет. Именно поэтому инженеры изобрели операционные системы(ОС).

Для чего же они нужны?🤔

ОС - это надёжный посредник между твоим кодом и машиной.
Она берёт на себя всю сложную, опасную, рутинную работу и даёт тебе простые, предсказуемые абстракции:

- Вместо «диска с секторами» → файлы и директории
- Вместо «регистров и таймеров» → процессы и потоки
- Вместо «физической RAM» → виртуальную память
- Вместо «ручного переключения задач» → планировщик, который сам решает, какая задача и когда получит процессор

Но как она это обеспечивает?👌

Современные процессоры умеют работать в двух режимах:

User space (пользовательский режим)

- Здесь живут твои программы: Python, браузер, твой сервис.
- У них нет доступа к чувствительным частям системы: нельзя трогать настройки памяти напрямую, нельзя общаться с диском или сетью без разрешения, нельзя читать память другого процесса даже если знаешь адрес. Любая попытка - и процессор автоматически передаёт управление ядру.

Kernel space (ядерный режим)

- Здесь работает ядро - самая привилегированная часть ОС.
- Ему разрешено всё: менять таблицы памяти, управлять устройствами, останавливать и запускать процессы.
- Именно ядро проверяет каждый твой запрос: «Можно ли этому процессу читать этот файл?», «Хватит ли ему памяти?», «Не пытается ли он выйти за границы?»

Переход из user space в kernel space возможен только через определённые точки, например, системные вызовы (read, write, mmap).

А что такое системные вызовы?🤔

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

data = file.read(1024)

на самом деле происходит следующее:

1. Твой код просит ядро: «Прочитай 1024 байта из этого файла и положи в мой буфер».
2. Процессор переключается в ядерный режим. Быстро, но не мгновенно.
3. Ядро проверяет:
• открыт ли файл?
• разрешено ли читать?
• не указывает ли буфер в запрещённое место?
4. Только после этого начинается само чтение
5. Данные копируются в твой буфер
6. Управление возвращается в твой код.

Таким образом, каждый read, write, open, malloc - это поход в ядро. А каждый поход - это сотни тактов процессора🤯

Почему это важно на практике🤓

- Когда ты вызываешь write(fd, ".", 1) в цикле 10 000 раз → 10 000 системных вызовов → 100 000+ тактов только на переключения.
Решение: собирай данные в буфер → один write(fd, big_buf, N)

- Когда ты открываешь и закрываешь файл на каждой итерации → каждый open() = проверка прав, поиск inode, аллокация дескриптора.
Решение: держи файл открытым или используй mmap, если данные статичны и нужны только для чтения.

Правило простое: чем чаще ты стучишься в ядро, тем медленнее работает программа.

Как проверить, насколько часто я стучусь в ядро?🖥

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

# Сколько системных вызовов делает твоя программа?
strace -c python3 script.py

# Где происходят page faults?
perf record -e page-faults python3 script.py
perf report

Red Flag 💅, если:
- syscalls > 100 000 за секунду при умеренной нагрузке
- page-faults растут линейно с объёмом данных
- context-switches высокие без явной блокировки

Это значит, что проблема не в логике. Проблема в частоте обращений к ядру.

Вывод: Производительность часто ограничивается не алгоритмами, а количеством переходов в ядро. Минимизация системных вызовов - это первый шаг на пути к эффективному коду🍸

Знаешь ли ты как работают умные колонки и реально ли они слушают тебя 24/7? Давай сегодня разберемся как умные помощники вроде Алисы, Салюта или Siri умудряются услышать заветное слово, не сливая при этом всю твою жизнь на серверы 🐰

-----------------

Давай сразу обговорим: конечно, никто им не мешает слушать тебя постоянно (ты все равно подпишешь любое пользовательское соглашение не глядя). Но теперь представь миллионы пользователей, и ты поймешь, что слушать весь этот аудиопоток, весь мусор, тишину, телек и тд - это такой дикий оверпрайс, что ни одна компания на это не пойдет. Ни одна персонализированная реклама не отобьет эти затраты. Экономика > шпионаж.

-----------------

Тогда как оно работает? 🧀
Ну, смотри - главный герой этой пьесы споттер (keyword spotter). Если по-простому, это крошечный, вечно работающий "слухач" (почти уверен, что на НТВ есть такой сериал про ментов), задача которого найти одно единственное слово в бесконечном потоке звука. И он делает это полностью ЛОКАЛЬНО, прямо на твоей колонке / телефоне.

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

Как искать?⌚️
Тут два пути - старая и новая школа.

Старая школа:
Скрытые Марковские Модели (HMM). Представь, что слово "Алиса" это рецепт, состоящий из звуков: [а] -> [л] -> [и] -> [с] -> [а]. HMM-алгоритм работал как раз по такому принципу. Он слушал звук и постоянно задавал себе вопрос: "Какова вероятность, что звуки, которые я слышу прямо сейчас, соответствуют моему рецепту?".

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

Новая школа:
Сейчас правят нейронки. Нейронка, чаще всего сверточная (CNN), смотрит на спектрограмму не как на последовательность звуков, а как на картинку.

- За счет чего работает? За счет распознавания образов. Нейросеть обучают на тысячах примеров произнесения Алисы, и она учится находить уникальный визуальный паттерн, который это слово оставляет на "карте частот". Ей уже не так важна идеальная последовательность, она ищет общую, характерную картину.
- Стало ли лучше? Однозначно. Этот подход гораздо устойчивее к шуму, разным интонациям и темпу речи. Нейронка улавливает суть звучания слова, а не его формальный рецепт. Именно поэтому современные колонки понимают тебя намного лучше, чем старые системы распознавания.

Новейшая школа:
Посадить индуса и пусть слушает (в свете последних новостей)🌟

Как улучшают? 💪

Трюк №1: Борьба с глюками и ложными срабатываниями:
Чтобы нейронка не реагировала на всё подряд, её обучают не только на ключевое слово, но и на тонны мусора. Обрывки другой речи, шум улицы, музыку. Это называется filler models. Таким образом мы уменьшаем кол-во ложных активаций.

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

Трюк №3: Двухэтапная верификация
Когда твой локальный споттер с вероятностью 95% решил, что услышал ключевое слово, он будит основную систему. Короткий кусок аудио (включая само ключевое слово) летит на сервер, где его перепроверяет уже большая и мощная нейросеть. Если и она говорит "Да, это оно!", то уже вряд ли мы ошиблись. Это защищает от случайных активаций.

Вместо вывода:
Так что да, пока не сказал ключевого слова, считай тебя не слушают. Твои секреты в безопасности. А вот всё, что сказано ПОСЛЕ него... как говаривал классик - это уже совсем другая история 😃

#system_design #архитектор #собеседование #шпаргалка #vibecoding

Сейчас каждый второй стартап хочет быть как Netflix и сразу пилит микросервисы. А в итоге получает тот же монолит, только на разных машинах: собрал все минусы сложной архитектуры (сеть тормозит, дебажить сложно), а плюсов (гибкость и скорость) так и не увидел.

Ловите чек-лист - это база system design, которую стоит понять. Пригодится как на собесах в бигтех на старшие позиции, так и при создании своего вайбкодинг стартапа (если вдруг стрельнет и будет что-то большое, я в тебя верю).

-----------------

1. Single Responsibility (Принцип единой ответственности) 👩‍🍳👩‍🌾👨‍🎨🤠🥸
Сервис должен делать одну вещь, но делать её лучше всех.
Не надо создавать божественный сервис, который и за корзину отвечает, и за ее оплату, и за уведомления об оплате. Это путь к боли.
Как проверить: Если описание того, что делает сервис, содержит слово «и» (например: управляет пользователями И рассылкой), смело режь его на части.
А зачем: Чтобы изменение в логике отправки уведомлений случайно не положило процесс оплаты. Изоляция сбоев по умному.

2. Database per Service (База на каждый сервис) ⌨️
Самое больное правило. У каждого сервиса- своя БД. Никаких общих таблиц. Данные сервиса это его интимная зона (точка G, если хотите).
Если сервису "Заказы" нужны данные сервиса "Клиенты", он не лезет напрямую в чужую базу SQL-запросом. Он вежливо стучится в API "Клиентов".
Почему так жестко: Если у вас общая база, то любое изменение схемы одной таблицы ломает половину системы. Это жесткая связность, от которой мы как раз и пытаемся убежать.

3. Границы по бизнес-доменам (DDD) 😗
Мы строим архитектуру вокруг реальной жизни, а не технических слоев. Забудь про сервисы с названиями "контроллеры" или "менджеры".
У нас должны быть: "Сервис Заказов", "Склад", "Доставка", "Биллинг".
Фишка: Когда бизнес приходит с новой фичей для "Доставки", ты правишь код только в одном месте, а не прыгаешь по 10 разным техническим микросервисам. Это называется Bounded Context.

4. Независимая сборка и деплой 🐸
Если чтобы выкатить обнову в "Корзине", тебе нужно договориться с тремя другими командами и ждать общего релизного поезда в четверг- у тебя не микросервисы.
У каждого сервиса свой репозиторий и свой CI/CD пайплайн.
Идеал: Команда А выкатывает релиз хоть 10 раз в день, вообще не спрашивая разрешения у команды Б. Жизненные циклы полностью изолированы.

5. Stateless (Без сохранения состояния) 😐
Серверы должны быть как ты в сессию - ничего не помнить. Мы не храним данные сессии в оперативной памяти (RAM) конкретного инстанса.
Вся инфа о юзере лежит во внешних хранилищах (Redis, БД).
Зачем: Чтобы мы могли в любую секунду поднять еще 10 копий сервиса или убить 5 старых, и пользователь ничего не заметил. Для сервера любой пришедший запрос как первый, он не зависит от того куда стучался юзер секунду назад.

-----------------

Вместо вывода:
Микросервисы это не про технологии (Docker/K8s), это про организацию кода и команд. Если собрался делать микросервисы, то важно придерживаться этих правил, иначе можно получить результат куда хуже, чем старый добрый монолит.

🎁 РОЗЫГРЫШ 3-х PRO-ПОДПИСОК

Хотим сделать ваш старт нового 2026 года проще и продуктивнее. Разыгрываем 3 месячные подписки на топовые ИИ-сервисы (на выбор победителя): ChatGPT, Cursor, Gemini AI или Claude.

Лайфхак: Подписчиков у нас пока немного, поэтому конкуренция низкая, а шансы на победу огромные. У тебя есть все шансы забрать эту подписку ❤️

Как принять участие:
✅ Подпишитесь на @idei_iz_doliny
✅ Подпишитесь на @nu_smotri_tech
✅ Нажмите кнопку «Участвую» внизу поста.

🏆 3 победителя будут выбраны случайным образом.

⏳ Результаты: 9 января в 18:00.

С победителями мы свяжемся лично, уточним какой сервис нужен, и всё оформим.

Жми кнопку, забирай подписку! С наступающими праздниками! 🍊

#CUDA #GPU #производительность

Представь: ты обрабатываешь какой-либо сигнал, например, аудиозапись, показания датчиков, массивы I/Q-данных с АЦП.

И для каждой точки ты хочешь посчитать какую-то характеристику, например, по формуле:

for (int i = 0; i < N; ++i) {
    out[i] = sin(x[i]) * cos(y[i]) + exp(z[i]);
}

Код простой. Все работает. Но если точек много, скажем, 10 миллионов, то на ноутбуке это займёт уже несколько секунд, цикл начинает тормозить.

Ты смотришь на это и думаешь: "А что, если считать все точки сразу параллельно?" 🤔

Казалось бы, почему бы и нет?
Процессоры давно умеют параллелить (многопоточность, векторизация), но…
• потоков у CPU - десятки
• векторы - это максимум 8-16 значений за раз
• а у нас миллионы независимых операций!

Тут в голову опять приходит вопрос: «А где вообще можно запустить десятки тысяч одинаковых вычислений одновременно?»

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

И вот в 2006 году инженеры NVIDIA спросили: «Почему бы не дать программистам доступ к этим вычислительным ядрам, причем не только для графики, но и для любых расчётов?»

Так появилась CUDA - технология, позволяющая писать программы, которые исполняются не на CPU, а на GPU.

Но почему GPU справляется с этим лучше? 🤔

Потому что он устроен по-другому. Вот ключевые отличия:

Ядра
• CPU: 8-32 мощных, универсальных ядра
• GPU: 1024-15360 простых ядер

Как обрабатываются данные
• CPU заточен под последовательность и ветвление
• GPU заточен под одинаковые операции над разными данными

Что оптимизировано
• CPU: Низкая задержка, высокая сложность логики
• GPU: Высокая пропускная способность, но ветвления дорогие(warp divergence)

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

Где эту технологию используют?🤔

Компьютерное зрение
• Детекция объектов (YOLO, SSD): ускорение ×5-×15
• Обработка изображений (фильтры, HDR, denoising)

Нейросети (ML/DL)
• Обучение: ускорение ×20-×100 (без GPU - невозможно)
• Инференс: в 10-100× быстрее CPU

Физические симуляции
• Расчёт частиц, жидкости, деформаций

Финансы / Наука
• Монте-Карло для оценки опционов: ×30-×70
• Свёртки в геномике, криптография (хэши, PoW)

Простейший пример: векторное сложение

На CPU (однопоточно)

// N = 10⁷ → ~25 мс на Ryzen 7
for (int i = 0; i < N; ++i) 
  c[i] = a[i] + b[i];

На GPU (CUDA)

// <<<N, 256>>>  запускаем N нитей по 256 в блоке
add_kernel<<<N/256, 256>>>(a, b, c);
// То же самое → ~0.4 мс на RTX 4070 → ×60 ускорение 

Всё параллельно. За один такт тысячи операций.

А что с памятью? 😕

Главное ограничение - это передача данных между CPU и GPU. Если ты шлёшь туда-сюда данные каждую итерацию, то ускорения не будет.

Главное правило: GPU любит жирные куски данных и долгие расчёты. Чем дольше он считает, тем меньше весит задержка копирования🤓

Вывод 🤓

CUDA ускоряет не код, а параллельные идеи. Если задача по своей природе параллельная, то жди прирост в несколько раз. Если последовательная или сильно ветвящаяся, то GPU простаивает, а копирование данных только замедлит выполнение. Инструмент мощный, но подходит не для всех задач.

Полезные материалы📖

Если заинтересовала эта технология, и ты хочешь выжать максимум производительности из своего железа или войти в число востребованных инженеров (HPC, ML, embedded, игры), то вот с чего можно начать:

• Бесплатный курс от freeCodeCamp (да-да, всего лишь 12 часов 😫)
• CUDA Toolkit Documentation - бесплатно, на английском, но очень структурировано
• Официальные примеры от NVIDEA на github'е

#SIMD #железо #оптимизации #Python #C_плюс_плюс

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

Но это не вся правда. Твой центральный процессор тоже умеет считать параллельно, не прибегая к видеокарте (вы цены на них видели?!🌟). И если ты не используешь эту возможность, твой код работает в лучшем случае на 10-20% от реальной мощности кристалла.

Сегодня разбираем SIMD (Single Instruction, Multiple Data).

Физика процесса: Как это работает в железе? 🐸

В классической архитектуре (SISD - Single Instruction, Single Data) процесс вычисления выглядит так:
1. Процессор загружает число А в регистр (сверхбыстрая память внутри ядра, обычно 64 бита, если твоя машина 64-битный процессор).
2. Загружает число B во второй регистр.
3. ALU (арифметико-логическое устройство) получает команду ADD, складывает их за 1 такт и кладет результат обратно в регистр.

В этом сценарии, даже если у тебя 64-битный процессор, а ты складываешь 32-битные float, половина регистра просто пустует, либо используется неэффективно.

Инженеры решили, что так не пойдет и расширили регистры 🤩
Так появились векторные регистры. Они имеют ширину 128, 256 или даже 512 бит.

SIMD (Single Instruction, Multiple Data) работает так:
Мы заполняем этот огромный 256-битный регистр сразу восемью числами float (по 32 бита). А затем ALU одной командой vaddps складывает их с другой восьмеркой чисел.
Итог: 8 операций сложения за тот же самый 1 такт процессора.

Зоопарк архитектур: Intel vs ARM 🌟

У разных производителей свой набор инструкций для этого:

x86 (Intel / AMD):
• SSE (128 бит): База. 4 числа за раз. Есть везде.
• AVX / AVX2 (256 бит): Стандарт для современного софта. 8 чисел float или 4 double.
• AVX-512 (512 бит): Тяжелая артиллерия (Xeon, современные i9). 16 операций за такт. Нюанс: при активном использовании процессор может снижать частоту, чтобы не перегреться.

ARM (Apple Silicon / Server ARM):
• NEON (128 бит): Есть во всех айфонах и макбуках. Аналог SSE/AVX.
• SVE (Scalable Vector Extension): Более умная технология. В Intel ширина вектора жестко прошита. В SVE код пишется "агностически" к длине регистра. Процессор сам решает: "Я маленький чип, считаю по 128 бит" или "Я суперкомпьютер, считаю по 2048 бит".

Уровень C++: Как управлять этим вручную 👨‍💻

Компиляторы (GCC/Clang) с флагом -O3 -march=native стараются сами найти циклы и превратить их в векторные инструкции (автовекторизация). Но они часто ошибаются.

Чтобы гарантировать скорость, используют интринсики (Intrinsics) (офигенное название, всегда нравилось) - псевдо-функции, которые транслируются прямо в инструкции CPU.

Пример на AVX2 (складываем пачками по 8 штук):

#include <immintrin.h> 

// Загружаем 256 бит данных в регистр
__m256 a_vec = _mm256_loadu_ps(arr_a); 
__m256 b_vec = _mm256_loadu_ps(arr_b);

// Одна команда для сложения 8 пар чисел
__m256 res = _mm256_add_ps(a_vec, b_vec);

P.S. В серьезном продакшене делают Runtime Dispatch: программа при запуске делает CPUID, видит, что AVX2 нет, и переключается на медленную ветку SSE, чтобы не крашнуться с Illegal Instruction.

Продолжение ⬇️

Уровень Python: Data Science и Web 🐔

Как мы знаем - писать на С++ бывает больно и все мы любим Python, но сам по себе он медленный.
Весь секрет скорости Python-библиотек в том, что они лишь пульт управления для SIMD-инструкций процессора.

1. NumPy (Математика)
Когда ты пишешь c = a + b для массивов, NumPy не запускает цикл. Он вызывает оптимизированный C-код (часто библиотеки BLAS/MKL), который использует AVX.
Как сломать: Написать списковое включение [x + y for x, y in zip(a, b)]. Это перенесет вычисления обратно в медленный Python (SISD) и убьет скорость в 50-100 раз.

2. Numba (JIT-компиляция)
Если логика сложная и NumPy не хватает, используй @njit из Numba. Это JIT-компилятор (Just-In-Time) на базе LLVM.
Он берет твою Python-функцию, анализирует байт-код и на лету компилирует её в машинный код, оптимизированный под инструкции именно твоего процессора.

from numba import njit, prange

@njit(parallel=True, fastmath=True)
def heavy_calc(a):
    # Numba сама развернет этот цикл в SIMD инструкции при компиляции
    for i in prange(len(a)):
         a[i] = np.sin(a[i]) * np.sqrt(a[i])

3. Simdjson / Orjson (Web & Backend)
В вебе узкое место парсинг JSON. Стандартная либа json читает посимвольно.
Библиотеки orjson или pysimdjson используют SIMD, чтобы загружать строку блоками и сравнивать сразу 32 символа на наличие скобок {} или запятых.

Пример использования в FastAPI/Django:
В высоконагруженных API замена одной строчки кода может снизить Latency на 20-30%.

import orjson # pip install orjson

# Вместо import json
def api_handler(data):
    # Скорость сериализации до 10-20 раз выше стандартной
    # Парсинг в 2-3 раза быстрее
    response = {
        "id": 123,
        "payload": [i for i in range(10000)],
        "history": "heavy_string_data" * 100
    }
    # orjson возвращает bytes, что тоже экономит время на кодировке
    return orjson.dumps(response)

Где спасает: Микросервисы, которые гоняют огромные JSON-ответы, логирующие системы, парсинг конфигов.

4. Базы данных и Векторный поиск
ClickHouse, Milvus, FAISS все они работают быстро, потому что хранят данные колонками (Columnar Storage). Когда данные лежат в памяти подряд, процессору легко загружать их в векторные регистры.

Вместо вывода 🤓:
SIMD это не про то, чтобы писать на ассемблере. Это про понимание того, как лежат твои данные.

- Векторные инструкции любят данные, которые лежат в памяти подряд плотным куском. Списки списков, объекты с кучей ссылок - это враги SIMD. Используй numpy.array, array.array, буферы bytes.

- Если обрабатываешь запросы, старайся собрать их в пачку (batch) и прогнать через матричную операцию, вместо того чтобы крутить цикл обработки по одному запросу.

- Правильные инструменты:
  * Для математики/ML: NumPy, PyTorch, JAX.
  * Для данных: Polars (вместо Pandas).
  * Для JSON: orjson.
  * Для своих узких мест: Numba или Cython.

- Полезные материалы📝

• Intel Intrinsics Guide - "Таблица Менделеева" для инструкций процессора.

• Numba: A 5 minute guide - Документация той самой библиотеки, которая заставляет Python летать. Читать разделы про @jit и параллелизацию.

• Блог Dan Lemire (автора simdjson) - Человек-легенда в мире перформанса. Пишет понятным английским про то, как парсить гигабайты JSON за секунды и обгонять стандартные библиотеки в 10 раз.

• Agner Fog's Software Optimization - Фундаментальные труды про микроархитектуру CPU. Если хочешь знать, почему одна команда выполняется 3 такта, а соседняя 100.

#Claude #инструменты #автоматизация

Начинаем серию небольших обзоров на интересные новые инструменты для жизни и работы 🔨

У Anthropic есть официальное расширение для Chrome. Заявляют, что это не просто чат-бот в боковой панели, который саммарит статьи, а аля это полноценный AI-агент, который получил доступ к вашему хрому: он умеет кликать, скроллить и печатать.

Вроде бы ничего такого, видели уже всякое. Но есть одна очень интересная штука. Киллер-фича - Record a workflow.
Вы что-то делаете в браузере, Claude запоминает порядок действий и потом может это повторить. Claude запоминает не координаты мыши (как скрипты автоматизации), а семантику действий, он имеет доступ к интерфейсу браузера (DOM-дереву), видит кнопки, поля ввода и может ими управлять.

Как попасть на вечеринку? ⌨️

Смотри прикрепленный pdf файл с инструкцией.

Как это работает: 🤩

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

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

1. Smoke Testing
Пишешь вайб код сайт. Вместо того чтобы писать тесты на Selenium/Playwright (еще бы их уметь) можно продолжить вайб код подход:
- Сценарий: Записываем путь: Логин -> Добавить товар в корзину -> Ввести промокод -> Проверить скидку. Называем "тест на скидку".
- Профит: Для тестирования просто говоришь: "Клод, прогони тест на скидку". Он пробегает по сайту визуально. Если верстка поехала - он скажет и если попросить сразу ее поправит.

2. Мониторинг цен
Парсинг WB/Ozon без написания парсеров и борьбы с API (а там реально сложно бывает).
- Сценарий: Показываешь ему, где на карточке товара лежит цена. Даешь список ссылок на конкурентов.
- Профит: Он проходит по списку, выдергивает цены и складывает в табличку.

3. Анализ инфополя
Когда лень читать 500 комментов под статьей на VC или Хабре.
- Сценарий: Открыть "Свежее", зайти в топ-3 статьи, открыть ветки комментариев, скопировать текст.
- Профит: Клод собирает "глас народа" и выдает сухую выжимку - за что ругают, за что хвалят, какой стек обсуждают.

Ограничения и подводные камни 🗿

Не спешите удалять Selenium, тут не все так гладко:
- Скорость: Он медленный. Очень. Реально думает перед каждым кликом. Это не скрипт, который делает 1000 запросов в секунду.
- Капча защита: Современные сайты агрессивно защищают себя капчами. Claude пока не умеет решать "Найди светофоры или переходы". Выход - дават ему доступ в активной сессии. Как по мне - это один из самых больших минусов.
- Лимиты: Не забываем - это жрет токены вашей подписки.
- Безопасность: Не давайте ему доступ к интернет-банку. Это все-таки бета, и выполнения сценария "перевести все средства в Anthropic", вместо "пришли чек" - сценарий маловероятный, но ненулевой.

Вместо вывода:

Это идеальный инструмент для задач категории "слишком сложно писать скрипт на Python, но слишком лень кликать руками". Это не по части стартапов или идей как заработать. Оно отлично для победы над рутиной. Но в будущем, когда допилят.

Попробовать стоит, если вы энтузиаст светлого будущего ИИ автоматизации и вам хочется соприкоснуться с ним. Но для полноценного использования слишком сырой, медленный и дорогой (но а что вы хотели от беты, ответит нам Anthropic, и будет прав).

#OpenClaw #AI #агенты #opensource #автоматизация

Листаю ленту и вижу интересное: народ массово скупает Mac Mini и арендует VPS. Не для разработки и даже не крипто-движуха. Все ради того, чтобы поселить у себя «УБИЙЦУ!!!» всех стартапов-оберток OpenClaw. За две недели проект набрал 100к звезд на GitHub.

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

Что это вообще такое? 🔨

Если коротко: это AI-агент, который живет на твоем сервере (или старом ноутбуке) 24/7. Он подключен к твоему Telegram (или Discord/Slack) и имеет доступ к shell-у хоста.

Ключевая фишка Conversation-first.
Забудь про YAML-конфиги и пайплайны. Ты просто пишешь боту в телеге: "Настрой веб-поиск, вот мой API-ключ" и он сам конфигурирует себя. Он не умирает, когда ты закрываешь крышку ноутбука (привет, Claude Code), он работает как демон и всегда онлайн.

Как это устроено 🔧

Внутри довольно красивая модульная история:
• Gateway: Вечный процесс, держит связь с мессенджерами.
• Pi (агент): Мозг, который получает задачу, формирует промпт, идет в LLM (можно подключить хоть ChatGpt, Claude, Gemini, хоть локальную Ollama), получает команды и исполняет их.
• Skills: Это то, что превращает его из чат-бота в работника. Хочешь работу с GitHub? Подключаешь skill. Хочешь управление умным домом? Есть skill. Они легко пишутся, как руками, так и сам бот умеет их создавать. А еще есть хаб от сообщества.
• Memory: Вот это что-то интересное. Вся память - это просто Markdown-файлы.
— SOUL.md: Характер бота (можно прописать хоть своего саркастичного кореша, чтобы он прислуживал тебе).
— USER.md: Факты о тебе («любит Python, ненавидит C++»).
— MEMORY.md: Долгосрочные заметки.
Перед каждым ответом агент читает эти файлы, поэтому он "помнит" контекст, даже если ты перезагрузил сервер.

Фича: Он пишет первым 🙈

Обычные боты отвечают только на запрос. OpenClaw умеет в Heartbeat.
Можно настроить чек-лист: «Каждое утро проверяй календарь и почту, если есть что-то срочное - пиши». Бот просыпается по крону, проверяет условия и, если нужно, инициирует диалог. Это реально меняет ощущение от взаимодействия.

Где подвох? (А он есть) 🗿

Давай поговорим об очевидном - это AI с доступом к shell. И ведь это все еще не настоящий AI, если ты хоть раз общался с чат ботами, то понимаешь, как часто они могут ошибаться:

1. Безопасность. Исследователи уже находят сотни открытых панелей Gateway, если кто-то перехватит управление у него root-доступ к вашей машине.
2. Деньги. Каждое действие, каждая проверка - это токены. Активное использование легко сжигает $70-100 в месяц. Поэтому лучше юзать подписку, а не оплату за токены, так если что просто лимит закончится, а не ты станешь нищим. Рассказал как в pdf.
3. Ghosting. Бот может залипнуть в бесконечном цикле, переписывая один и тот же файл, или просто уйти "подумать" на 5 минут.
4. Инициатива наказуема. Граница между «расскажи» и «сделай» размыта. Спросишь "как работает удаление файлов?" - он может пойти и показать на практике.

Вместо вывода 🦞

Я бы сказал так: OpenClaw - это все еще не тот ИИ агент, которого мы все ждём. Это просто еще один удобный инструмент: он мощный, гибкий, с кучей интересных архитектурных решений, которые просто даже интересно изучить. Завести из коробки базовую версию и начать что-то делать - проще простого.

Главный критерий, который стоит себе задать: "Могу ли я описать задачу в одном сообщении и не контролировать процесс?" Если да - это территория OpenClaw. Если нужно смотреть промежуточные результаты, корректировать, итерировать, то лучше берите Claude Code или другой your_favourite IDE-инструмент.

OpenClaw не для тебя, если хочешь "поставил и забыл", ищешь замену IDE для серьёзного кода, или ожидаешь, что AI будет думать за тебя (поскорее бы).

Для тех кто захочет повторить - прикрепил PDF с инструкцией по установке и короткой настройке.

🔗Ссылки:
• Моя статья на Хабр - там все тоже самое, только гораздо подробнее и с картинками.

#Хранилища #DataStorage

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

Секрет в иерархии. Современные системы строятся как пирамида из нескольких уровней. От кэша процессора с задержкой в один такт до ленточных архивов со сроком хранения 30+ лет. Каждый слой решает свою задачу: скорость, объём, долговечность или цена. И грамотное распределение данных между ними - это один из самых недооценённых рычагов оптимизации.

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

Уровень 1: Основная память

Включает в себя несколько компонентов:

- Кэш процессора (L1/L2/L3)

Самая быстрая память в системе. Расположена непосредственно на кристалле процессора.

• L1 - 32–64 КБ на ядро, доступ за 1 такт (менее 1 наносекунды)
• L2 - 256 КБ–1 МБ на ядро, задержка 3-10 тактов
• L3 - до 100+ МБ, общий для всех ядер, задержка 10-40 тактов

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

Факт: на архитектурах x86/x64 размер кэш-линии составляет 64 байта. При чтении одного байта соседние 63 байта загружаются автоматически, поэтому последовательный обход массива работает в разы быстрее произвольного доступа 🤓

- Оперативная память (RAM)

Волатильная память, теряющая данные при отключении питания.

• Задержка доступа: 50-100 наносекунд
• Типичные объёмы: от 8 ГБ в потребительских ПК до нескольких терабайт в серверах
• Энергозависима: требует постоянного питания для сохранения данных

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

Факт: приложения вроде Redis и Memcached используют оперативную память как основное хранилище именно ради предсказуемой низкой задержки - миллисекунды вместо десятков миллисекунд при работе с диском 😎

- Постоянная память (PMem / NVDIMM)

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

• Задержка: 100-300 наносекунд, медленнее оперативки, но в 1000 раз быстрее SSD
• Коммерческий пример: Intel Optane Persistent Memory (до 512 ГБ на модуль)
• Режимы: как расширение оперативки или как отдельное хранилище

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

Факт: хотя Intel прекратила производство линейки Optane в 2022 году, технология постоянной памяти продолжает развиваться - Samsung, SK Hynix и другие вендоры работают над подобными решениями 👍

Уровень 2: Локальное хранилище

Постоянные носители, подключённые напрямую к устройству.

• Жёсткий диск (HDD) - магнитные пластины внутри корпуса. Скорость 100–200 МБ/с. Дёшево за гигабайт, но медленно и чувствительно к ударам.
• SSD - флеш-память без движущихся частей. Скорость от 500 МБ/с до 7 ГБ/с. Быстро, надёжно, дороже за гигабайт.
• Карта памяти (SD) - миниатюрный флеш-накопитель. Используется в фотоаппаратах, телефонах, дронах 🤯
• USB-флешка - портативный накопитель для переноса файлов между устройствами.
• Оптический диск (CD/DVD) - данные записываются лазером на пластиковую пластину. До 128 ГБ на современных дисках. Подходит для архивов с долгим сроком хранения.
• Магнитная лента - данные записываются последовательно на ленту в кассете. Одна кассета хранит до 18 ТБ. Используется в крупных дата-центрах и научных организациях для архивирования петабайтов данных при минимальной стоимости.

Факт: ленточное хранилище до сих пор применяется в ЦЕРН для архивации данных Большого адронного коллайдера - это один из крупнейших архивов в мире на магнитных лентах.

Продолжение ⬇️

Уровень 3: Сетевое хранилище

Хранилище, доступное множеству серверов по локальной сети дата-центра.

• NAS (сетевой накопитель) - файловый доступ по протоколам NFS или SMB. Прост в настройке, подходит для совместной работы с файлами.
• SAN (сетевая система хранения) - предоставляет серверам быстрый блочный доступ к диску как к локальному. Используется для баз данных и виртуализации, где критична низкая задержка.
• Объектное хранилище - данные хранятся как объекты с уникальными идентификаторами и метаданными. Легко масштабируется до петабайтов.
• Распределённые файловые системы - единое файловое пространство поверх множества серверов. Примеры: Ceph, GlusterFS, HDFS. Данные автоматически реплицируются между узлами, обеспечивая отказоустойчивость и горизонтальное масштабирование без единой точки отказа.

Факт: распределённая файловая система HDFS, лежащая в основе экосистемы Hadoop, изначально была вдохновлена научной статьёй Google о своей внутренней файловой системе (GFS), опубликованной в 2003 году 😏

Уровень 4: Облачное хранилище

Хранилище, предоставляемое как услуга. Платёж зависит от объёма, частоты доступа и класса хранения.

• Блочное хранилище - предоставляет виртуальный диск для виртуальной машины. Примеры: AWS EBS, Azure Disks, Google Cloud Persistent Disks. Используется для баз данных, операционных систем, любых задач, требующих низкой задержки и возможности монтирования как локального диска.

• Объектное хранилище - данные хранятся как объекты с уникальными идентификаторами. Примеры: AWS S3, Azure Blob Storage, Google Cloud Storage. Масштабируется до экзабайтов, подходит для медиафайлов, бэкапов, логов. AWS S3 гарантирует долговечность 99.999999999% (11 девяток), то есть потеря объекта статистически возможна не чаще одного раза на 10 000 объектов за 10 миллионов лет.

• Файловое хранилище - сетевая файловая система с доступом по стандартным протоколам (NFS, SMB). Примеры: AWS EFS, Azure Files, Google Cloud Filestore. Позволяет множеству виртуальных машин одновременно монтировать один и тот же том, подходит для совместной работы приложений.

Факт: все три типа можно комбинировать в одной архитектуре. Например, виртуальная машина использует блочное хранилище для ОС, монтирует файловое хранилище для общих конфигов и записывает логи в объектное хранилище 🤹

Уровень 5: Облачные базы данных

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

• Реляционные базы данных - хранят данные в таблицах со строгой схемой, поддерживают транзакции ACID. Примеры: AWS RDS, Azure SQL Database, Google Cloud SQL, Postegre SQL. Подходят для финансовых систем, интернет-магазинов, приложений с требованиями к целостности данных.
• NoSQL базы данных - гибкая схема, горизонтальное масштабирование, оптимизация под конкретные паттерны доступа. Примеры: AWS DynamoDB (ключ-значение), Google Bigtable (колоночная), Azure Cosmos DB (мульти-модельная). Используются для высоконагруженных приложений, IoT, аналитики, социальных сетей.

Для чего:
• Реляционные - когда важна целостность данных и сложные запросы с JOIN'ами
• NoSQL - когда важна скорость, масштабируемость и гибкость схемы

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

Главный вывод

Умные системы не хранят всё в одном месте. Они распределяют данные по слоям:

• Горячие - в кэше и оперативке
• Тёплые - на быстрых дисках
• Холодные- в облаке или на лентах

А истинное мастерство заключается в балансе скорости, надёжности и цены 😎

Полезные материалы

• What Every Programmer Should Know About Memory
• Designing Data-Intensive Applications
• HDFS Architecture