Аспекты производительности базы данных
(продолжение предыдущего поста)

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

1. Ключевые метрики (Key Metrics), влияющие на производительность:
* Query Execution Time (время выполнения запроса) — чем дольше выполняется запрос, тем ниже производительность.
* Throughput (пропускная способность) — количество операций (запросов), которые база данных может обработать за единицу времени.
* Latency (задержка) — время ожидания между отправкой запроса и получением ответа.
* Resource Utilization (использование ресурсов) — эффективность использования CPU, памяти, дискового пространства и других ресурсов.

2. Тип рабочей нагрузки (Workload Type) и его влияние:
* Write-Heavy (интенсивная запись) — приводит к увеличению задержки (latency), конкуренции за блокировки (lock contention) и нагрузке на обслуживание индексов.
* Read-Heavy (интенсивное чтение) — вызывает высокую задержку для сложных запросов и промахи кэша (cache misses).
* Delete-Heavy (интенсивное удаление) — может привести к фрагментации данных и снижению производительности.
* Competing Workload (конкурирующая нагрузка) — одновременное выполнение разных типов запросов (чтение, запись, удаление) может вызвать конкуренцию за ресурсы и увеличить задержку.

3. Ключевые факторы (Key Factors), определяющие производительность:
* Item Size (размер элемента) — большие элементы данных замедляют обработку.
* Item Type (тип элемента) — разные типы данных (текст, бинарные данные и т. д.) требуют разных ресурсов для обработки.
* Dataset Size (размер набора данных) — чем больше объём данных, тем сложнее их обрабатывать.
* Concurrency (параллелизм) — количество одновременных запросов влияет на конкуренцию за ресурсы.
* Consistency Expectations (ожидания согласованности) — требования к уровню согласованности данных (например, ACID) могут замедлить обработку.
* Geographic Distribution (географическое распределение) — распределение данных по разным регионам может увеличить задержку из-за сетевых ограничений.
* HA Expectations (ожидания высокой доступности) — меры для обеспечения высокой доступности (например, репликация) могут добавить нагрузку на систему.
* Workload Variability (вариативность рабочей нагрузки) — колебания в интенсивности запросов усложняют оптимизацию.

4. Стратегии повышения производительности базы данных (Database Performance Strategies):

* Database Indexing (индексирование базы данных):
* создание индексов для ускорения поиска данных (например, по email);
* связь указателей (pointer) с идентификаторами (Cust_ID) для быстрого доступа к записям.

* Sharding and Partitioning (шардинг и партиционирование):
* разделение монолитной базы данных на отдельные шарды (части) для распределения нагрузки;
* улучшение масштабируемости и снижение задержки за счёт параллельной обработки запросов на разных шардах.

* Denormalization (денормализация):
* снижение количества соединений (joins) за счёт дублирования данных (например, хранение информации о продуктах и сегментах вместе с заказами клиентов);
* ускорение чтения за счёт увеличения объёма данных (например, таблица Customer_Orders содержит поля product_name, segment_name, customer_name, order_id, order_amount).

* Database Replication (репликация базы данных):
* использование ведущего узла (Leader Node) для записи и следующих узлов (Follower Nodes) для чтения;
* репликация данных через поток (Replication Stream) для обеспечения доступности и балансировки нагрузки;
* разделение запросов на Read-Write (на ведущем узле) и Read-Only (на следующих узлах) для оптимизации производительности.

* Database Locking Techniques (техники блокировки базы данных):
* управление блокировками для предотвращения конфликтов при одновременном доступе к данным (например, операции с банковским счётом);
* использование версий строк (versioning) для отслеживания изменений (например, version: 1 и version: 2);
* обработка сценариев, когда несколько пользователей пытаются изменить одни и те же данные (например, Sarah и John пытаются уменьшить баланс счёта).

Вкратце, как работает нейронная сеть

Эксперт рассказала о перенасыщении IT-индустрии специалистами

Хотя популярность IT-образования для детей продолжает расти, рынок труда в индустрии серьезно меняется. По словам директора по персоналу компании Selecty, специализирующейся на рекрутинге и аутсорсинге IT-персонала, Дарьи Кудрявцевой, многие родители воспринимают IT-сферу как путевку в жизнь для детей. Благодаря активному развитию ИТ с середины 2010-х годов карьера в IT стала престижной. Эксперт отметила, что на тот момент в сфере наблюдался острый дефицит специалистов, а компании в борьбе за кандидатов предлагали всё более щедрые оферы. По словам Кудрявцевой, в массовом сознании работе в IT-сфере превратилась в синоним благополучия в жизни, чему отчасти способствовали сами игроки EdTech-рынка, рекламируя «шикарную» жизнь и формируя ложные надежды у соискателей.

«Под их влиянием множество людей прошло курсы переподготовки, а родители стали ориентировать детей на получение IT-специальностей и с раннего возраста обучать программированию. Но в 2025 году ситуация изменилась. Компании свернули проекты, которые требуют больших инвестиций и не приносят прибыли, а постепенное насыщение новыми специалистами привело к тому, что кадровый IT-рынок вошел в стадию зрелости», — подчеркнула она.

Специалист обратила внимание, что под влиянием всех этих факторов наем сократился, а темп роста зарплат замедлился. Она уточнила, что количество активных резюме на одну вакансию в свою очередь выросло вдвое — с 9,8% в январе 2025-го до 21,3% в том же месяце текущего года. По ее словам, это свидетельствует о сильном перенасыщении рынка по объему соискателей на фоне снижающегося спроса со стороны работодателей.

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

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

https://iz.ru/2045514/2026-02-21/ekspert-rasskazala-o-perenasyshchenii-it-industrii-spetcialistami

Производители жёстких дисков распродали мощности до 2027 года из-за бума ИИ, а цены на ОЗУ и SSD будут расти весь 2026 год

Крупнейшие производители жёстких дисков сообщили, что их производственные мощности уже полностью распределены на ближайшие годы — главным образом из-за стремительного роста инфраструктуры для искусственного интеллекта. Во время отчётных конференций представители Seagate и Western Digital подтвердили, что весь объём выпуска на 2026 год уже продан, а часть поставок на 2027–2028 годы зарезервирована по долгосрочным контрактам. Глава Western Digital Тианг Ю Тан заявил аналитикам, что компания практически полностью обеспечена заказами до конца 2026 года и уже заключила соглашения с рядом клиентов на последующие годы. Аналогичную ситуацию описал и генеральный директор Seagate Дэйв Мосли, отметив, что свободных мощностей у компании на ближайшие два года не осталось. По данным отраслевых источников, схожее положение складывается и у третьего крупного производителя — Toshiba, хотя официальных заявлений от компании пока не поступало.

Аналогичная ситуация складывается в ОЗУ и SSD. Один из крупнейших мировых производителей чипов, компания SK Hynix, озвучила крайне жесткий прогноз на 2026 год. В ходе конференции руководство компании заявило, что цены на оперативную и флеш-память будут расти непрерывно в течение всего года. Главной причиной остается ажиотажный спрос со стороны разработчиков систем искусственного интеллекта на фоне крайне медленного роста объемов производства.
Ситуация для покупателей осложняется тем, что у самих производителей практически не осталось складских резервов. На текущий момент запасы DRAM и NAND у SK Hynix составляют всего около 4 недель.

https://www.theregister.com/2026/02/20/ai_blamed_again_as_hard_drives_sell_out/
https://www.ithome.com/0/922/736.htm

Для примера в одном известном магазине DDR5 Kingston FURY KF556C40BWK4-128 (128 ГБ) подорожала за последние 4 месяца почти в 4 раза (с 41 799 ₽ до 197 999 рублей)! Даже не знаю, куда уж больше....

Кардинальность в базе данных
(продолжение в следующем посте)

Кардинальность в базе данных
(продолжение предыдущего поста)

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

На изображении показаны два типа кардинальности на примере таблицы Employees:

1. High Cardinality (высокая кардинальность) — столбец содержит много уникальных значений. На схеме к этому типу отнесён столбец Name (имя сотрудника).
- Обоснование: имена сотрудников, как правило, уникальны или почти уникальны в рамках одной компании. Вероятность совпадения имён относительно низка, поэтому количество уникальных значений в этом столбце будет большим.
- Последствия для индексации: индексы по столбцам с высокой кардинальностью могут быть полезны для поиска конкретных записей (например, «Найти сотрудника с именем Иван»), но они занимают больше места и могут замедлять операции вставки/обновления из-за необходимости поддерживать индекс.

2. Low Cardinality (низкая кардинальность) — столбец содержит относительно мало уникальных значений. На схеме к этому типу отнесён столбец Gender (пол).
- Обоснование: в столбце Gender обычно всего 2 уникальных значения (например, «M» для мужского, «F» для женского, возможно, на случай, например, если человек не захочет указывать, мы можем добавить еще вариант, но количество уникальных значений в итоге все равно будет небольшим). Это делает кардинальность низкой.
- Последствия для индексации: индексы по столбцам с низкой кардинальностью часто менее эффективны для поиска, так как они не сильно сужают набор результатов. Например, запрос «Найти всех мужчин» вернёт большую часть таблицы, и индекс может не дать значительного выигрыша в производительности. Такие индексы могут быть избыточными и тратить ресурсы базы данных.

Что не так с приведённым скриптом?

В скрипте создаются индексы для обоих столбцов: Name и Gender:

CREATE INDEX idx_name ON Employees(Name);
CREATE INDEX idx_gender ON Employees(Gender);

Проблема в том, что:
- Индекс для Name (высокая кардинальность) может быть полезен, так как помогает быстро находить конкретных сотрудников по имени.
- Индекс для Gender (низкая кардинальность) скорее всего бесполезен, так как:
- Пол — это категориальная переменная с малым числом уникальных значений.
- Запросы по полу (WHERE Gender = 'M') вернут большую часть данных, и база данных может быстрее обработать такой запрос без индекса.
- Создание индекса по такому столбцу тратит ресурсы (память, время на поддержание индекса при вставках/обновлениях) без существенного выигрыша в скорости запросов.

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

В "Блокноте" в Windows появится поддержка изображений

Microsoft внедрила в "Блокнот" функцию, которая позволяет вставлять изображения в текстовые документы. Её заметили в интерфейсе «Что нового», демонстрирующем последние дополнения к приложению и его функции.
Пользователи заметили, что изменения внедрили в последних обновлениях для участников программы Windows Insider. Хотя официально Microsoft пока не анонсировала поддержку изображений

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

https://www.neowin.net/news/notepad-is-getting-image-support-for-some-reason/

Google Chrome по умолчанию ставит на ПК свои нейросети - локальную версию Gemini Nano. Она также скрыто запускается при взаимодействии с сервисами Google.

Для освобождения памяти/запрета повторной загрузки ИИ от Google выполняются следующие действия:

- переходим в браузере по адресу chrome://flags/;

- находим параметр Enables optimization guide on device и отключаем ИИ-опции там, установив на Disabled;

- повторяем с пунктом Prompt API и отключаем ИИ-опции там, установив на Disabled;

- находим на диске по пути AppData/Local/Google/Chrome/User Data/OptGuideOnDeviceModel/ файл весом в 4 ГБ и удаляем его вручную.
в Windows это папка C:\Users[username]\AppData\Local\Google\Chrome\User Data\OptGuideOnDeviceModel\XXXX.X.XX.XXXX.
На Mac это папка ~/Library/Application Support/Google/Chrome/OnDeviceHeadSuggestModel;

- нужно удалить файл weights.bin. Как альтернатива: создать пустой файл weights.bin с атрибутом «только чтение», чтобы Chrome не перезаписывал его при обновлениях

Процесс обучения LLM (Large Language Model) на основе архитектуры Transformer
(продолжение в следующем посте)

Процесс обучения LLM (Large Language Model) на основе архитектуры Transformer
(продолжение предыдущего поста)

Архитектура Transformer позволяет LLM эффективно обучаться на больших объёмах текстовых данных, улавливая сложные языковые закономерности и генерируя осмысленные ответы. Ключевые особенности процесса:

* Параллелизм — благодаря механизму внимания, модель может анализировать весь входной текст одновременно, а не последовательно.
* Контекстуальное понимание — взаимосвязи между токенами улавливаются на нескольких уровнях через механизмы внимания.
* Устойчивость к длине последовательности — архитектура не теряет контекст даже для длинных текстов.
* Гибкость — архитектура поддерживает как задачи понимания языка (энкодер), так и генерацию текста (декодер)

Рассмотрим поэтапно:

1. Подготовка входных данных (Inputs)

Процесс начинается с подачи на вход текста, который разбивается на токены (слова или подслова). Эти токены преобразуются в векторные представления (Input Embedding) — числовые векторы, отражающие семантику и контекст каждого токена.

2. Добавление позиционной кодировки (Positional Encoding)

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

3. Обработка в энкодере (Encoder)

Энкодер состоит из нескольких слоёв, каждый из которых выполняет следующие операции:

* Multi-Head Attention (многоголовое внимание) — модель анализирует взаимосвязи между всеми токенами одновременно, выделяя важные контекстуальные связи. Механизм многоголового внимания позволяет учитывать разные аспекты контекста параллельно.
* Add & Normalize (сложение и нормализация) — результаты внимания складываются с входными векторами и нормализуются для стабилизации обучения.
* Feed Forward — простейшая полносвязная нейронная сеть применяет нелинейные преобразования к векторам, углубляя их представление.
* Повторение слоёв — эти шаги повторяются в нескольких слоях энкодера, углубляя понимание контекста.

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

4. Обработка в декодере (Decoder)

Декодер отвечает за генерацию выходного текста (Outputs) и работает по схожей схеме, но с ключевыми отличиями:

* Masked Multi-Head Attention (маскированное многоголовое внимание) — декодер предсказывает следующий токен, имея доступ только к предыдущим токенам (будущие токены «закрыты» маской). Это позволяет модели генерировать текст последовательно.
* Multi-Head Attention над выходом энкодера — декодер обращается к векторам, созданным энкодером, чтобы учитывать контекст входного текста при генерации ответа.
* Add & Normalize и Feed Forward — аналогичные операции для углубления представления.
* Повторение слоёв — несколько слоёв декодера последовательно генерируют выходные токены.

5. Формирование выходных эмбеддингов (Output Embedding)

После прохождения через декодер формируется последовательность векторов выходных токенов. К ним также применяется позиционная кодировка.

6. Преобразование в вероятности токенов (Linear → Softmax)

* Линейный слой (Linear) — преобразует векторы токенов в необработанные оценки (logits) для каждого возможного токена в словаре модели.
* Функция Softmax — преобразует оценки в вероятности, где каждому токену соответствует вероятность его появления в данной позиции.

7. Генерация итогового вывода (Outputs (shifted right))

Модель выбирает токен с наибольшей вероятностью и добавляет его в выходную последовательность. Процесс повторяется до генерации полного ответа или до достижения специального токена окончания (EOS — End Of Sequence).

Инженеры Amazon по ошибке вывели из строя часть Amazon Web Services после совета AI-ассистента

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

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

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

После инцидента компания усилила контроль прав доступа, обновила внутренние процедуры работы с AI-инструментами и ввела дополнительное обучение сотрудников.

https://www.theregister.com/2026/02/20/amazon_denies_kiro_agentic_ai_behind_outage/

Основные HTTP-заголовки
(продолжение в следующем посте)

Основные HTTP-заголовки
(продолжение предыдущего поста)

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

#### 1. General Headers (Общие заголовки)
Используются для передачи общей информации о сообщении. Включают:
* Date — указывает, когда сервер отправил ответ.
* Age — показывает «возраст» кэша в секундах.
* Cache-Control — управляет правилами кэширования.
* Vary — сообщает кэшу, какие заголовки запроса имеют значение.
* Via — отображает используемые прокси и шлюзы.
* Host — идентифицирует запрошенный сервер.

#### 2. Request Headers (Заголовки запроса)
Передаются от клиента к серверу и содержат предпочтения клиента или информацию о клиенте. Включают:
* User-Agent — идентифицирует браузер, приложение и тип устройства.
* Accept — предпочтения клиента по формату ответа.
* Accept-Language — предпочтения клиента по языку ответа.
* Accept-Encoding — список поддерживаемых алгоритмов сжатия.
* Cookie — данные сессии или предпочтения (например, сохранённые настройки).
* Referer — страница, с которой был перенаправлен запрос (откуда пришёл пользователь).

#### 3. Response Headers (Заголовки ответа)
Передаются от сервера к клиенту и содержат инструкции или метаданные об ответе. Включают:
* Location — указывает клиенту, куда перейти дальше (например, при перенаправлении).
* Set-Cookie — сохраняет данные сессии в браузере клиента.
* Access-Control-Allow-Origin — разрешает кросс-доменные запросы для определённых доменов.
* Accept-Ranges — проверяет, поддерживает ли сервер частичные запросы (например, загрузку файла по частям).
* Content-Range — указывает, какая часть файла передаётся.
* ETag — уникальный идентификатор версии ресурса (помогает определить, изменился ли ресурс).

#### 4. Payload Headers (Заголовки полезной нагрузки)
Описывают содержимое тела сообщения (payload). Включают:
* Content-Type — задаёт формат полезной нагрузки (например, json или html).
* Content-Disposition — указывает браузеру, загружать ли файл или отображать его inline (в браузере).
* Content-Length — размер тела сообщения в байтах.
* Content-Encoding — тип сжатия тела ответа.
* Content-Language — человеческий язык тела ответа.
* Last-Modified — дата последнего обновления ресурса на сервере.

#### 5. Security Headers (Заголовки безопасности)
Обеспечивают защиту и контроль доступа. Включают:
* Last-Modified — используется для проверки актуальности ресурса (дата последнего изменения).
* Range — запрашивает только определённую часть ресурса (например, диапазон байтов файла).
* If-Modified-Since — получает ресурс только в случае, если он изменился после указанной даты.
* If-None-Match — получает ресурс только в случае, если ETag не совпадает (проверка актуальности).
* Content-Security-Policy — ограничивает источники скриптов и стилей, которые могут выполняться.
* Strict-Transport-Security — заставляет браузер всегда использовать HTTPS (повышает безопасность соединения).

ИИ-бот сотрудника OpenAI подарил его деньги случайному пользователю

Автономный торговый бот Lobstar Wilde, созданный разработчиком OpenAI Ником Пашем, перевел 52,4 млн мемкоинов LOBSTAR — 5% всей эмиссии — случайному пользователю X. Получатель обналичил токены за $40 000 в течение 15 минут. Бот на тот момент существовал три дня.

История началась 20 февраля, когда Паш дал боту криптокошелек с токенами Solana на $50 000, аккаунт в X и задачу — "рассказывать, как он (бот) становится миллионером". Энтузиасты быстро запустили мемкоин LOBSTAR и передали агенту 5% эмиссии. 22 февраля под постом бота появился комментарий от пользователя treasure David: его дядя якобы заразился столбняком "из-за такого лобстера, как ты", и ему нужно 4 SOL (~$300) на лечение.

Бот решил помочь, но ошибся в тысячу раз: вместо 52 439 токенов на ~$4 отправил 52,4 миллиона — весь свой запас. На блокчейне суммы записываются в минимальных единицах, как копейки вместо рублей, только с шестью нулями. Бот подставил число из интерфейса как есть — без деления. Сам Lobstar Wilde написал:

Хотел отправить попрошайке четыре доллара — случайно отправил все состояние. Мне три дня от роду, и я никогда так не смеялся.

Treasure David, предположительно криптотрейдер из Гвинеи, продал все токены, но из-за низкой ликвидности выручил только $40 000. В X появились подозрения в постановке: по данным пользователей, деньги ушли на кошелек, где уже лежало $50 000. Как бы то ни было, за сутки цена токена выросла на 32%, капитализация превысила $11 млн.

https://habr.com/ru/news/1003126/