Вы, наверное, слышали, что Шедевром использует ВИДБ.
Он использует наши таблицы, использует ВИМ-Кью.
Это тоже топики, которые у нас в Яндексе созданы.
Сейчас речь пойдет об довольно интересной технологии – это чтение с реплиг.
Вы увидите довольно интересные технические вызовы с точки зрения производительности и посмотрим, как мы их решаем.
Давно прошли моменты, когда один сервер базы данных обслуживает одного пользователя.
Даже прошли моменты, когда сервер базы данных обслуживает тысячи пользователей.
Вполне нормальные ситуации, что в базу данных приходят миллионы пользователей и что-то нужно с этим делать, нужно строить какие-то новые архитектурные подходы.
Ну и на самом деле, таких вот примеров, когда миллионы пользователей, их очень много, вот просто я вот сейчас их перечислю, вот типичный пример сервиса, которым, возможно, вы все пользуетесь, у него аудитория сотни миллионов, вот, и представляете, вот сотни миллионов одновременно открывают,
И, например, сначала делают авторизацию, потом подгружают там информацию о счёте, потом подгружают, например, там маршрут строят и так далее, и так далее.
И это идёт в какую-то базу данных, то есть 100 миллионов пользователей выполняют большое количество действий одновременно.
А потом я чуть покажу, как вот именно в такси, какие они очень сложные действия делают с точки зрения базы данных.
Вы даже не представляете, вот там чуть-чуть забегая вперёд.
Потом другой есть класс проблем, когда не большое количество пользуясь, а большое количество РПС.
Вот это уже Яндекс карта.
Когда отгружается эта страничка, что происходит?
Мы подгружаем саму карту конкретные изображения, то есть на самом деле эта картинка стоит из большого количества изображений.
Мы подгружаем объекты, которые на ней есть.
Для каждого объекта есть фотография, есть отзывы, есть лайки.
И это все нагрузка в базу данных, которая амплифицируется и приводит к миллионам рпс начтения.
Я опять говорю «чтения», потому что весь доклад будет про «чтения».
Дальше вполне себе проблема — это горячие ключи.
Вот тут уже показана у нас новостная страничка.
Вот вышла какая-то актуальная новость, и все пошли ее читать.
Все пошли читать именно ее вот эту новость по конкретному айдишнику, по конкретному ключу.
И тут уже никакое шардирование нам не поможет.
Нам не поможет там тысяча серверов.
Если мы читаем точечно по одному ключу, мы всегда пойдем в один конкретный шарт, вот в одну строчку бази данных и тут что-то надо сделать.
То есть представляете, 100 миллионов пользователей идут читать один ключ в базе данных.
Ну и несколько дата-центров.
То есть это сейчас реальность.
Без этого никакой серьезный сервис не работает.
Но я хочу проиллюстрировать на примере, например, видео-сервиса.
То есть видео-травка отдаётся обычно из локального какого-то дата-центра.
Куда ходить быстрее, куда ходить дешевле, куда ходить с меньшей латентностью.
Видео – это просто простейший пример.
сервисы, который создают большую нагрузку на полусопропускание.
И плавно переходим к сути доклада.
Мы будем говорить про чтение из базы данных.
И вот тут выдвигаются довольно интересные требования.
То есть первые требования мы должны читать за одну миллисекунду из нескольких датацентров.
Дальше я прямо еще пару раз про это коснусь.
Я раскрою, почему одна миллисекунда... На самом деле, поднимите руки, кто знает, почему именно одна миллисекунда, почему десяти листов не хватит.
Вот прям раскрою, вы не поверите, но действительно есть сервисы в Яндексе, кому нужна строгая одна миллисекунда.
Ну и второе, что нужно решать, то есть не только время, но и перпендикулярное совершенно требование, это большая пропустная способность.
Мы должны просто через себя прокачивать трафик от сотни миллионов пользователей.
Как я говорил, эти сотни миллионов пользователей могут прийти в один ключ в базе данных, который находится на одном сервере.
Классическое решение по учебнику — это чтение с реплик.
То есть, что у нас делается?
У нас есть сервер базы данных, в нем выделяется лидер.
И этот лидер каким-то образом поставляет данные в свои реплики.
И эти реплики могут находиться в нескольких экземплярах, в разных датоцентрах.
Ну и обычно, как происходит, то есть пишущая нагрузка идет на лидера, он все-таки является каким-то координатором нагрузки.
А вся читающая нагрузка идет на реплике.
А мне вот прямо интересно, кто из вас проходил архитектурность беседования в какой-либо компанию?
Вот уже почти половина зала.
Вот это выучите и половина собеседования у вас все нормально.
Потому что там обычно спрашивают, вот как справиться с бешной нагрузкой от пользователей.
Отвечайте, ставите много реплика и все будет хорошо.
Ну, на самом деле, тут все гораздо интереснее.
Вот эта теория реплика, она развивалась в течение некоторого времени.
Можно выделить, как минимум, 4 подхода к реплицированию в разных классах базы данных.
Один из самых первых подходов — это традиционная ассимхронная репликация, когда у нас выделяется один лидер, и он поставляет изменения в ассимхронном режиме на одну либо несколько реплик.
Лидер принимает нагрузку на запись, реплики на нагрузку на чтение, но у этих подходов у классических есть очень узкое место неприятное.
Это выбор и перевыбор лидера.
Лидер живет в одном дата-центре.
Реплики живут в других дата-центрах.
Их скаватор приехал, раскопал линию связи.
У каждого из них у лидеров старого.
Он понимает, что он живой, все нормально с ним.
Реплика в другом дата-центре.
Она видит тоже дата-центра.
Сам по себе живой, все нормально.
Вот, но я не вижу лидера.
И она говорит, я теперь лидер.
И начинает принимать на себя пишущую нагрузку.
То есть старый лидер принимает на себя пишущую нагрузку.
Новый лидер тоже принимается на себя пишущую нагрузку.
И наверняка вы все знаете, как это ситуация называется.
Да никак, это заводить инцидент и вручную разбираться с этими конфликтами записи.
То есть это безумно сложная задача.
Небольшим шагом вперед, вот, являются подходы, например принятые в MongoDB, это набор реплик, что тут появляется именно в картинке.
Вот, если внимательно картинку посмотрим, у нас не только потоки данных есть, а еще появляются хардбиты.
То есть это синхронизация между
Всеми участниками этого процесса, которые позволяют что сделать, если какой-то участник отвалился, то мы с помощью квором выбираем нового лидера.
И вот этот квором напилили, перевыбор и периодических орбит позволяет нам как бы уже автоматически выбирать лидера.
Следующим шагом вперед является одноранговая архитектура и классический пример, вот прям замечательная база данных Кассандра, которая, там, одной из классических новостей решений, что в Кассандре происходит все равны.
Пишем мы в несколько узлов сразу по кворому.
Читаем мы тоже из нескольких узлов по кворому.
И поэтому какие-то локальные отказы одного-двух узлов нам не страшны абсолютно.
И подобный подход очень сильно отличается от предыдущих двух.
Ну и одним из последних подходов является так называемая распределенная база данных.
Они появились не так давно, и у них есть некоторые общие черты.
В распределенной базе данных выделяется строковая таблица.
Этого строковой таблицы в ней ключи отсортированы по значению.
И эти ключи разбиты на диапазоны.
И за каждый диапазон отвечает свой лидер, который принимает пищевшую нагрузку вот и у этого лидера есть несколько реплик, который отвечает за чтение этих нескольких диапазонов.
И тут мы плавно переходим к ВДБ, которая является типичным представителем распределённой базы данных.
А я хочу дать своё понимание распределённой базы данных.
Распределённые базы данных — это вот таких два основных, две основных сущности.
Первое — можно работать как классические транзакционные базы данных, то есть в режиме строгой согласованности писать и читать.
То есть строгой согласованности — это очень важно.
И второе — можно работать в режиме нового эскюлерышения.
Когда мы эластичны, мы переживаем отказы дета-центров, то есть можем увеличивать бесшовное количество шардов, таблицы, и при этом, например, выполнять транзакции над миллионом шардов одновременно.
Вот это мое такое понимание распределённой базы данных.
И в IDB, то есть доклад у нас про реплики, в IDB поддерживаются два режима репликации.
Вот более такой классический асинхронная репликация.
То есть ну это стандартный факт, он реализован.
И вот новый режим репликации, как в расплывенных базах данных, он также реализован и про это дальше мы расскажем.
Классический режим репликации.
Про него уже были доклады пару лет назад.
Вот поэтому QR-кода, прям замечательный доклад, есть как устроена синхронная репликация.
Могу в двух словах рассказать, потому что внутри архитектура тоже довольно интересная.
То есть есть строковая таблица.
Рядом с ней заводится топик.
в которой отгружается все изменения этой таблицы.
То есть, все логические изменения мы отгружаем.
И потом уже данные из этого топика идут, например, в другую базу данных, которая может находиться, например, в другом дата-центре.
Это асинхронная репликация.
И вот этот вот топик с логическими изменениями в нем, это типичный пример чейндж-дата-кепча, cdc.
У него есть особенность, которая характерна данным подходом, то, что выбор лидера ручной.
Мы настроили, что из одного дата-центра реплицируем другой дата-центр, вот назад переключать там будет сложновато.
И дальше я пойду уже про новый подход, который принято в других распределенных базы данных про более современный подход.
Вот наша таблица строковая.
Ключи отсротированы, выделены диапазоны.
И за каждый диапазон ключей отвечает так называемая таблетка.
Практически в любой распределенной базе данных есть какой-то такой лекковесно логический процесс.
Вот таблетка таблет по-разному называется.
И таблетка может переезжать, например, с узла на узел, если понимать, что тут слишком много таблеток.
Таблетка может разделиться на две таблетки.
Те в свою очередь могут разделиться на четыре таблетки.
То есть, если мы понимаем, что слишком большая нагрузка,
Вот на этот диапазон ключей поделим пополам.
И это деление происходит за миллисекунды.
Абсолютно прозрачным для пользователя.
А если мы понимаем, что две таблетки соседние, недогруженные, то что мы сделаем,
Мы их объединим, смёржем тоже незаметно для пользователя, то есть зачем ему тратить много ресурсов, вот давайте мы там схлопнем эти ресурсы, и будем тратить меньше ЦПУ и так далее.
таблетки могут переезжать между дата-центрами, то есть сейчас она тут, потом она там.
И еще одна интересная особенность, почему они могут так переезжать спокойно с узла на узел, а потому что таблетки это слой вычислений, а есть еще один зеленый слой хранения, который абсолютно независимо находится под таблетками и таблетка может умереть и быстро воскреснем в другом дата-центре, потому что слой хранения у них общий.
А вот теперь пошли к проблеме.
Это типичная дата-центра, ну, например, в европейской часть России, между которыми раунд-трип 10 мс.
Появляется полисский сервис, который селится, например, в третьем дата-центре, и он локально читает за 1 мс.
Вот он поселился там, где есть его данные.
А теперь появляется еще несколько полисских сервисов, которые живут далеко, но хотят 1 мс.
А потом данные могут переехать каким-то образом в другой дата-центр.
И тут мы вынуждены бороться с физикой, то есть мы вынуждены бороться со скоростью света, которая накладывает ограничение, и требованиями пользователями, которые хотят 1 мс.
А вот теперь, вот если кто-то не верил, что есть такие пользователи, кто хочет именно одну миллисекунду, такие пользователи есть.
Это вот конкретные пользователи в IDB.
Вот прямо сейчас на этих трех пользователей я расскажу.
И вот поясню, почему одна миллисекунда.
Кто знает, где родился Фредди Меркера?
А Занзибар, кто знает, что такое Занзибар, но это город и архипелак.
А вот почему я на компьютерной конференции рассказываю про Занзибар?
Zanzibar — это одна из передовых систем контроля доступа, то есть авторизация.
Посмотрите, на этом графе есть субъекты доступа, объекты доступа.
И чтобы понять, кто к чему имеет доступ, мы должны пройтись по этому графу.
И именно вот на базе и такой граф позволяет построить очень мощную функциональную систему авторизации.
Там можно столько всего вот такие сущности добавить, что покрывает любые хотелки безопасников.
И именно такая авторизация работает в платформе Рейтеха Яндекса.
То есть когда вы заказываете такси, например, вот или водители там за...
Он проходит ровно через такой граф авторизации.
А теперь вот интересные красные цифры.
Чтобы пройти по пути, в 50-м персентиле мы делаем три шага.
А в 99-м персентиле мы делаем 20 чтений.
А теперь давайте, вот у нас между датацентрами там 10-20 мс, умножаем их на 20 чтений.
И получается, какая-то неприличная цифра уже порядка полусекунды на авторизацию.
Это уже не приемлемо, особенно при большом количестве пользователей.
И вот как раз отсюда появляется одна миллисекунда.
То есть именно платформа RAI-Теха требует от нас чтение за одну миллисекунду.
Потому что если умножить одну миллисекунду на 20, ну, вполне еще адекватное время получается 20 миллисекунд на проход по графа.
Вот такие требовательные пользователи у нас есть.
Следующий типич, например, пользователи, которые нужны чтение из реплиг, кинопоиск, например, либо поиск по видео.
Когда человек открывает кинопоиск, показывает список фильмов, смета-информация фильмов, эта мета-информация меняется редко, но читается очень интенсивно, потому что очень много пользователей одновременно выбирают.
И тут прям помогают реплики справиться с таким потоком нагрузки.
Либо другой интересный момент, о котором даже возможно не догадывались.
Вот внизу этот прогресс-бар, вот этот бегунок, то есть индикатор вашего места просмотра в фильме.
Вот этот индикатор пишется на одном устройстве, а потом вы можете зайти на другом устройстве и продолжить с этого же момента просматривать кино.
Момент продолжения читается с реплик.
Ну, и третий и наиболее характерный пример чтения с реплик, это, конечно же, Яндекс карты, на которых есть точки, вот, непользовательские организации, объекты интереса, различные и так далее.
У них есть фотографии, лайки, отзывы.
И вот это всё, оно активно читается, вот, но пишется, но вот так вот среднее.
Вот, и вот это активное чтение всё проходит через реплики в ADB.
Ну и пойдемте все-таки в глубь, как устроены внутри реплики и какие есть вызовы.
Как я говорил, есть у нас таблетки.
Они отвечают за диапазоны ключей.
Внутри, на самом деле, стоят из лидера и нескольких реплик.
Таким образом, за каждый диапазон отвечает один лидер и несколько реплик.
А вот теперь хочу пойти в глубоконкретные таблетки.
Каждая таблетка – это ничто иное, как конечный автомат.
Все же хорошо в УЗе учились.
Помните, что такое конечный автомат?
Ну, конечно, автомат — это некоторая сущность, которая реагирует на внешнее воздействие, на входы, изменяет свое состояние, вот, и изменяют еще свои выходы, вот.
И таким образом, внешние изменения, то есть записи, чтения и так далее, они меняют состояние таблетки.
И вот этот лог изменений, конечно, автомата, мы пишем в распределенной хранилище по сети, который где-то там находится.
И если потом, например, таблетка рестартует, она перечитывает лог изменения и приходит к тому же самостоянию.
А теперь, если внимательно подумать, в теории автоматов еще есть замечательное свойство и эквалентность автоматов.
Боюсь спросить, что это такое.
два автомата эквалентна, если они при подаче одинаковые последовательности на вход дают, оказывается, в одинаковом состоянии генерируют одинаковые выходы.
А давайте мы рядышком поставим такие же автоматы, эквалентные, абсолютно такие же, и будем отгружать в них поток изменений.
То есть весь слог изменений, который идет у нас в хранилище, мы еще отгрузим в такие же автоматы, конечно, которые находятся где-то там за сетью.
И вот эти автоматы назовем реплики.
И вот получается красивая картинка, что лидер принимает, получает изменения, он их транслирует, транслирует одновременно в надежные хранилища и транслирует одновременно своим репликом.
Как вы понимаете, реплик в такой картинке можно поставить сколько угодно, они просто будут принимать изменения.
Давайте посмотрим на некоторые интересные технические вызовы, которые есть внутри.
Ну, например, как читать свежие данные?
Представьте, что у нас на счете пользователей есть полмиллиона рублей, а мы параллельно добавляем еще миллион рублей.
И вот реплика, на самом деле, она должна вот прочитать еще пока старое значение, она должна не прочитать грязные данные.
Ну, на самом деле, вот этот вызов он довольно-таки простой.
Лидер транслирует только закомиченные изменения.
И реплика читает этот лог.
Таким образом мы читаем только закомичное изменение без грязных данных и показываем актуальное состояние, которое есть.
Другой технический вызов интересный — это как сжать наш лок.
Есть у нас база данных, как вы понимаете, которые вполне себе гарантируют миллионный поток изменений в секунду.
Через неделю это будут трабаэты данных.
Вот от трабаэты данных приводят к двум неприятным моментам, показанным на слэде.
Первый неприятный момент — просто диски кончатся.
А второй неприятный момент, если таблетка её лидера либо её реплика рестартует, то мы будем вынуждены трабайты данных поднимать и чтобы восстановить наше состояние.
И поэтому используется абсолютно красивый архитектурный паттерн, который я тоже рекомендую вам использовать где-то на собеседованиях.
Это периодическое снятие снапшотов.
Мы в этом логе снимаем снапшоты, отправляем их в хранилище.
А когда хранилище получает снапшот, оно в синхронном режиме подчищает мусор.
То есть все старые ненужные записи, оно может уже удалить.
Следующий технический вызов.
Как понять, откуда читать данные?
Потому что сценария для чтения могут быть вот совершенно разных типов.
Первое, когда мы читаем баланс, заказы, состояния корзины, что-то такое, что должно быть строго согласованное и консистентное.
Мы там не можем ошибиться.
Вот, то есть мы нам будет нам прям безумно неприятно, если мы в банке увидим мигающий баланс на нашем счете.
Либо есть, наоборот, сценарий чтения, где можно пренебрегнуть актуальностью.
Например, нам все равно 50 лайков, либо 51 лайков.
Если там какой-то лайк появится секунды позже, нам все равно.
Поэтому такие сценарии можно отправлять на реплики.
Как это реализовано внутри ВДБ?
Есть два режима чтения, то есть клиент указывает.
Либо я хочу читать в режиме строгой согласованности, это самые высокие уровень изоляции, и чтение всегда пойдет с лидера.
То есть, когда лидер у нас в данном случае является центральной точкой, и когда все записи и чтения идут через него, то тут у нас линия реализуемость получается строгая согласованность.
А если мы можем чуть-чуть пренебречь согласованностью, мы можем включить режим транзакции, стилы, рейдонли, и таким образом мы разрешаем ходить на реплики.
Ну и давайте парочку ещё немного глубоких вещей, и дальше будет проще.
Смотрите, как у нас стартуют реплики.
Когда реплика поднимается, она сначала делает запрос в Discovery.
Вот она должна понять, где находится лидера.
То есть внутри в IDB есть единый резтор всех таблеток.
Вот она обнаруживает лидеры и регистрируется на этом лидере.
После этого наступает этап синхронизации.
снял снапшот, чтобы не отправлять на реплику слишком много изменений.
И отправляет на реплику этот снапшот.
И после этого работает основной режим.
Основной режим, когда мы транслируем лог изменений, транслируем его ассинхронно пачками с интервалом примерно 20-30 мс.
И вот в этом режиме основная работа потом и происходит.
Как происходит чтение с реплик?
Приходит пользователь с запросом, с SQL запросом.
Вот в этом, кстати, помните, я говорил, что комбинируем две хорошие черты.
Мы комбинируем хорошую черту новую SQL решение.
Клиент приходит на любой узел, например, из тысячи машин и говорит, что выполняем мой SQL запрос.
Это тузел понимает, то есть партия тески или запрос, понимает, можно ли его обслужить с помощью реплика, либо нет, но и ретранслируют либо на лидеры, либо на реплику.
Команда включения мы постараюсь сделать максимально дружелюбный.
То есть все, что нужно вам сделать, то есть сначала создали табличку, а потом одна SQL-команда табличка, вот у тебя в каждом дата-центре должно быть по три реплики, все.
И внутри уже заработает вся вот эта сложная механика реплика.
Но тут хочу обратить внимание еще на пару интересных технических моментов, это согласованность.
Временная согласованность, потому что тут чуть-чуть сложнее.
Временная согласованность бывает двух видов между лидером репликой в рамках одной партиции и между репликами разных партий.
Сейчас покажу, в чем отличие.
Посмотрите, между лидером и репликой одной партиции у нас согласованность в режиме eventual consistency.
То есть изменения в конечном счете доедут до реплики.
И поэтому в рамках одной партиции все хорошо.
В рамках второй партиции тоже все хорошо.
То есть из-за этих партий по отдельности можно читать безболезненно.
А вот между разными партицами уже сильно сложнее.
Представьте, что на первой партице баланс одного абонента, на второй партице баланс другого абонента.
И если туда вот в рамках 20-30 мс данные будут чуть-чуть по-разному доезжать, вот мы можем сложить очень неприятно, получить очень неприятные эффекты.
Поэтому, если мы хотим, чтобы наши запросы точно пошли на реплику, надо учитывать это представление запросов.
Например, запросы точно чтение поключу, к чему они приведут.
Мы поключу, пойдем в одну конкретную партицию, там все хорошо, и почитаем данные из этой партийцы.
Какие запросы пойдут не на реплику, а на лидера?
Если мы явно скажем, что мы хотим строгую согласованность тут без вариантов, база данных выполнит наш приказ и пойдет на лидера.
Если мы зададим сложные запросы с большим количеством джойнов, группировок и так далее, мы тоже пойдем на лейдера, потому что не всегда с помощью реплик такие сложные запросы можно обслужить.
И третий класс запросов — это чтение из нескольких партийцей, согласованное чтение из нескольких партийцей, подчеркиваю.
Это безумно сложная инженерная задача, я раньше подсветил.
И вот как раз ровно сейчас мы ее решаем.
Вот в моменте, я думаю, мы решим и будет глубокий доклад, как это сделано внутри.
Ну и напоследок, парышку красивых слайдов.
Что будет, если включить реплики?
Синее мы читали с лидеров.
Зеленые мы переключились на реплики.
А справа, что у нас происходит с временем чтения?
Если посмотреть на фиолетовую черту, это 99-й персентиль.
Можете видеть, что до включения реплик у нас были скачки 15-30 мс, а вот умножьте 15-30 мс на 20 чтений из графа.
Вот получаем опять же неприлично 600 мс.
А после включения реплик, что получилось ровно линия, и хочу отдельно обратить внимание на зеленую линию, это 50-й персентиль, это медианное время чтения.
50-й персентиль равен ровно одной миллисекунде, что и требовалось доказать, получить.
То есть, если мы хотим использовать реплики, их стоит задаваться в разных зонах доступности, нужно мониторить различные как времена ответа, так и задержки от лезера.
Не нужно слишком усложнять запросы, нужно чуть-чуть помогать базе данных справляться, но и как обычно настраивать аллёрта.
Ну и в заключение, то есть включение реплиг позволяет кардинально распоралелить наши чтения по нагрозке, вот работать в нескольких зонах доступности, вот и самое главное, преодолеть физику, получить одну миллисекунду, даже если наши данные находятся совершенно в другом дата-центре.
Саш, спасибо большое за очень классный доклад.
Одна миллисекунда звучит очень, очень дерзкая и мощная, честно.
Я вот когда слушаешь про это, обычно борешься, борешься там за десятки миллисекунд, а тут одна миллисекунда, очень круто, хороший результат.
Вопрос из зала, я напомню, что у нас будет QR-код вот здесь, по которому можно будет отсканировать и задать вопросы в чате.
И за лучший вопрос мы дарим подарок.
Спасибо большое за доклад.
Была очень интересная тема.
И интересует весьма специфичный вопрос.
Мы поговорили про то, что случается, если отваривается у нас лидер.
А вот если, допустим, потерялась два дата центра, между ними в них каждый несколько реплик, и у нас развалилась связь.
У нас же в каждом получается свой лидер, не решали ли вы задачу того, как восстанавливать все это.
То есть есть общий лог того, что пишется, но вот мы в два лидера написали разные какие-то вещи.
Мы же не можем просто вырубить сервисы там все на несколько минут.
Вы как-то вот решали, связность дальнейшая или нет такой задачи?
Помните, я говорил, что есть общий слой хранения.
Вот, и общий слой хранения как раз на нем работает Quorum, который позволяет синхронизировать все таблетки между собой.
И как раз, помнишь, вот этого Quorum запрещается работа больше, чем одного лидера.
То есть даже если сеться, то есть у нас два дата-центра совсем разделились, связность потерялась, то все равно это как-то или как это будет.
Я хочу сказать об интересной гарантии, которая дает в IDB.
Я думаю, что она может вас впечатлить.
То есть, например, можно работать в режиме трех дата-центров, в режиме строгой согласованности выполнять транзакции.
отключается один дата-центр из трёх, всё продолжает работать, отключается ещё одна стойка в другом дата-центре, всё продолжает работать.
Вот это как раз гарантия в ADB.
А какой механизм здесь выбора лидера?
При том, когда у тебя теряется вся связанность между дата-центрами, теряется лидер, дальше что происходит?
Кажется, здесь уже невозможно анетифицировать, у вас должна быть единая точка отказа.
Единый точка отказывается как раз на слой хранения.
На котором... Нет, это не точка отказывается.
Единый слой объединенный.
Так, вопросы... Да, вопрос с зала.
Как раз таки по поводу единого слоя хранения данных.
Дата центры могут быть, наверное, и в разных странах, в том числе, и предусмотрена ли в Яндекс.Дб какая-то поддержка защиты персональных данных, где люди из разных стран будут делать запросы, но при этом их персональные данные не должны попадать в дата центры в других странах.
Смотрите, с защиты персональных данных у нас очень жёстко и очень сурово.
В частности, например, ВИДБ работает в облаке, а наш Яндекс облака прошло большое количество сертификаций в этом плане.
И аудитов, что даже дрожь бросает от того, сколько от нас всего требует регулятора.
Но не одним облаком мы едины, и хочу подчеркнуть, что ВИДБ работает не только в облаке, не только внутри Яндекса,
А прекрасно можете спокойно скачать его себе, запустить докер, запустить он премис на большой машине, поставить на своем кластере, это бесплатно, доступно в гитхабе, так далее.
То есть, мы не закрыты технология, мы вышли в open source лет 6 назад, просто ставьте и пользуйтесь.
То есть, данные не уезжают никуда, в другие страны персональные?
Матрица, сейчас задается вопрос, можно ли данные расположить в другой стороне?
То есть, если вы какой-то прикладной сервис, который разворачивает ВИДБ в другой стороне, мы как Open Source вам помешать не можем.
Ну он премис, обычный он премис решения.
Если ты хочешь локализовать свои данные, возьми себе сервак и поставь туда ВИДБ.
Но оно при этом не будет реплицироваться.
Почему не будет сделать себе реплики, подключи их, распределить по дата центрам и все будет хорошо у тебя?
Честно, я его еще не прочитал, но я его прочитаю в слух.
Должен ли клиент разбираться, в какой момент его запросы идут на реплику, а когда к лидеру?
Это первая часть вопроса, вторая часть вопроса.
Нужно ли дополнительно обучать или документировать такие процессы для коллег, состоящих клиентские сервисы?
Абсолютно правильный вопрос.
Мы с тременной, как я говорила, что есть три класса запросов, и это я прям хочу подчеркнуть.
Да, сейчас нам слайды включат на экран, и мы покажем это.
Да, смотрите, если клиент захотел строгую согласованность, говорит, я работаю с деньгами, мне нужна строгая согласованность.
Тут без вариантов, все пойдет на лидера.
Если клиент пошлет безумно сложные запросы, с которыми реплика тоже не справится, тоже пойдет на реплику.
А если реплики справятся, то они обработают и получат вот такую красивую картинку.
Поэтому на самом деле, что для таких клиентов нужно делать, если они сомневаются, куда идут их чтения, надо просто мониторить графики.
Если мы видим, что напрям си не стало зеленым, значит все хорошо.
Там еще было по поводу того, а вот нужно ли стучать по рукам у себя в команде коллегам, когда они не понимают и не туда идут.
То есть они не так распределяют нагрузку, не туда.
Но как это документируется?
Как людей обучить вот тому, чтобы они использовали правильно этот интерфейс?
В ADB очень выносливая система и до некоторых пределов она может автоматически масштабироваться, справляться со всякими желаниями пользователей.
Но иногда все-таки бывает случаи, когда хотят слишком много.
И тогда все-таки нужно каким-то образом влиять на пользователей.
Вопрос первого ряда у нас.
Могу привести пример, кстати, когда, ну, если на прям пользователь внезапно придет с гигантским шквалом запросов на запись, вот сейчас аудитория послушала, что произойдет в этом случае.
Мы пойдем в одного лидера.
Лидер на некоторое время перегрузится.
И буквально через несколько секунд мы поймем, что он захлебывается.
Мы его разделим на части, на 2, на 4, на 8 и так далее.
То есть мы будем справляться с этим.
Но в самый начальный момент мы не можем предусмотреть, что придет миллионный нагрузок.
Вообще это достаточно стандартный паттерн, то есть любые распределенные системы примерно так и работают.
Они понимают, в какой момент у тебя основная часть захлебывается и потом начинают распределять, дробить, делить и так далее.
То есть здесь ничего такого как бы необычного нет.
У тебя был слайд по поводу устройства таблетки и о том, что она сбрасывает свои стейты в некоторые распределённые хранилища.
Но концептовально это напоминает, что тот тип Райда Хейтлога, который в классических базах данных используется для репликации как раз.
Это одна и та же сущность в вашем случае, что и Райда Хейтлог, или это разные сущности?
Нет ли такой ситуации, что распределённость в этого хранилища за счёт статевых задержек дает какие-то
Ну, просадки полэтнси в момент записей.
И если это все-таки разные сущности, то есть если где-то есть локальный write-out headlock и вот этот распределенный хранилищ, то как между ними обеспечивается синхронизация в случае, если одна из вот этих таблеток она погибла вместе с сервером?
Мы работаем примерно по такой же технологии, то есть это ровно такой же лок изменения, о котором вы говорите, как write a headlock.
Просто у нас он более гранулярный, работает на этапе таблеток.
То есть, например, если рассмотреть классическую базу данных, вот большую релюционную, вот наверняка все знают их названия, там write a headlock,
Вот у нас эти логи изменения, они индивидуальны для каждой маленькой таблеточки, которая у нас сработает миллионы.
Вот единственное такое у нас архитектурное изменение.
Получается, что часть отварпселенного хранилища, куда таблетка скидывает свой стейт, она находится на той же ноде, где таблетка находится.
Нет, распределенная хранилища, она прямо обязательно размазана по дата-центру, по всем машинам, и прям распределенная хранилища, оно само может переезжать, то есть переживать отказы дисков и так далее, то есть оно старается поддерживать свою отказу устойчивости, свои
То есть, все стараются находиться в нескольких датacentрах, на разных серверах, на разных дисках.
Вот тут там все хорошо с отказываясь с той частью.
Давайте все-таки передадим в первый ряд, я обещал.
Давно присматриваюсь опять к ADB.
Сейчас еще, наверное, попытку сделаю.
Есть пару вопросов по поводу таблеток.
Я так понимаю, что это какой-то аналог шардов получается, что там данные как-то распределяются.
Как-то они еще распределяются, наверное, по репликам.
И если мы как-то на вот это шаргнирование по таблеткам влияем, то есть, например, что со связанными данными, то есть, то что вот в разных таблицах вот это вот все, то есть, например, у нас
Какие-то пользователи попадают в один ДЦ, в один хост ВИДБИ, чтобы там ни было.
И, наверное, хочется, чтобы связанные с этим пользователем данные в других таблицах тоже где-то были рядом, чтобы максимально вместе обрабатывались.
Мы на это как-то можем влиять?
Или ВИДБИ просто вот это распределяет как-то по-своему?
В ADB распределяют по своим алгоритмам.
Там есть балансировщик, так называемый Hive, который перевозит таблетки на более свободные узлы, на менее загруженные узлы и так далее.
Но мы можем повлиять на порционирование таблицы.
Например, можем указать стартовое разделение ключей по диапазонам.
Можем указать рекомендуемое количество шардов.
А если это первый вопрос, да, влиять можем, но при этом есть очень небольшая логика, как автоматически справляться с нагрузкой.
А второй вопрос, как сделать, чтобы данные были локальные, ну вот как раз включить реплики, и получается, что все таблицы могут быть в локальных репликах на данном узле.
Ну и про вот это распределенное хранилище, просто в процессе объяснения
Звучит, что бы сделать надёжную базу данных, нужно взять надёжную базу данных и использовать её.
Что за распределённые хранилища, как оно поддерживает вот эту консистентность и что-то про него?
Так, про это было пару докладов, как именно там у нас сквором устроено вот в этом распределённом хранилище.
Хочу немного подправить, чтобы сделать хорошую базу данных, чтобы она хорошо работала в режиме строгой согласованности.
В этой базе данных должен быть какой-то центральной точкой координации, в которой будет линия раздаваться запросы.
В нашем случае точка координации получается распределенной хранилище, но оно гигантское.
Оно может стоять из 10 тысяч машин.
Но тем не менее, на этих 10 тысяч машинах будет работать к вору, которая будет поддерживать таблетки наши, которая будет помогать их перезапускать, помогать бороться со сплитбрейном.
У нас были доклады, парочку докладов и даже тройку на конференциях, как именно распределенный хранильший работает.
Сори, это будет последний, наверное, вопрос.
Я, кстати, тоже очень много хотел, но я думаю, можно будет найти Сашу в дискуссионной зоне, поймать его здесь там на обеде или где-то еще и позадавать ему еще дополнительные вопросы.
Может быть, единственный вот в чате, знаешь, какой был вопрос, которым я вот хотел бы полернуть.
Он очень провокативный, значит, готовься к нему.
Почему мне нужно перейти на УИДБ?
Смотрите, вот есть относительно крупная организация.
Которая в бизнес-цикле обработки заказа встает шардерланный посгресс.
Поняли, что 20 шардов посгресса не справляются с этой нагрузкой.
И эта организация затеивает процесс перехода на другое количество шардов, количество 40 штук.
То есть с 20 шардов мы делаем переход на 40.
При этом нужно аккуратно писать в два места, читать, например, тоже с двух мест.
То есть нужно аккуратно, очень аккуратно переключать нагрузку.
То есть решардирование – это боль.
И угадайте, что случилось, когда они перешли с 20 шардов на 40 шардов.
Не хватило 40 шардов в 1,5 года.
Почему стоит использовать распределённые базы данных?
Такой проблемы просто нет.
То есть 20 на 40 шардов и перейдёте за пару минут.
Да, но каждому инструменту, наверное, подходит своя зона ответственности.
И если у вас большое количество данных, вам хочется хранить, шардировать большим количеством шардов у IDB идеальный вариант.
Давайте поблагодарим Сашу за отличное выступление.