Архитектура данных

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

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

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

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

При перезаписи партиции аналитического набора читатель видит смесь старых и новых файлов. Какой механизм публикации предотвращает частично обновлённое состояние?

Допустим, аналитический набор нельзя изменять задним числом, но в нём нужно исправить ошибочное значение. Как представить такую коррекцию в append-only модели?

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

CREATE TABLE orders (
  order_id BIGINT,
  customer_id BIGINT,
  amount DECIMAL(12, 2)
);

CREATE TABLE customers (
  customer_id BIGINT,
  segment VARCHAR(30)
);

INSERT INTO orders VALUES (101, 7, 250.00);

SELECT o.order_id, c.segment, o.amount
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id;

В потоковом хранилище данных за сутки образуются тысячи мелких файлов. Какой механизм уменьшит издержки их обработки?

После сбоя транзакционная СУБД подтверждила запись, но не успела перенести изменённые страницы таблиц на диск. Какой механизм позволяет восстановить подтверждённое состояние?

Требуется удалить персональные данные пользователя из append-only хранилища, не переписывая весь исторический поток. Какой архитектурный механизм может обеспечить такое удаление?

На таблицу заказов с высокой частотой вставок добавили несколько индексов для ускорения чтения. Как это изменение влияет на стоимость записи?

Система должна хранить данные с разной ценностью и сроком доступа. Как политика жизненного цикла данных может снизить стоимость хранения без потери требуемой доступности?

Сервис оформляет заказ через несколько автономных хранилищ. Как сага обеспечивает согласованность без общей транзакции?

Аналитическая витрина объединяет данные из двух источников с разной задержкой. Как определить, что результат ещё неполон, а не содержит реальные нулевые значения?

Объясните, за счёт какого механизма LSM-дерево часто эффективнее B-дерева при высокой доле последовательных вставок?

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

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

После записи в распределённое хранилище клиент должен сразу прочитать подтверждённое значение даже при отказе узла. Какой механизм согласования чтения и записи это обеспечивает?

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

Представьте распределённое аналитическое хранилище: запросы ищут редкие значения идентификатора, но данные физически разбросаны по блокам. Как вероятностный фильтр может сократить чтение?