Вакансии в наши команды DBaaS (Database as a Service)

Я очень люблю распределенные системы, архитектуру, дизайн систем. А самое интересное в этом та часть, где хранится state или по простому базы данных. Причем базы данных бывают разные и сейчас у нас в компании активно разрабатывается продукты Database as a Service (пока Postgres и Cassandra). И если вы любите базы как я и еще умеете писать код на Python или Go, то вы можете присоединится к этой команды.

Вот как они сами описывают свой продукт
- Наша команда делает продукт для массового управления кластерами БД.
Но не просто систему получения кластера БД - мы глубоко интегрируемся с платформой разработки, платформой мониторинга и алертинга, платформой доставки данных, и т.д.
Это позволяет предоставить бесшовный опыт для большого количества пользовательских сценариев буквально по клику мышки и вызову одной команды.

А вот какие планы по развитию этих продуктов
Сейчас мы предлагаем пользователям кластера PostgreSQL и Cassandra, однако планируем расширять список поддерживаемых БД. Запускаемые нагрузки активно растут, сейчас это сотни команд и тысячи кластеров, однако ожидаем десять+ тысяч кластеров. Одним словом - огромное количество возможностей для развития и прокачки скиллов в условиях решения нетривиальных задач, с которыми сталкиваются только крупнейшие компании. Сейчас большинство БД работает на виртуальных машинах в приватном облаке, однако в ближайшее время мы планируем запускать наши БД на Baremetal K8s для улучшения производительности.

Вот стек и конкретные задачи, которыми можно будет заняться прямо сейчас
Пишем на Python и Golang, c упором на надежность кода и полное покрытие тестами. Сейчас есть много продуктовых и технических целей как в части подключения Change Data Capturing в PostgreSQL, реализации Disaster Recovery Plan, так и в части управления конфигурациями, инфраструктуры, K8s и разработки Control Plane. Наша команда самостоятельно проектирует, декомпозирует, прототипирует и реализует такие задачи.

Немного про условия
Трудоустройство возможно как в РФ, так и в странах СНГ с Центрами Разработки Тинькофф.

Если вам хочется заниматься такими задачами, то напишите мне в личку (@apolomodov) и дальше я пообщаюсь с вами и познакомлю с коллегами.

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

Материалы из Code of Architecture про базы данных и распределенные системы

В продолжении поста хочу поделиться материалами из клуба Code of Architecture
- Design Data-Intensive Applications (вот плейлист)
- Database Internals - (вот статьи с краткими саммари каждого выпуска: 1, 2, 3 и 4)
- Distributed Systems, 4th Edition (вот статья с ссылками на все выпуски и кратким саммари)
- Обсуждение white paper "Amazon Aurora" (статья с саммари)

Ради интереса я попросил модель Сбера "Кандинский 2.2" нарисовать картинку к посту по описанию "База данных как сервис с логотипами postgres и cassandra" в стиле kandinsky и получилось забавно:)

#Vacancy #Databases #SoftwareDevelopment #Engineering #Architecture #Architect

POSTGRES: The First Experience (POSTGRES: Первое знакомство)

Эта книга отлично подходит для начинающих знакомиться с популярной базой данных Postgres. Авторами книги являются Pavel Luzanov, Egor Rogov, Igor Levshin, причем Егор Рогов является еще и автором книги "PostgreSQL 15 изнутри", а про эту книгу я уже рассказывал. И хоть книга про внутрянку Postgres хороша, но она сложновата для старта, а сегодняшняя книга отлично для этого подходит. Она состоит всего из 175 страниц, что разделены на 12 глав, представленных ниже. Скачать книгу можно здесь: русская версия, английская версия

1. PostgreSQL — what is it all about? - рассказ про возникновение и развитие проекта postgres
2. What’s new in PostgreSQL 15 - changelog изменений в версии 15 по сравнению с 14 версией
3. Installation on Linux and Windows - простенькая инструкция про установку postgres, чтобы с ней можно было поиграться
4. Connecting to a server, writing SQL queries, and using transactions - пример работы с postgres через командную строку с выполнением DDL (Data Definition Language), DML (Data Manipulation Language), DCL (Data Control Language), TCL (Transaction Control Language) или по простому: create table, alter table, drop table, select, insert, delete, update, grant, revoke, begin/commit, rollback
5. Learning the SQL language on a demo database - демо на примере букинга отелей, покупки билетов, аэропортов и так далее. Эту демо-базу можно скачать и поиграть с запросами посложнее, включая функции агрегации, оконные функции, работу с массивами, рекурсивные запросы, а также работу с расширениями.
6. Using PostgreSQL with your application - глава с рассказом о том, как заводить пользователей для отдельных приложений. Дальше удаленными подключениями из программного кода (php, perl, python, java). Дальше идет рассказ о том как делать бекапы.
7. Minimal server setup - глава про настройки postgres и как они влияют на работу системы. Здесь на сцене появляются настройки: буфферов (shared_buffers), размера кеша (effective_cache_size), рабочей памяти (work_mem), настройки autovacuum, настройки костов для планировщика запросов (random_page_cost и seq_page_cost). Интересно, что в книге приводит настройка 1C.
8. About a useful pgAdmin application - глава про использование UI для конфигурирование postgres
9. Advanced features: full-text search, JSON format, foreign data wrappers - рассказ про дополнительные фичи, доступные в postgres, среди которых есть полнотекстовый поиск, который не сравнится с условным elastic, sphinx, но для части вещей подойдет. Другая крутая фича jsonb, которая позволяет использовать postgres как документо-ориентированную базу данных (залезая на террирторию MongoDB), причем мы можем индексировать поля внутри jsonb. Ну и финальная фича - это внешние интеграции через foreign-data wrapper.
10. Education and certification opportunities - здесь идет речь про обучение и сертификации, которые есть у компании Postgres Professionals и какие области они покрывают.
11. Keeping up with all updates - описание источников для получения дополнительной информации: mailing list, конференции
12. About the Postgres Professional company - описание компании Postgres Pro, вендора Postgres из России, в которой работают авторы этой книги

#Databases #DistributedSystems #Architecture #SoftwareArchitecture #Software

Designing A Data-Intensive Future: Expert Talk • Martin Kleppmann & Jesse Anderson • GOTO 2023

Это крутое интервью от топовых специалистов
- Мартина многие знают как автора классической книги с кабанчиком ("Designing Data-Intensive Applications"), сейчас он больше исследователь и занимается так называемым "Local-First Collaboration Software" (automerge) - подробнее можно посмотреть в выступлении Мартина, которое я разбирал месяц назад
- Jesse я узнал в качестве автора книги "Data Teams", а также автора интересного выступления "Why Most Data Projects Fail and How to Avoid It", про который я рассказывал 2 месяца назад
Оба участника превосходно шарят в теме разговора и их интересно слушать. Вот тут доступна расшифровка.

Ниже тезисно расскажу основные мысли
Мартин рассказывает про свою книгу "DDIA", котороя про основы работы с данными и широкий ландшафт технологических решений (на момент 10 лет назад, когда Мартин начинал писать книгу)
Мартин планирует написать второе издание книги, в котором он рассмотрим вопросы
- Рост популярности cloud-native приложений и разработку распределенных приложений слоями, когда одна распределенная система опирается на нижележащую распределенную систему и так далее - рекомендую про это подробнее прочитать в whitepaper от ребят из Google "Deployment Archetypes for Cloud Applications", про которую я рассказывал раньше
- Закат Map-Reduce, чью поляну забрали cloud DWH с точки зрения аналитики и стриминговые системы с точки зрения приложений с кастомной логикой
Мне нравится, что Мартин продолжить и во второй книге использовать подход

So I'm not telling people what to do, I'm telling people what questions to ask.

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

For example, you could run both consumers side by side for an amount of time, check the consistency across the two systems, and then eventually decide to switch over from the old one to the new one. Streaming systems allow that so much better than, for example, systems based on, like, doing calls to individual services. So I feel like, as you said, the streaming can help with making change easier there.

Дальше Мартин вспоминает свое бытие в стартапах и говорит, что для них часто важно пытаться сделать вещи максимально просто, потому что они всегда в сложных условиях нехватки времени, людей, ресурсов. А также все очень быстро меняется и надо быть готовым к этим изменениям, поэтому использование Kafka в качестве стриминг платформы в стартапе может быть полезно.

Дальше Мартин вспоминает про automerge, что я упоминал в начале и потом переходит на тему работы ученым и почему он переключился после 10 лет пребывания в стартапах на стезю ученого и как это позволяет ему лучше продумывать сложные идеи в области distributed systems. А также почему так мало PhD диссертаций превращаются в рабочие системы (значимое исключение Apache Flink).

Ну и напоследок участники дают советы
- Мартин: "I guess my recommendation would be to learn just enough about the internals of the systems that you're using so that you have a reasonably accurate mental model of what's going on there."
- Jesse: "There are a lot of paths out there. Pit's to look out the various paths, look at what you want to do and what your skills are and see if one of those applies to you", где приведены карьерные варианты: разработка, менеджмент, наука, консалтинг, devrel. И в зависимости от сильных сторон и предпочтений, стоит выбрать свой путь.

#Management #Data #Databases #SystemEngineering #DistributedSystems #Software #Architecture

How Data & Software Eng. Teams Collaborate to Ensure Smooth Data Integrations • Sam Bail • GOTO 2023

Интересное выступление Sam Bail про коллаборацию команд, что отвечают за разработку софта и за аналитические данные:) Слайды этого выступления доступны здесь.

Сетап проблемы выглядит так

Product manager: We’re launching this awesome new feature next month! And we need analytics from day 1! Let’s GOOO!
Data team: HOLD ON! Lemme talk to the software engineering team first and see what their data architecture looks like…

А дальше доклад посвящен следующим темам и выстроен в виде важных вопросов, которые обычно задает Sam в очередном проекте
1. Logistics - нужны доки, нужны встречи и понятная зона ответственности, понятные коммуникации, ответы на вопросы: что мы планируем измерять и когда (уже в первый день, неделю, месяц, ...). Как сделать так, что команда разработки была в синке с аналитикой.
2. Infrastructure - где хостятся данные, какой там тип хранилища, могут наши ETL инструменты с этим справиться, нужен ли SSH туннель. Есть ли prod и dev инстансы, мы используем реплики для получения данных? Нужен ли нам доступ на запись? Что мы делаем с credentials (личные они или общие, как мы их шарим). Когда удастся получить доступ к данным? На dev или prod?
3. Data model - как выглядит схема данных, есть ли документация, кто поддерживает изменения в схеме и кто и как их коммуницирует? Как будет выглядеть data constraints enforcing (foreign key relationship, NULL values, default values, JSON schemas)? Как обрабатываются таймзоны в датах, валюты? Действительно ли мы сохраняем все, что хотим измерять?
4. Application and data flow - как и когда записи создаются и поля заполняются значениями? Какие действия вызывают модификации значений? Как события модификаций данных логируются (поле updated_at или отдельная таблица с событиями логирования)? Как будут обработаны удаления (hard или soft удаления)? Архивируются ли "старые" данные? Нужна ли миграция данных из старого приложения? Будут ли реалистичные тестовые данные, на которых можно будет разрабатывать? Будут ли тестовые данные в production среде?
5. Data contracts - как будут документированы договоренности из пунктов 1-4? И как мы будем обеспечивать их соблюдение в будущем не требуя слишком большого человеческого участия? Что из этого можно вынести в CI/CD и проверять на стороне производителе данных (а не как обычно на стороне потребителя)? Как нужно будет коммуницировать об изменениях и кого надо будет информировать об этом? Что делать, если что-то сломается? Как надо будет репортить о проблемах, а также какое SLA будет на фиксы?

Автор обобщает весь доклад тремя пунктами

- Integrating data from a new source into your data warehouse isn’t just “plug n play”
- There are an infinite number of questions to consider. You will probably miss something.
- The key is connection and context between teams.

А дальше, если все сделать правильно, то проблема из самого начала превращается в

Product manager: Look at this awesome new feature! And the dashboard to track all these cool metrics!
Data team: Well it’s not everything you asked and it was a bit bumpy getting there, but it works! Go team!

#Data #Software #SoftwareDevelopment #Engineering #Management #Leadership #Databases

AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

Продолжая вчерашнюю тему про модели консистентности, рекомендую посмотреть интересное выступление от ребят из AWS про значимый апгрейд их базы данных Aurora, которую мы как-то обсуждали в бонусном выпуске "Code of Architecture" и по которой есть whitepaper от 2017 года. Сейчас ребята добавили возможности масштабирования к этой базе данных. Причем тут фокус был на масштабировании write нагрузки, так как с read нагрузкой у этой базы уже было все хорошо. Если кратко описывать изменения, то смысл примерно такой

1) Добавляется семантика шардирования внутри самого Aurora - для этого у пользователей появляется возможности
- Пометить таблицы как шардированные и указать ключ шардирования - если транзакции попадают на один шард, то это максимально быстро, если нет, то используются распределенные транзакции двухфазный коммит. Для шардирования используется hash-range partitioning.
- Пометить часть таблиц как reference - такие таблички используются как справочники и они разложены на каждом шарде (их стоит использовать, если write нагрузки на эти таблички небольшие)
2) Шардированная база поддерживается семантику вида read commited и repetable read
3) Эта семантика работает внутри кластера Aurora, поэтому общие штуки типа дампа или point-in-time recovery работают как ожидается от кластера без шардов
4) Под капотом все это работает за счет добавление концепции shard group внутри aurora cluster, где есть роутеры для распределенных транзакций (здесь координируются распределенные транзакции и собирается общий результат) и шардов для доступа к данным (здесь выполняются локальные части запросов, работает локальный планировщик, используются индексы и так далее). Здесь тоже появляется дополнительный параметр compute redundancy, который позволяет compute частям шардов лучше переживать отказы
5) Для реализации repetable read ребята используют концепцию bounded clocks, которая похожа на концепт TrueTime из Spanner. Смысл этой концепции в том, чтобы использовать метки времени с разных устройств для упорядочивания транзакций. Проблема в том, что часы на разных машинка время может чуток отклоняться, поэтому приложению нужно несколько параметров: current time (approximate), earliest possible time, latest possible time. А дальше приложение должно подождать немного для того, чтобы точно не выставить транзакции метку времени из прошлого (иначе это может нарушить порядок транзакций в кластере). Эти параметры приложение получает из сервиса EC2 TimeSync с точностью порядка микросекунд. В самой презентации рассказывается как это работает для локальных и распределенных транзакций, а также для выполнения запросов с агрегатами.
6) В конце доклада авторы рассказывают про то, как взаимодействуют роутеры и шарды, а также как померить эффективность запросов, какие запросы получают максимальные бенефиты от параллелизации выполнения запросов на разных шардах (создание индексов, вакуум, агрегаты)
7) Пока эта limitless версия Aurora доступна через заявку на превью

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

#Software #Architecture #DistributedSystems #SystemDesign #Engineering #Databases

The 12 Factor App for Data • James Bowkett • GOTO 2023

Интересное выступление James Bowkett на тему хороших подходов для работы с данными. В названии он делает отсылку к 12 факторам, которые в свое время сформулировали ребята из Heroku и которые стали предвестником подходов cloud native приложений. James предлагает 12 факторов, которые помогут сделать более качественным пайплайн работы с данными, которые часто называют сейчас big data и используют для обучения ML моделей:) Мне принципы Джеймса понравились, а особенно понравилось то, как он их структурировал

-> Architecture & Design - факторы, относящиеся к проектированию решений
1. Data structures as code - универсальный совет не полагаться на UI, а конфигурировать настройки для управления данными через код. Это стандартный совет в духе IaC (infrastructure as a code), GitOps и так далее.
2. Append-only data structures - использование таких структур данных добавляет историчность и позволяет time travel.
3. Optimise for access and retrieval - автор рекомендует не делать кладбище данных (data graveyard), а думать про то, как денормализовать данные так, чтобы их было удобно использовать
4. Separate data from logic - автор предостерегает от использования протекающих абстракций (leaky abstraction), навроде магических значений, которые требуют специальной обработки на стороне потребителя. Это приводит к запутанности в данных, а также куче дополнительной лапши в коде у потребителей
5. Strongly type your data columns - автор призывает думать про типы данных и использовать их. Это позволяет получать более качественные данные в хранилище + сами движки хранения эффективнее работают если нам не нужно непрерывно кастовать данные между типами (что, кстати, тоже является протекающей абстракцией)
-> Quality & Validation - факторы, относящиеся к качеству данных и валидации
6. Architect for regression testability - наше решение должно быть спроектировано с учетом потребности в регрессионном тестировании отгружаемых данных, что является пререквизитом для CD (continuous delivery)
7. Track changes in your test data - автор рекомендуют хранить лог изменений, который применялись к тестовым данным, а также применять их консистентно между средами
-> Audit & Explainability
8. Mind your metadata: Data-Cataloguing - автор рассказывает про каталогизирование данных, что позволяет управлять метаданными. Мельком он упоминает OpenMetadata и Apache Atlas
9. Mind your metadata: Code Traceability - автор рекомендует организовать трассировку от данных к коду, системам, людям, которые их сгенерировали. Это позволяет понять происхождение данных, что может быть полезно при траблшутинге и не только
-> Consumption
10. Defined APIs for accessing data - автор рекомендует специфицировать API, отделить внутреннюю модель данных от внешней и никогда-никогда не открывать доступ к вашему внутреннему хранилищу (избегайте интергаций через шаренную базу данных)
11. Defined SLAs (& SLOs) for data - у API должен быть определен уровень обслуживания и ожидания для потребителей
12. Treat data as a product - данные надо воспринимать как продукт. А дальше стоит думать про потребителей продукта, их потребности, сценарии использования, ... В итоге данные начинают работать и организация становится data-driven.

#Data #DataOps #Databases #Software #Engineering #Management #Processes #Devops

Amazon Aurora DSQL (Рубрика #Data)

Вернер Вогель, CTO Amazon, в своем keynote на re:Invent 2024 полчаса рассказывал про новые возможности базы Aurora, которая появилась порядка 10 лет назад, а теперь перещла в класс newSQL и стала по фичам напоминать Google Spanner, который как раз появился больше 10 лет назад. Вот какие фичи выделял Вернер
1) Serverless Architecture - для автоматического масштабирования под нужные нагрузки
2) High Availability - для одного региона 99.99% availability, для мультирегионального master-master сетапа 99.999%
3) PostgreSQL Compatibility - полная подддержка PostgreSQL
4) Performance - обещают 4х скорость по сравнению с другими похожими решениями, видимо, из мира newSQL. Я бы глянул на бенчмарки, чтобы понять с кем они сравнивались:)
5) Active-Active Multi-Region Operations - собственно, мультирегиональный вариант, который может принимать записи и реплицировать их в реальном времени (интересно глянуть насколько это быстро работает в мультирегиональном исполнении)
6) Zero Infrastructure Management - пользователям не надо думать об инфре (кроме как сколько это счастье будет стоить)
7) Innovative Transaction Processing - здесь Вернер пафосно рассказыва про аналог гуглового TrueTime, что был еще 10+ лет назад в Google Spanner. Теперь у Amazon есть свои спутники и атомные часы для микросекундной точности и все это называется Amazon Time Sync Service. Это и позволяет сделать распределенные транзакции с хорошими гарантиями консистентности:)

P.S.
Про Aurora я уже часто упоминал раньше
- Бонусный выпуск Code of Architecture по white paper "Amazon Aurora: Design Considerations for High Troughput cloud-Native Relational Databases"
- AWS re:Invent 2023 - [LAUNCH] Achieving scale with Amazon Aurora Limitless Database (DAT344)

#Databases #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Cloud #Management #Leadership

Research Insights Made Simple #14 Review of"What goes around comes around ... and around" (Рубрика #Databases)

Этот выпуск посвящен обсуждению whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили половину статьи, успев разобрать общее впечатление от статьи и часть про модели данных и языки запросов. В итоге, получились следующие темы
- Введение и знакомство с гостей
- Общий обзор статьи
- Отличия российского и мирового контекста развития БД
- Обсуждение авторов статьи и их влияния на индустрию (Майкла Стоунбрейкера и Эндрю Павло)
- Эволюция моделей данных и языков запросов
- MapReduce (аля Hadoop и почему они уже leagcy)
- Системы KV и их ограничения
- Документно-ориентированные базы данных (MongoDB)
- Wide Column Family и Apache Cassandra
- Полнотекстовый поиск - Elasticsearch и встроенные возможности в RDBMS
- Векторные базы данных и семантический поиск
- Многомерные данные и array databases
- Графовые базы данных
- Заключение и анонс следующей темы

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Вакансия java разработчика в a/b платформу (Рубрика #Vacancy)

Что-то в последнее время я пишу только про позиции engineering менеджеров, но нам в компании требуются не только руко водители, но и крутые инженеры на сложные задачи. Сегодня я хотел рассказать про позицию java разработчика в a/b платформу в команду, что делает движок для обсчета всех метрик по экспериментам для всей компании. Круто, если этот инженер будет уровня senior и дополнительным плюсом будет глубокое знание Apache Spark.

Если говорить про a/b платформу, то это действительно важный для всей компании проект, который несет под себе инженерную сложность (про нее расскажу подробнее). Если говорить про a/b тесты, то есть классическая книга Рона Кохави "Доверительное a/b тестирование", про которую я рассказывал раньше. Если же говорить про историю a/b платформы, то она была у нас давно, но раньше их было много и они кусочно покрывали разные уровни тестов - когда я приходил в компанию порядка 9 лет назад, то уже тогда был прототип платформы DCO, которую мы с тех пор раскачали и использовали для экспериментов в вебе и мобильных приложениях. Пару лет назад мы решили закопать DCO и сделать новую платформу Hippo (я как-то показывал ее потенциальный логотип).

С тех пор платформа сильно выросла и научилась многому, но пришло время масштабировать ее на всю компанию и для этого надо сделать многое по расчету метрик, которые прошли следующий путь
- Все аналитики из продуктов считают метрики по экспериментам в своих python ноутбуках (легко ошибиться или получить результат, пытая данные под разными углами)
- Лаборатория экспериментальной статистики написала свои алгоритмы обсчета метрик для a/b экспериментов на таких же лабах, но для ограниченного набора метрик
- Инженерная команда metric store забрала эти python ноутбуки и перевела на Apache Airflow, где расчеты велись поверх Greenplum, где MPP база была нашим основным хранилищем данных для аналитических вычислений
- Инженерная команда metric store перевезла расчет этих метрик на новую архитектуру, где метрики считаются с помощью Apache Spark, а данные лежат уже внутри нашего Data LakeHouse (DLH)

По-факту, наша датаплатформа мигрировала на подход с DLH, который мы как-то разбирали с Колей Головым в подкасте Research Insights. Кстати, в ближайшее время будет серия подкаста с разбором того, как мы это делали с техническим директором датаплатформы. Плюс про a/b платформу тоже будет отдельный эпизод подкаста, где мы поговорим про то, что это такое, насколько она важна и сложна. Но если вы хотели решать сложные технические задачи уже сейчас, то можете писать мне в личку и мы обсудим варианты.

P.S.
Кстати, у меня уже есть эпизоды
- С руководителем этого отдела Андреем Цыбиным, где мы говорили про соседний продукт Statist (продуктовая аналитика)
- С лидом бекенда этого продукта Женей Козловым, где мы говорили как про бекенд Statist, так и в общем про инженерный подход к разработке

#Engineering #Software #Career #Vacancy #Databases #Fintech

Research Insights Made Simple #15 Review of"What goes around comes around ... and around" - Part II (Рубрика #Databases)

Этот выпуск продолжает обсуждение whitepaper "What goes around comes around ... and around" от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Здесь мы поговорили о том, как менялись архитектуры баз данных и почему, а также обсудили выводы авторов исследования о будущем баз данных. Разбору статьи помогает мне Алексей Светличный, мой коллега, что руководит развитием отдела баз данных в Т-Банке. Алексей работает с базами данных более 15 лет, где он прошел путь от небольших систем, до крупных Enterprise решений. Сейчас руководит командой, которая разрабатывает DBaaS и развивает экспертизу по базам данных в компании.

За час общения с Лешей мы обсудили вторую половину статьи, куда входили следующие темы

- Введение и план обсудить эволюцию архитектур баз данных за 20 лет.
- Развитие архитектур реляционных и колоночных БД
- Появление и развитие облачных БД с разделением хранения и вычислений (масштабирование ресурсов, эластичность вычислений, объектное хранилище)
- Прорывы в OLTP-масштабировании (пример AWS Aurora)
- Data Lake House и гибридные движки (Parquet, Iceberg, разделение масштабирования воркеров и хранилища)
- Качество данных и подходы к хранению разных классов данных
- Изменение парадигмы ответственности за данные в компаниях (Data Mesh)
- NoSQL базы, CAP-теорема и консистентность (MongoDB, Cassandra, ACID в NoSQL)
- NewSQL базы (Google Spanner, CockroachDB, YDB) и сложность их эксплуатации
- Новые технологии и аппаратная поддержка БД
- Роль маркетинга в успехе технологий, опенсорс и пользовательский опыт
- Финальные выводы whitepaper и размышление о будушем баз данных

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Code of Leadership #50 - Interview with Sergey Mikhalev about Odnloklassniki, VK, T-Bank and Data Platform (Рубрика #Data)

В очередном выпуске подкаста ко мне пришел интересный гость, Сергей Михалев, который работает техническим директором data platform в Т-Банке. До этого Сергей успел приложить руку к дата платформам Одноклассников и ВКонтакте. В этом видео мы успели с Сергеем обсудить его карьерный путь, который всю дорогу был связан с большими данными. Заодно мы обсудили как само это понятие менялось во времени и как выглядит state of the art сейчас, а также почему мы в Т-Банке переезжаем с Greenplum (mpp база данных) на более модный и молодежный подход с DLH (data lake house) и как имплементирует федеративный подход с data mesh, а также как поверх всего этого работает a/b платформа. А если быть точнее, то список тем, что мы успели обсудить за 2 часа приведен ниже

- Введение и знакомство с гостем
- Ранние годы, образование и профессиональный выбор
- Начало карьеры, оптимизация БД, миграции данных и рост до тимлида
- Рост компетенций
- Работа в «Одноклассниках» над дата инфраструктурой
- Инженерная и экспериментальная культура «Одноклассников»
- Важность данных и много a/b экспериментов как признак зрелого продукта
- Развитие дата-платформы в «Одноклассниках» и переход на позицию технического директора дата-платформы всего VK
- Переход в Т-банк и обсуждение культуры работы с данными, принятой в Т
- Уровень инженерной культуры, дежурства, обработка логов, AB-тесты, интерфейсы для экспериментов.
- Архитектура Greenplum, параллельность, ограничения, расширение кластеров
- Обеспечение надежности, риски при переключениях, резервная система. Ограничения Greenplum
- Новая архитектура дата-платформы с разделением compute и storage
- Новая парадигма работы с данными: внедрение дата контрактов
- Федерализация дата инженеров и передача ответственности в сами продуктовые команды
- Сервисы и дата-продукты, пайплайны, взаимодействие в экосистеме
- Форматы работы: офис против удалёнки
- Баланс работы и личной жизни
- Будущее IT и потенциал биомедицины
- Советы по саморазвитию и поддержанию мотивации
- Завершение и благодарности

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #Databases #Architecture #Devops #Management #Career #Architecture #DistributedSystems #SystemDesign #Leadership

Research Insights Made Simple #17 - Measuring the Impact of Early-2025 AI on Developer Productivity (Рубрика #DevEx)

Разбор отчета METR "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", где показано замедление разработчиков при использовании AI. Методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Правда, такой размер выборки не помешал многим журналистом активно писать про это исследование. В итоге, я позвл в гости Артема Арюткина, СРО платформы для разработчиков в Городских сервисах Яндекса, вместе с которым мы обсудили все плюсы и минусы этого исследования.

Вот примерный список тем, что мы успели обсудить за 40+ минут
- Введение, анонс METR и бенчмарка
- Знакомство с гостем
- Спонсор исследования и возможная предвзятость
- Как устроен эксперимент
- Гипотезы о мотивах и дизайне исследования
- Оценка и самооценка задач участниками
- Набор участников и требования к ним
- Ограничения масштаба и методологии
- Цифры: 246 задачи от 1 до 8 часов по длительности, 16 инженеров в исследовании
- Пять факторов замедления работы
- Контекст, интеграция и коммуникации как узкое место
- Как работать с инструментом по уровням сложности
- Почему моделям сложно применять изменения в реальном коде
- Итоги бенчмарков и ограниченность генерализации

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

P.S.
На Big Tech Night в ближайшую пятницу Станислав Моисеев, мой коллега, что руководит RnD центром, расскажет про разные подходы к измерению developer productivity в общем, а также то, как померить влияние Gen AI на это. Если тема вам интересна, то регистрируйтесь и приходите послушать.

#Software #Engineering #Metrics #Databases #Architecture #Devops

Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Техношоу «Дропнуто»: выпуск 1 (Рубрика #SRE)

Посмотрел вчера интересный выпуск нового шоу "Дропнуто" от моих коллег из Т-Банка. В этом шоу ребята говорят об инцидентах на дата‑платформах, с честным разбором причин и выводов. Интересно, что шоу идет в прямом эфире, что должно вселять надежду в минимум редактуры и зап...ния. Формат выдержан в духе blameless postmortems, где мы подходим к постмортемам без обвиненений и даже с прицелом на обучение - чель поговорить про то, а почему отказы случаются, как их предотвратить и что изменить в процессах/архитектуре для повышения надежности (кстати, про надежность в Т-Банке хорошо рассказывал Леша Мерсон в статье, о которой я писал раньше).

В первом выпуске подкаста гостем был Александр Крашенинников из Т‑Банка, практик в области платформ данных/ETL/DWH, а также просто человек с хорошим чувством юмора и навыками импровизации, что можно увидеть из его рассказа о двухнедельном инциденте в датаплатформе, о котором он рассказывает в этом эпизоде. Цепочка инцидента выглядит кратко примерно так: удаление/потеря метаданных → падение чтения в Trino → нет бэкапа/медленное CDC‑восстановление → критичный инцидент → разворот на новую Kafka‑архитектуру + контракты → унификация схем, параллельные загрузки → валидация и исправление расхождений → восстановление сервиса с возможной частичной потерей → восстановление сервиса из бекапов и дозагрузка исторических данных.

Инженерам может понравитсья этот «боевой» разбор инцидента
- Эксплуатация CDC (change data capture): где Debezium удобен, его архитектурные варианты, типовые грабли
- Паттерны целостности: outbox‑подход для надёжного обмена событиями между сервисами и границы применимости.
- Наблюдаемость пайплайнов: какие SLI поднимать для «скорости данных» (freshness/latency), целостности (дупликаты/пропуски), устойчивости коннекторов.

Руководителям эпизод полезен для управленческой оптики:
- Единый язык риска: связать цвет/серьёзность инцидента с бюджетам ошибок и фризом релизов
- Культура обучения на сбоях: blameless‑постмортемы как системный инструмент качества и коммуникации между командами данных/продукта/SRE.
- Управление SLO: перевод пользовательских метрик (например, «данные в витрине свежи ≤ X минут 99,9% времени») в алерты и план/факт по риску.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Databases #Data

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)

Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)

1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам

2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).

3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.

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

#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API

[1/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Изучил ежегодный обзор рынка баз данных от Andy Pavlo, крутого преподавателя и исследователя мира БД из Carnegie Melon University. Ниже краткое саммари основных моментов

🐘 PostgreSQL правит бал
Доминирование PostgreSQL продолжается и именно вокруг Postgres сосредоточена большая часть энергии и инноваций в СУБД.
В 2025 это подтвердилось громкими сделками:
- Databricks купил облачный PostgreSQL-сервис Neon (~$1 млрд)
- Snowflake – Crunchy Data ($250 млн)
- Microsoft запустил свой PostgreSQL-DBaaS (HorizonDB)

Появились проекты масштабирования Postgres по горизонтали (шардинг):
- Supabase нанял соавтора Vitess для проекта Multigres
- PlanetScale анонсировал систему Neki – Postgres-на-стероидах для больших нагрузок
Pavlo приветствует эту волну "шардированного Postgres", хотя напоминает, что попытки сделать масштабируемый Postgres предпринимались и раньше.

🤖 MCP для LLM в каждый дом
Если 2023-й был годом "векторных индексов" в каждом движке, то 2025-й – годом поддержки Anthropic MCP (Model Context Protocol) во всех СУБД. После поддержки OpenAI этого протокола практически каждый вендор выпустил MCP-сервер к своей базе – от OLAP-систем (ClickHouse, Snowflake и др.) до NoSQL (MongoDB, Neo4j, Redis); а провайдеры PostgreSQL‑DBaaS написали свои реализации. По мнению Andy Pavlo появление такого стандарта взаимодействия ИИ с БД - это благо, но стоит нужно ограничивать и мониторить эти реализации (например, только read-only запросы, лимиты на результат и таймауты), иначе рано или поздно случится факап

⚖️ MongoDB против FerretDB – судный день?
Впервые за историю индустрии СУБД одна компания подала в суд на другую за имитацию её API. MongoDB, Inc. обвинила стартап FerretDB (прокси, переводящий запросы MongoDB в PostgreSQL) в нарушении авторских прав, патентов и лицензии. Andy Pavlo сравнивает этот иск с процессом Oracle vs Google за Java API – тогда суд встал на сторону свободной реализации. Исход дела неясен, но есть пикантный нюанс: FerretDB изначально назывался "MangoDB". Интересно, что параллельно Microsoft в 2025 открыла исходники собственной Mongo-совместимой базы DocumentDB (передав проект в Linux Foundation) – то есть фактически занялась тем же, в чём Mongo обвиняет FerretDB.

📁 Война форматов данных
Почти 15 лет формат Parquet царил в колонночных хранилищах, но в 2025 сразу пять новых open-source форматов бросили ему вызов (ещё несколько появились в 2024-м). Среди них – проекты от академиков (FastLanes, F3, AnyBlox), стартапов (Vortex от SpiralDB) и гигантов (Microsoft Amudai, правда, его тихо прикрыли к концу года). Сообщество Parquet встрепенулось и взялось за модернизацию стандарта. Andy Pavlo отмечает, что главная проблема Parquet – не в самом формате, а в фрагментации реализации: слишком много парсеров/писателей в разных языках, поддерживающих разный поднабор фич. В результате 94% файлов «в живой природе» до сих пор созданы с фичами v1 образца 2013 года. Никто не будет переписывать петабайты старых паркет-файлов, да и невозможно быть уверенным, что любая система прочитает новейший файл – вдруг ей не хватит поддержки специфичных опций. Новые форматы пытаются решить проблему совместимости по-разному. Например, формат F3 (разрабатываемый в том числе при участии Pavlo) встраивает в каждый файл собственные декодеры: и в виде нативных модулей, и в виде WASM-кода, лежащего прямо в файле. Идея в том, что база данных сможет прочесть колонку даже нового, незнакомого формата – исполнив прикреплённый WASM-декодер. Другие (AnyBlox) генерируют единый WASM для всего файла. Пока неясно, чей подход победит – Parquet повсеместен, и инерция огромна. Следующее сражение развернётся за поддержку GPU в форматах, прогнозирует Pavlo, но одно ясно уже сейчас: битва за эффективное хранение данных вошла в новую фазу.

В продолжении я расскажу про остальные пункты.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

[2/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Продолжая рассказ об обзоре рынка баз данных от Andy Pavlo, расскажу про оставшиеся тезисы.

💸 Деньги, слияния и поглощения
2025-й оказался богат на крупные сделки в мире данных
- Продолжилась охота на PostgreSQL-компании: Neon ушёл к Databricks, Crunchy Data – к Snowflake (за $250 млн)
- IBM не остался в стороне и забрал себе DataStax (Cassandra) примерно за $3 млрд
- Salesforce раскошелился на старейшую ETL-платформу Informatica (~$8 млрд)
- Даже MariaDB Corp. умудрилась в том же году дважды купить «саму себя» – вернув под своё крыло отколовшуюся облачную дочку SkySQL
- Неожиданностью года стало слияние Fivetran и dbt Labs – две взаимодополняющие компании объединились в ETL-колосс, метящий на скорый IPO

📉 Инвесторы охладели к новым СУБД
Хайп вокруг векторных баз спал, венчуры в 2025 меньше инвестировали в молодые DB-стартапы, предпочитая нести деньги в AI. Зато лидеры отрасли продолжают получать огромные раунды:
- Databricks привлёк $5 млрд (два раунда) за год
- ClickHouse – $350 млн
- Supabase – суммарно $300 млн (Series D + E)
- И даже совсем молодые проекты вроде SpiralDB (создатели Vortex) поднимают десятки миллионов.

💀 Не все выжили
Ряд компаний не пережил этот год
- Закрылся FaunaDB – амбициозный распределённый СУБД‑стартап с сильной консистентностью (Pavlo был у них техконсультантом и советовал добавить SQL, но его не послушали)
- Проект PostgresML (машинное обучение внутри PostgreSQL) тоже не взлетел
- Команда Hydra (коннектор DuckDB↔️Postgres) разбрелась кто куда
- Даже классика: Apache Derby (Java-СУБД с 1997 года) объявлен "read only" – разработка остановлена за отсутствием мейнтейнеров.
GPU-базы данных тоже постигла нелёгкая судьба
- Стартап-супергруппа Voltron Data с инвестициями $110M так и не успела выпустить свой GPU-ускоренный движок Theseus
- HeavyDB (ранее OmniSci/MapD, пионер GPU-СУБД) тихо прекратил самостоятельное существование – команду поглотила Nvidia
Andy Pavlo резюмирует: нишевые решения вроде Kinetica и Sqream по-прежнему где-то на периферии, а заметно потеснить классические CPU-ориентированные СУБД GPU-решения пока не смогли. Производительность современных колонночных систем на CPU уже настолько высока, что решающее значение имеют не сырые оптимизации, а удобство для разработчиков и «умность» оптимизатора запросов. Впрочем, Pavlo намекает, что в 2026-м мы услышим о новых попытках задействовать GPU на полную мощность – гонка продолжается.

🏆 Ларри Эллисон – вершина успеха
Для основателя Oracle этот год стал поистине триумфальным. В 81 год Ларри Эллисон возглавил список богатейших людей планеты, впервые «коронованный» как самый богатый человек в мире (состояние оценивалось около $393 млрд). Oracle взлетел в цене благодаря облачным сделкам в сфере ИИ, и в сентябре 2025 акции Oracle выросли на 40% за день, сделав Эллисона не только №1 в мире, но и самым богатым человеком в истории (с поправкой на инфляцию обошёл даже Рокфеллера). Правда, спустя пару месяцев стоимость Oracle откатилась и Ларри потерял порядка $130 млрд – в масштабе миллиардера это как для нас с вами лишиться одной зарплаты, шутит Pavlo. В течение года Oracle/Эллисон засветились в крупных событиях: Oracle выступил ключевым партнёром в сделке по «американизации» TikTok и финансировал попытку поглощения Warner Bros (через принадлежащий семье Эллисона холдинг Paramount). Andy Pavlo признаётся, что был даже рад услышать новость о том, что “благодаря базам данных кто-то стал самым богатым на земле” – наконец в нашей сфере случилось нечто позитивное. Он иронизирует над критиками Эллисона: мол, Ларри уже завоевал мир корпоративных баз данных, выиграл регаты и построил сеть люкс-спа для техно-богачей, так почему бы ему не купить новостной телеканал? Эллисон не обращает внимания на разговоры, делает что хочет – фанаты и новая жена его поддерживают, а остальное неважно.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future