Компания Uber создала собственную базу данных с нуля. Она получила название Schemaless DB.
В ее рамках они хотели добиться высокой доступности операций записи.
Uber сделала это возможным благодаря использованию умной и простой техники под названием Buffered Writes.
В двух словах, Buffered Writes означает, что каждый запрос на запись хранится как минимум на двух узлах - Primary Leader и Secondary Leader.
Вот как это работает:
-Клиент делает запрос в обработчик запросов.
-Обработчик запросов отправляет запросы на запись на Secondary Leader. Данные сохраняются в специальной буферной таблице на Secondary Leader.
Затем он также отправляет запрос на запись на Primary Leader. Только если обе записи прошли успешно, клиент получает подтверждение успешной записи.
- Задача Primary Leader заключается в репликации данных.
Но если leader выходит из строя до успешной асинхронной репликации, Secondary Leader служит временной резервной копией данных.
-Background Worker следит за Primary Follower, чтобы узнать, когда появится запись после репликации
-Как только запись появляется на Primary Follower, Background Worker удаляет запись из Buffer Table.
Здесь следует отметить несколько важных моментов:
- Количество вторичных лидеров настраивается
- Secondary leader выбирается случайным образом
- Буферизованные записи используют идемпотентность. Если существует несколько записей с одинаковыми идентифицирующими полями, то не имеет значения, сколько раз был сделан запрос.
В ее рамках они хотели добиться высокой доступности операций записи.
Uber сделала это возможным благодаря использованию умной и простой техники под названием Buffered Writes.
В двух словах, Buffered Writes означает, что каждый запрос на запись хранится как минимум на двух узлах - Primary Leader и Secondary Leader.
Вот как это работает:
-Клиент делает запрос в обработчик запросов.
-Обработчик запросов отправляет запросы на запись на Secondary Leader. Данные сохраняются в специальной буферной таблице на Secondary Leader.
Затем он также отправляет запрос на запись на Primary Leader. Только если обе записи прошли успешно, клиент получает подтверждение успешной записи.
- Задача Primary Leader заключается в репликации данных.
Но если leader выходит из строя до успешной асинхронной репликации, Secondary Leader служит временной резервной копией данных.
-Background Worker следит за Primary Follower, чтобы узнать, когда появится запись после репликации
-Как только запись появляется на Primary Follower, Background Worker удаляет запись из Buffer Table.
Здесь следует отметить несколько важных моментов:
- Количество вторичных лидеров настраивается
- Secondary leader выбирается случайным образом
- Буферизованные записи используют идемпотентность. Если существует несколько записей с одинаковыми идентифицирующими полями, то не имеет значения, сколько раз был сделан запрос.
Скрытое содержимое могут видеть только пользователи групп(ы): Premium, Местный, Свои