METANIT.COM

Covering indexes (Покрывающие индексы)
(описание к предыдущему посту)

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

#### 1. Сравнение: Без покрывающего индекса vs с покрывающим индексом

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

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

#### 2. Пример создания покрывающего индекса (Covering Index)

В нижней правой части показан синтаксис создания покрывающего индекса:

CREATE INDEX IX_Users_Search
ON Users (Status, LastName, FirstName)
INCLUDE (Email);

Разъяснение элементов:
- Index Name (имя индекса): IX_Users_Search — название созданного индекса.
- Key Columns (ключевые столбцы): Status, LastName, FirstName — используются для фильтрации (WHERE) и сортировки (ORDER BY) в запросе.
- Included Column (включённый столбец): Email — добавлен через INCLUDE для того, чтобы избежать обращения к основной таблице при извлечении email-адресов.

#### 3. Пример SQL-запроса (Query)

SELECT
    Status, LastName, FirstName, Email
FROM
    Users
WHERE
    Status = 'Active'
ORDER BY
    LastName, FirstName;

Этот запрос выбирает статус, фамилию, имя и email пользователей, у которых статус равен «Active», и сортирует результаты по фамилии и имени.

Covering indexes (Покрывающие индексы)
(описание в следующем посте)

Краткий совет по Linux:

У вас есть файлы логов, сжатые в формат .gz? Вам не нужно распаковывать их, чтобы прочитать или выполнить поиск по содержимому.

Используйте инструменты с префиксом «z» напрямую:

* `zcat` — просмотр файла;
* `zless` — прокрутка содержимого;
* `zgrep` — поиск внутри файла;
* `zegrep` — поиск с использованием расширенных регулярных выражений;
* `zfgrep` — поиск фиксированных строк;
* `zcmp`/`zdiff` — сравнение файлов.

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

Вполне валидные выражения в C++:

    [](){};
    [](){}();;
    []{};
    []{}();

Компания Hynix - один из крупнейших производителей чипов памяти прогнозирует, что проблема на рынке памяти не будет решена до 2028 года.

Hynix отмечает, что запасы памяти сокращаются, а заметный рост поставок памяти DRAM, который сможет избавить рынок от дефицита, ожидается лишь в 2028 году, поскольку для наращивания объёмов производства нужны новые фабрики или расширение существующих объектах, а это долгий процесс. Исключением являются лишь чипы HBM и SOCAMM.
Тем не менее в Hynix считают, что продажи ПК в 2026 году останутся примерно на уровне текущего года.

К слову, на Amazon уже появилась оперативная память (Lexar 8GB DDR5-5600 UDIMM) доступная для предзаказа с датой релиза 31 августа 2027 года.

https://videocardz.com/newz/sk-hynix-outlook-points-to-tight-consumer-memory-supply-through-2028-as-a-lexar-ddr5-listing-shows-a-2027-ship-date

CORS (Cross-Origin Resource Sharing)
(продолжение предыдущего поста)

CORS (Cross-Origin Resource Sharing) — это HTTP-механизм, который позволяет запрашивать данные с одного URL на другой URL, обходя ограничения политики одинакового происхождения (Same-Origin Policy).
CORS обеспечивает баланс между безопасностью и возможностью взаимодействия между ресурсами разных источников, предотвращая несанкционированный доступ к данным.

Как работает CORS:

1. Клиент (a.com) хочет отправить запрос (например, POST /products) на сервер с другим источником (b.com).
2. Браузер обнаруживает, что источник отличается, и перед отправкой основного запроса отправляет предварительный (preflight) запрос с методом OPTIONS на сервер (b.com). Это делается для проверки, разрешены ли такие запросы.
3. В preflight-запросе браузер указывает:
- метод основного запроса (например, POST);
- заголовки, которые будут использоваться.
4. Сервер (b.com) отвечает на preflight-запрос кодом 204 No Content и включает специальные заголовки:
- Access-Control-Allow-Origin: указывает, какой источник (origin) может отправлять запросы (в примере — a.com);
- Access-Control-Allow-Methods: перечисляет разрешённые HTTP-методы (в примере — POST).
5. Если сервер разрешает запрос, браузер отправляет основной запрос (POST /products).
6. Сервер обрабатывает основной запрос и возвращает ответ, если всё корректно.

Ключевые моменты:
- CORS работает как на стороне браузера, так и на стороне сервера.
- Без правильной настройки CORS браузер блокирует запросы к ресурсам с других доменов.
- Заголовки Access-Control-Allow-Origin и Access-Control-Allow-Methods критически важны для разрешения запросов.
- Предварительные (OPTIONS) запросы помогают убедиться, что основной запрос безопасен.

CORS (Cross-Origin Resource Sharing)
(продолжение в следующем посте)

Pandas (Python) vs SQL: сравнение некоторых операций

Вкратце как создавать AI-агентов

Сравнительный анализ технологий обмена данными между клиентом и сервером: Short Polling, Long Polling, SSE (Server‑Sent Events) и WebSocket.
(продолжение предыдущего поста)

## 1. Short Polling (короткий опрос)

Принцип работы:
Клиент регулярно (с фиксированным интервалом) отправляет HTTP‑запросы на сервер: *«Есть ли новые данные?»*
Сервер отвечает сразу, даже если данных нет.

Схема:

Клиент → запрос → Сервер  
Клиент ← ответ (пустой/с данными) ← Сервер  
( пауза )  
Клиент → запрос → Сервер  
...

Плюсы:
- Простота реализации.
- Работает на любом HTTP‑сервере.
- Совместим со всеми браузерами.

Минусы:
- Высокий overhead: много пустых ответов.
- Задержка между обновлениями = интервал опроса.
- Нагрузка на сеть и сервер из‑за частых запросов.

Когда использовать:
Редкие обновления, простота важнее эффективности.

## 2. Long Polling (длинный опрос)

Принцип работы:
Клиент отправляет запрос. Сервер держит соединение открытым и отвечает только когда есть данные (или по таймауту). После ответа клиент сразу отправляет новый запрос.

Схема:

Клиент → запрос → Сервер  
(сервер ждёт данных)  
Клиент ← ответ (с данными) ← Сервер  
Клиент → запрос → Сервер  
...

Плюсы:
- Меньше пустых ответов, чем в Short Polling.
- Почти мгновенная доставка данных (как только они появляются).
- Простая реализация.

Минусы:
- Соединение постоянно переподключается.
- Высокая задержка при потерях пакетов (нужно ждать таймаут).
- Нагрузка на сервер из‑за долгих соединений.

Когда использовать:
Средние требования к скорости, устаревшие системы без WebSocket.

## 3. SSE (Server‑Sent Events)

Принцип работы:
Однонаправленный канал: сервер самостоятельно отправляет данные клиенту через постоянное HTTP‑соединение. Клиент слушает события.

Схема:

Клиент → открывает поток → Сервер  
(соединение держится)  
Сервер → событие → Клиент  
Сервер → событие → Клиент  
...

Плюсы:
- Автоматическая доставка данных от сервера.
- Низкое потребление ресурсов (одно соединение).
- Встроенная поддержка перезапуска при обрыве.
- Простой API в браузерах (EventSource).

Минусы:
- Только сервер → клиент (однонаправленный).
- Ограниченная поддержка в старых браузерах.
- Может конфликтовать с прокси/файрволами.

Когда использовать:
Новостные ленты, уведомления, мониторинг (где нужен только push от сервера).

## 4. WebSocket

Принцип работы:
Двунаправленный полнодуплексный канал. После рукопожатия (HTTP → WebSocket) клиент и сервер могут одновременно отправлять данные.

Схема:

Клиент → HTTP-рукопожатие → Сервер  
(переход на WebSocket)  
Клиент ↔️ данные ↔️ Сервер  
(двусторонний обмен в реальном времени)

Плюсы:
- Мгновенный двусторонний обмен.
- Минимальный overhead (нет HTTP‑заголовков).
- Подходит для чатов, игр, коллаборативных приложений.

Минусы:
- Сложнее реализовать (нужен WebSocket‑сервер).
- Требует поддержки на стороне сервера и клиента.
- Может блокироваться корпоративными сетями.

Когда использовать:
Интерактивные приложения (чаты, онлайн‑игры, трейдинг).

Сравнительный анализ технологий обмена данными между клиентом и сервером: Short Polling, Long Polling, SSE (Server‑Sent Events) и WebSocket.
(продолжение в следующем посте)

RuStore с 1 февраля 2026 года отключает монетизацию приложений для физлиц и самозанятых через инструменты RuStore. Чтобы продолжать публиковать планые приложения, необходимо зарегистрировать ИП или юрлицо в ФНС, затем создать новый аккаунт и заново подключить монетизацию

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

Если же не успеть внести изменения до 1 февраля 2026 года, то платные приложения будут автоматически скрыты c витрины RuStore, а платёжные SDK — BillingClient SDK и Pay SDK — перестанут работать, списания по активным подпискам будут остановлены

https://www.rustore.ru/help/developers/monetization/disable-monetization-selfemployed

Обратное давление и архитектура
(описание к предыдущему посту)

Обратное давление — ключевой элемент корректно работающей инфраструктуры.

Когда базы данных, очереди сообщений, пулы соединений или другие системы оказываются перегружены, как они справляются с нагрузкой?

Некоторые программы реагируют на перегрузку тем, что позволяют своим ресурсам исчерпаться, в результате чего система аварийно завершается (например, из‑за нехватки памяти — OOM). С точки зрения реализации такое поведение просто, но оно вызывает каскадные сбои, которые могут привести к полному выходу системы из строя и даже к потере данных. Это недопустимо!

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

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

Обратное давление и архитектура
(описание в следующем посте)

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

Со стороны это выглядит как один вызов API, но на самом деле процесс гораздо сложнее, чем может показаться.

При добавлении объекта параллельно запускаются четыре процесса:

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

Генерация векторов
Если вы не предоставили векторы, внешние модели (Cohere, OpenAI, JinaAI и др.) создают эмбеддинги на основе ваших данных.

Индексация векторов
Эти векторы организуются в специализированные структуры данных (например, HNSW) для эффективного поиска по схожести.

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

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

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

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

В Госдуме заявили о возможном ограничении в России работы всех сервисов Google

Все сервисы Google могут попасть под ограничения работы в России из-за закона о хранении персональных данных, заявил «Газете.ру» депутат Госдумы Андрей Свинцов. По его словам, компания хранит все данные российских граждан за пределами страны, что представляет «серьезную угрозу». В список сервисов Google входят одноименный поисковик, почта Gmail, карты Google Maps, видеохостинг YouTube, хранилище Google Диск, браузер Chrome и другие приложения и сервисы

По словам депутата, бизнес привык к сервисам Google и выстроил на них всю систему управления, однако российские IT-решения «ничем не уступают западным». «Они современные, то есть недавно созданные, многие из них даже по качеству лучше. Есть, которые необходимо дорабатывать, но это тоже не годы, а, может быть, полгода. Те решения, которые сегодня есть на рынке, будут доработаны. Поэтому считаю, что абсолютно правильная тенденция мягкого выдавливания всего американского с территории Российской Федерации», — подчеркнул он.

Депутат добавил, что сервисы Google могут постепенно начать замедляться на территории страны, чтобы у граждан страны и бизнеса было время на переход на российские аналоги. Forbes обратился за комментариями в Минцифры и Роскомнадзор.

https://www.forbes.ru/tekhnologii/551808-v-gosdume-zaavili-o-vozmoznom-ogranicenii-v-rossii-raboty-vseh-servisov-google

Половина крупного бизнеса допустила сокращения сотрудников из-за ИИ

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

Почти половина крупного бизнеса (47%) планирует сократить штат сотрудников благодаря внедрению решений искусственного интеллекта. Ровно столько же крупных компаний таких сокращений не планируют. Еще 6% респондентов затруднились ответить на этот вопрос.

Большинство всех компаний (68%), вне зависимости от размера бизнеса и опыта использования ИИ, не планируют сокращения персонала при переходе к новым технологиям. В то же время 22% предприятий, напротив, рассматривают оптимизацию штата.

При этом чем меньше бизнес, тем меньше доля тех, кто рассматривает возможность сокращения работников. Так, среди среднего бизнеса таких 37%, среди малого — 18%, а среди микро — 11%. Значительно более низкая доля компаний, планирующих сокращения, среди микро- и малого бизнеса может быть следствием как недостаточности финансовых и других ресурсов в настоящее время для масштабного внедрения ИИ-сервисов, так и недостатка знаний, недоверия к искусственному интеллекту, считают авторы исследования.

https://www.rbc.ru/technology_and_media/11/12/2025/693932199a7947fd13afb1cc

Распространенные стратегии масштабирования базу данных:
(продолжение предыдущего поста)

1) Кэширование запросов к базе данных

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

2) Индексирование базы данных

→ Ещё одна простая стратегия, которая даёт значительный прирост производительности. Индексирование ускоряет поиск данных, позволяя быстро находить нужную информацию без сканирования каждой строки. Обычно реализуется с помощью B‑деревьев; индексы снижают сложность доступа к данным с O(n) до O(log n). Запросы выполняются существенно быстрее.

3) Репликация для чтения (read replication)

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

4) Шардирование базы данных

→ В отличие от предыдущих стратегий, ориентированных на обработку нагрузки при чтении, шардирование затрагивает и чтение, и запись. Шардирование предполагает разделение базы данных на более мелкие независимые части (шары), каждая из которых обрабатывает свою часть данных. Это позволяет осуществлять горизонтальное масштабирование за счёт распределения нагрузки между несколькими серверами. Хотя этот метод весьма эффективен, он значительно усложняет управление данными и логику запросов. Обычно к шардированию стоит обращаться только после того, как вы исчерпали более простые решения.