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

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

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

В докладе мы расскажем, чем архитектурно отличается Postgres Query Optimizer (Planner) родом из 70-х от спроектированного в 90-е планировщика Orca. Мы также объясним, какие запросы Greenplum с Planner будет жевать на порядки дольше, чем запланированные Orca, и почему.
Мы поясним, где Planner не совсем cost-based, а где он всё же использует стоимостную модель, сравним его с Orca на кейсах с пробросом группировки и коррелированными подзапросами. Кроме того, мы коснёмся и конкретных случаев, где Planner всё же остаётся незаменимым.

Stateless Postgres Query Router (SPQR) — open-source решение для горизонтального масштабирования PostgreSQL через шардирование. Мы разрабатываем эту систему в Yandex Cloud, и это уже четвёртая итерация наших попыток построить масштабируемый PostgreSQL. До SPQR мы пробовали переиспользовать PostgreSQL FDW механизм, писали хуки в планнере запросов, реализовали прокси на чистом C — и в итоге пришли к SPQR, написанному на Go и работающему на уровне протокола PostgreSQL.

SPQR поддерживает шардирование как по диапазону значений, так и по хэшу. Система совместима не только с обычным текстовым протоколом PostgreSQL, но и с extended protocol — что позволяет использовать prepared statements и клиентские библиотеки без изменений. Роутер работает в сессионном и транзакционном режимах, в реальном времени определяет, на каком шарде нужно выполнить запрос, и управляет перемещением данных между ними.

В докладе мы расскажем:

- как построить масштабируемую OLTP-базу на PostgreSQL;
- какие архитектурные решения легли в основу SPQR;
- как мы добавляем новые шарды без решардинга;
- как устроен собственный SQL-лексер и почему мы отказались от pganalyze/pg_query_go;
- как реализовать PostgreSQL-прокси с поддержкой транзакций и extended protocol;
- какие проблемы возникают при построении таких систем: от оценки нагрузки на ключи до блокировок, перевоза данных и отказоустойчивости;
- будущее развития нашей системы.

Это доклад для разработчиков распределённых систем и тех, кто масштабирует PostgreSQL или только собирается это делать. Вы узнаете, что стоит за словами "Postgres-прокси" на практике — с примерами, болью и кодом.

Работа распределённой СУБД существенно зависит от шардирования данных. Когда данных много и они очень неоднородны — тысячи таблиц на сотнях машин — без фонового динамического перераспределения просто ничего не будет работать из-за постоянно возникающих неоднородностей, превышающих возможности отдельного шарда. Данную задачу можно разделить на две основные части: техническую реализацию перемещения шарда между нодами и алгоритмический процесс выбора шардов, которые нужно переместить. В докладе я сконцентрируюсь на второй части и расскажу, как мы решаем задачу планирования перераспределения шардов по нагрузке в динтаблицах YTsaurus — распределённом key-value сторадже, используемом для подготовки больших данных в Яндексе и выложенном в Open Source.

Федеративные SQL-запросы - запросы, адресованные внешним источникам данных. Они часто используются для оперативной аналитики разнородных данных и их миграции между различными хранилищами. Чтобы федеративные запросы летали, федеративные системы должны уметь быстро извлекать большие объёмы данных из внешних источников. Чтение данных в один поток - слишком медленное и неэффективное, особенно с учётом того, что федеративная система - обычно ещё и система распределённая. Чтение данных в несколько потоков по частям позволяет гораздо лучше утилизировать аппаратные ресурсы федеративной системы, однако ставит вопрос о согласованности данных: смогут ли читающие потоки видеть одно и то же состояние внешней таблицы?

Облачный сервис обработки аналитических запросов Yandex Query, построенный на основе YDB, является примером такой системы. Оптимизируя его пропускную способность, мы занялись задачей многопоточного чтения из внешних источников данных, и в этом докладе хотим поделиться накопленным опытом. Мы проведём сравнительный анализ API популярных реляционных СУБД (PostgreSQL, MySQL, Oracle, MS SQL Server, Greenplum, CocroachDB, YDB) с точки зрения возможностей многопоточного, консистентного и отказоустойчивого чтения, коснёмся темы MVCC - в классическом и распределённом варианте, а также погрузимся в технику разбиения массива данных на "сплиты" - элементарные единицы работы в системе массивно-параллельной обработки данных. А ещё в докладе будет много подробностей об устройстве федеративной YDB и сценариях её применения в Yandex Cloud.

Расскажу про нестандартный способ отмасштабировать (очень) большой кластер ClickHouse — используем репликацию и DELETE вместо INSERT INTO SELECT.

Мы расскажем об исследованиях форматов представления графа в DLH-инфраструктуре для различных аналитических сценариев.
Эффективный доступ к данным графа в S3 требует быстрый доступ как к точечным вершинам для поиска соседей, фильтрации меток и загрузки-выгрузки больших частей графа для аналитики. Стандартные форматы хранения в DLH не всегда эффективны в этих сценариях.
Подход от Alibaba в виде платформы GraphScope использует представление графа в формате GraphAr который решает предлагает решение проблемы доступа к данным за счет сочетания хранения семантики графа в слое метаданых, колоночного представления и набора методов оптимизации специфичных для Labeled Property Graph (CSR, дельта-кодирование, Page-alligned Collections и другие). Это позволяет не только эффективно хранить данные графа но и стать центральной частью экосистемы обработки графов в DLH.
В рамках исследования нашей командой была реализована поддержка формата GraphAr для DuckDB и проведены первичные замеры эффективности реализации основных сценариев аналитики на графе в сравнении с Iceberg, Hive и графовыми БД.
Расскажем про детали реализации и выводы о преимуществах и недостатках. Поделимся результатами проведенных бенчмарков на датасетах SNAP и LDBC и реальных графах большого размера, а также нашим опытом в работе с ними.

В докладе будет рассказано, как объединить подходы поколоночной обработки с использованием SIMD с JIT компиляцией для вычисления выражений в SQL движке.

Задача о многомерных ранцах или история про то как мы научили OpenSearch распределять данные в кластере так чтобы обеспечить и равномерное потребление диска и нагрузку на индексацию и на поиск

В условиях Data Mesh, где нет централизованной команды инженеров данных и аналитиков, поддержание качества кода в распределённой среде стало ключевым вызовом. За последние годы наша платформа данных прошла путь от ручного ревью изменений и частых хотфиксов до полностью автоматизированного CI/CD-пайплайна. Мы расскажем, как внедрили статические и интеграционные тесты для SQL-кода и автоматизировали контроль за выполнением пользователями стандартов разработки. Вы узнаете, какие инструменты и подходы помогли нам выявлять неоптимальный код, контролировать права доступа и поддерживать актуальность репозитория.

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

Apache Airflow — популярный инструмент для планирования и оркестрации задач. Несмотря на низкий порог входа, он требует базовых знаний Python, что может затруднять его использование аналитиками и увеличивать нагрузку на инженеров.
В докладе будет рассказано, как нам удалось сделать Airflow удобным не только для разработчиков, но и для аналитиков, переведя типовые сценарии в формат YAML-конфигураций. Вы узнаете:
· как перейти от ручного написания DAG к self-service автоматизации;
· как обеспечить масштабируемость, безопасность и управляемость решений;
· с какими техническими вызовами мы столкнулись при миграции мажорных версий;
· какой опыт эксплуатации был получен за 5 лет использования одного из внутренних решений.
Доклад будет интересен инженерам и аналитикам, которые хотят сделать оркестрацию процессов более доступной и управляемой.

Расскажу как переводили тяжёлую отчётность с модели импорта Power BI на прямые запросы DataLens + ClickHouse, рассмотрим какие проблемы пришлось решить.
После ухода Power BI столкнулись, что пока нет хороших решений, где можно просто загрузить данные в систему отчётности и отчёт будет работать на мощном облачном сервере более менее терпимо даже при объёме данный в миллиарды строк.
Доступные отечественные и свободные решения, в основном, строятся на прямых запросах, а это значит, что нужно самостоятельно заниматься задачами по оптимизации структуры данных, настройки кластеров и оптимизации запросов.
Сложности добавляло, что наша команда занимается проектами монетизации данных - отчётность предоставляется поставщикам и бюджеты на отчёты весьма ограничены, нет возможности использовать сверхмощные кластера. Требуется реализовывать отчётность в десятки миллиарды строк на скромных мощностях и чтобы данные обрабатывались за десятки секунд.
Мы начинали с Greenplum, но не устроила производительность, остановились на ClickHouse и выжимали оптимизацию из всего что можно, разбирались с движками, типами данных, кодеками, проекциями, индексами, стратегиями объединения данных, парализацией, схемами запросов, метриками производительности и прочим.
В итоге разобрались как настраивать ClickHouse для высокопроизводительной BI отчётности и готовы поделиться опытом.

Доклад описывает опыт решения проблем, возникших в рамках проекта миграции аналитического хранилища SAS, включая отсутствие информации о владении объектов, отключение неактуальных процессов, миграцию пользователей и данных, расхождение расчетов, соблюдение SLA, построение аналитики хода динамики миграции и многое другое

Структура доклада:
1. Приветствие
2. Знакомство
3. Адженда доклада
4. Что такое SAS?
5. Про проект миграции
7. С чего начать миграцию?
9. Отсутствие информации о владении объектов SAS
10. Cоблюдение ранее заключенных SLA на новом хранилище
11. Расхождение расчетов между SAS и Greenplum
12. Миграция пользователей 
на целевые системы
13. Резюме доклада
14. Секция Q&A

В Яндекс Go мы строим единую платформу обработки данных для нескольких бизнесов (Такси, Еда, Лавка, Доставка и др.), которая предоставляется нашему ключевому пользователю, инженеру данных, как решение "под ключ", как единое рабочее место (фреймворк и сервисы) для batch и streaming поставки и обработки данных.

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

Этот доклад может быть интересен практикующим инженерам данных, техлидам и архитекторам, руководителям DWH, а может даже и CTO.

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

В этом докладе мы представим WeSQL — облачную СУБД с открытым кодом и раздельными уровнями compute/storage, разработанную на основе MySQL для эффективной работы на S3. Мы расскажем о мотивации создания WeSQL, объясним, почему был выбран движок хранения на основе LSM-дерева, и как локальные диски вычислительных узлов используются совместно с S3.

Вы узнаете, как WeSQL достигает высокой экономической эффективности за счёт:

- разделения требований к задержкам и отказоустойчивости
- использования персистентного кеша
- гибридного row-column формата хранения.

Мы также поделимся планами по дальнейшему развитию WeSQL, а также продвижению и поддержке WeSQL в России.

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

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

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

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

В современных data-продуктах качество данных — это не разовые проверки, а непрерывный процесс.

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

Решения, которые будут затронуты:
✔ Базовая архитектура - с чего всё начинается
✔ Автоматизация рутины – чат-бот для алертов + автотикеты
✔ Проверка data-контрактов – как быстро внедрить автоматическую валидацию схем
✔ Реализация гибких триггеров проверок
✔ Детекция аномалий – от простых SQL-правил до ML для сложных кейсов
✔ Полный аудит ошибок – сохраняем проблемные данные + SQL-запросы для анализа
✔ Карантин – изоляция "битых" данных без потери информации
✔ Автогенерация DQ-проверок с помощью LLM – снижение ручного труда за счет автоматического создания SQL-правил и data-контрактов на основе описания данных и требований
✔ Обучение модели на исторических инцидентах для предложения превентивных проверок
✔ Поддержка естественного языка: аналитик описывает проблему → получает готовую DQ проверку

Технологии:
Триггеры (Airflow, DWH-интеграция)
Адаптивные пороги для алертов
LLM для генерации DQ-проверок, поддержка естественного языка
Дашборды мониторинга


Что узнаете:
→ Как за минимальный срок развернуть оптимальную DQ архитектуру
→ Каким образом снизить нагрузку на команду за счет умных алертов
→ Когда ML в DQ – это must have, а когда – overkill
→ Как внедрить систему, которая экономит 80% времени

Итог:
Data Quality больше не пожарные бригады — это встроенный иммунитет data-экосистемы. Покажу реальное работающее решение, как перейти от ручного контроля к системной надёжности.

Работа с дата каталогом – это всегда очень много ручного труда: описание, проставление владельцев и стюардов, тегирование и тд. Но мы заметили, что есть ситуации, когда мы проставляем некоторые атрибуты по понятным правилам. А если есть правила, значит можно автоматизировать. В докладе расскажу, что это за правила и как мы реализовали систему, в разы сократившую время на рутинную работу с каталогом.

Как подойти к Data Governance не как к локальной инициативе, а как к системной трансформации управления данными в крупной организации? В докладе разберём, как мы в Альфа-Банке шаг за шагом выстраиваем такую работу: от выбора подхода до оценки результатов.

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

Расскажу о пути длиною в год, как мы в компании пришли от идеи продукта Контрактов данных до его реализации и заезда поставщиков в него. Обсудим, какие проблемы мы хотели решить внедрением продукта, какие технологии были выбраны для создания и какая вышла архитектура в финальном варианте. Также, с другой стороны, рассмотрим проблемы внедрения продукта на большую аудиторию: реально ли это сделать в короткий срок?

В жизни каждого руководителя бывают моменты, когда зашел за метрикой не в ту дверь: получил значение, обещал перевыполнить план, но не знал о характере обновления дашборда и его фильтрах по умолчанию. Чтобы пользователи нашей платформы данных перестали попадать в подобные ситуации, мы разработали решение для поиска и фильтрации нужных показателей в BI на основе LLM-агентов.

В рамках данного доклада обсудим:
• преимущества и недостатки AI подхода
• основные сложности, с которыми мы столкнулись на этапе подготовки контента для AI-агента
• механизмы верификации AI-ready контента в BI

Мы — платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Коротко о нас:

— собираем более 6 млрд событий в день;
— собрано и накоплено 2,5 трлн событий к концу 1 квартала 2025 года;
— DAU — 200+, WAU — 400+, MAU — 700+ (активные пользователи за день, неделю, месяц соответственно);
— несколько BI (Metabase, Superset, Grafana).
Платформа содержит огромное количество данных. Основной BI инструмент — демократичный Metabase, и из-за демократии куча дашбордов в нем. Поиск и выбор достоверных показателей занимает порою очень много времени даже для опытного аналитика, не говоря уже о новых пользователях системы. Для решения этой задачи мы посмотрели в сторону решения на основе LLM-агентов и запросов в API BI системы.

Технологии:

Python — на нем написана основная функциональность AI-помощника.
Mattermost — корпоративный мессенджер, в котором агент будет работать.
GigaChat — в качестве LLM, которая поможет реализовать агентов.

Что такое CSI и зачем он Kubernetes.
Как устроена интеграция с разными типами хранилищ - через API и без него.
Наш опыт разработки драйвера csi-scsi-generic.
Подход к архитектуре драйвера, универсальность и расширяемость.
Проблемы, которые мы решали: resize, multipath, очистка устройств.

Вы можете сколько угодно обсуждать компьют и форматы хранения — но если вы строите Lakehouse, рано или поздно упрётесь в сторадж.
Мы прошли через это:
—спасали Lakehouse от тупика в трупуте,
—боролись с шумными соседями и деградацией IO,
—выжали 80 ГБ/с, обойдя ограничения одного кластера,
—и поняли, что архитектура Lakehouse начинается с правильного стораджа.
Этот доклад — честный отчёт о том, как выжить и масштабироваться, когда сторадж стал узким горлышком всей аналитической платформы.
Будет боль, будет правда, будут выводы.

В докладе будет рассказано о пути оптимизации процесса доставки данных для обучения моделей в Kubernetes.
Начиная с простой загрузки из S3, мы столкнулись с проблемой увеличения времени запуска задач обучения и решали её путем поэтапного развития.
Мы расскажем, как мы:

- Перешли от простой загрузки из S3 к кешированию на нодах с использованием Kubernetes CSI драйвера.
- Улучшили процесс, внедрив кеширование в кластерах с помощью NFS шар и K8S оператора, и какие ограничения мы встретили.
- Разработали и внедрили проектные хранилища с бекапом в S3, используя NFS Storage API, K8S оператор и CRUD сервис.

План доклада
1. Введение в проблему
- Начальные подходы: простая загрузка из S3 и их ограничения.
- Проблемы с большим временем запуска задач обучения.

2. Первый шаг: кеширование на нодах
- Реализация с помощью Kubernetes CSI драйвера.
- Проблемы с утилизацией ресурсов и наблюдаемостью.

3. Улучшение: кеширование в кластерах с NFS
- Реализация с помощью NFS шар и K8S оператора.
- Ограничения по объему и совместной работе.

4. Развитие: именованные хранилища с бекапом в S3
- Архитектура и реализация с использованием Storage API.
- Создание и управление NFS хранилищами с помощью K8S оператора и CRUD сервиса.

5. Практический опыт и результаты
- Как проектные хранилища изменили наш процесс: метрики эффективности.
- Примеры использования и совместной работы в командах.

Столкнувшись с задачей сбора Data Lineage из ETL/ELT процессов, основанных на Apache Spark и Apache Airflow, наша команда надеялась, что это будет довольно просто, и получится использовать какое-то из готовых Open Source решений - OpenMetadata, DataHub, Marquez и т.п. Все оказалось немного сложнее - сходу ни один инструмент нам не подошел, либо по функционалу, либо по производительности. В итоге мы начали разрабатывать собственное решение - сервис DataRentgen https://github.com/MobileTeleSystems/data-rentgen.
В докладе описывается путь к разработке инструмента длиною в полтора года - требования пользователей, RnD Open Source решений и их недостатки, немного метаний между разными технологиями сбора и хранения Lineage, и к чему мы в конечном итоге пришли. DataRentgen все еще в активной разработке, но уже собирает довольно много полезных данных.

- Pydantic v2 перенёс всю логику валидации в Rust-библиотеку pydantic-core через PyO3, что дало до 17× ускорения валидации моделей по сравнению с v1 .
- В PydanticCore используется SIMD-оптимизация целочисленного и строкового JSON-парсинга на AArch64 и fast-path для ASCII-строк (~15% прирост), а также перенос валидации enum-типов в Rust (~4× ускорение) .
- Кэширование и переиспользование CoreSchema для обобщённых типов снижает время старта FastAPI-приложений на 67% в сценариях интенсивного использования generics .
- Повторное использование экземпляров SchemaValidator и SchemaSerializer, а также ленивое вычисление аннотаций FieldInfo сокращает затраты памяти на 2–5× при большом числе вложенных моделей .
- В Pydantic v3 планируется убрать обвязку миграции из v1, добавить более богатый контекст ошибок (номер строки и столбца при JSON-валидации) и оптимизировать @validate_call, сохранив скорость v2

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

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

В докладе поделюсь проблемами, с которыми мы столкнулись до появления аналитического DWH-контура: разрозненные источники данных, сложность интеграции и отсутствие единой точки доступа. Расскажу, как мы видели решение этих проблем через построение централизованного хранилища и выбор подходящих инструментов, а также поделюсь итоговой архитектурой, которая позволила упростить миграции между инструментами и повысить гибкость аналитической инфраструктуры. Особое внимание уделю сервисам, которые мы внедрили для аналитиков, включая внутренний Data Portal, созданный практически полностью с помощью GPT человеком без опыта в веб-разработке, что значительно ускорило процесс и расширило возможности команды.

В современных Big Data экосистемах управление доступом к данным становится критически важным по мере роста кластеров и усложнения инфраструктуры. В докладе мы расскажем об особенностях организации доступа к большим данным, поделимся опытом Сбера в части эволюции системы авторизации больших данных: от изолированного Standalone-решения к облачной CloudNative архитектуре, способной масштабироваться вместе с бизнес-потребностями.
На примере реального кейса рассматривается путь модернизации механизмов, начиная с выбора подходящего решения, такого как Apache Ranger и его применения к BigData экосистеме, и заканчивая сложностями масштабирования и переносом сервиса в контейнерное окружение Kubernetes. Особое внимание уделяется проблемам сайзинга, возникающим при росте числа клиентов, и способам их решения с использованием технологий Service Mesh. В заключении обсуждаются ключевые аспекты, на которые стоит обратить внимание при миграции в облако и управлении высоконагруженными системами.
Ключевые показатели решения:
· снизили потребление компьютерных ресурсов в 2 раза, не снижая при этом уровень доступности сервиса;
· снизили T2M на 200%+ (с 1,5 часов до 8 сек.).

Расскажу как мы выстраивали управления данными вокруг InMemory хранилища, как мигрировали с одного MDM на другой и почему нельзя вот так просто использовать коробочные продукты управления мастер данными.