С технической точки зрения Яндекс Диск — не просто веб-обертка файловой системы, а 60+ сервисов для обработки сотен различных фич — от просмотра и редактирования данных до публичного доступа к ним. Эта статья будет полезна, если вы планируете распределить нагрузку на вашу БД или вам просто интересен опыт развития БД для обработки большого числа запросов. Когда мы запускали сервис, то сразу ориентировались на рост и приняли решение шардировать базу метаданных о файлах. Но за 11 лет Яндекс Диск настолько вырос, что нам пришлось трижды менять подход к шардированию.
Чтобы повысить отказоустойчивость, добавили большое количество реплик для чтения. Добавление пользователя более редкая операция, чем чтение информации для получения или изменения его данных, поэтому rate на запись ниже, чем на чтение. System DB — это база данных с одной коллекцией, которая содержит только ID пользователя и ID-шарда. Она занимает всего несколько гигабайт, а индексы помещаются в оперативную память. Диск сразу планировался как большой сервис, которому нужно расти горизонтально.
Разные реплики одной таблицы также могут быть шардированы по-разному. Каждый таблет упорядоченной таблицы является независимой очередью. Решардирование упорядоченной таблицы возможно только с указанием желаемого числа таблетов.
Решения
Прежде, чем будем думать, как шардировать, нужно хорошенечко погрузиться в задачу и проработать сценарии работы. Следует выбирать принципы шардирования так, чтобы минимизировать суммарную стоимость системы, лучше выраженную в твёрдой валюте. Прежде чем заниматься всякой ерундой типа шардинования нужно понять, а нужно ли оно мне.
Перераспределине Данных(решардинг)
Потому что на самом деле они не отражают реального физического сервера. И используется несколько методов для отображения непосредственно ключа на шард. Изначально в блокчейне Ethereum планировалось ввести более глубокий уровень шардирования, разделив сеть на разные сегменты. Однако эта идея в значительной степени была отложена на второй план.
- Эта статья будет полезна, если вы планируете распределить нагрузку на вашу БД или вам просто интересен опыт развития БД для обработки большого числа запросов.
- Мы можем использовать шардинг без репликации, репликацию – без шардинга или и то, и то вместе.
- Какая-то логика применяется внутри прокси, он определяет, на какую ноду идти, делает запрос, получает данные, потом передает эти данные назад клиенту.
- Каждый шард управляет набором нод, обрабатывающих транзакции.
Шардинг также позволяет горизонтально масштабироваться и повышает устойчивость к сбоям — падение одного шарда приводит к деградации сервиса, но не к падению всей системы. Благодаря ей достигается отказоустойчивость и масштабируются запросы на чтение, которых сильно больше почти во всех прикладных системах. Сочетание репликации с шардингом позволяет масштабировать крупные системы, обеспечивая при этом отказоустойчивость.
Он обеспечивает масштабируемость, производительность и доступность при работе с базами данными. Шардинг значительно усложняет архитектуру базы данных и логику приложений, требуя тщательного проектирования и исполнения. Если один шард выходит из строя, это не приводит к сбою всей базы данных.
Маршрутизатор ищет подходящий маршрут с учетом входных параметров запроса, стратегий маршрутизации и топологии узлов сервисов. Следит, чтобы клиент, получивший данные через некоторый узел, по возможности направлял данные и получал ответы от него же. Это предотвращает неконтролируемый рост нагрузки на множество разных узлов. Application Sharding обеспечивает поддержку постепенного развёртывания. Для этого создаётся отдельная шарда с новым релизом обработчика и репликой реальных данных. При green-blue развёртывании трафик постепенно перенаправляется на новый релиз.
В обзоре мы подробно рассмотрим, когда внедрять шардирование, как Shardman справляется с ограничениями традиционных подходов и почему он стал выбором для миграций с Oracle на объемах свыше 60 ТБ. Давайте представим, что нам надо записать в кластер информацию про всех жителей планеты. В роли ключа шарда мы можем взять, допустим, год рождения человека. В таком случае нам будет достаточно 116-ти серверов (правда, каждый год нам придётся добавлять новый сервер). Также мы можем взять в виде ключа страну проживания — тогда потребуется около 250-ти серверов.
Координатор шардов — это отдельный микросервис, который хранит реестр всех пользователей (на каком шарде находятся данные каждого пользователя) и хостов, которые входят в каждый шард. Он поддерживает соединение со всеми хостами и определяет их «живость», а еще — упрощает миграцию данных, чтобы ребалансировать шарды. Например, хеширование ключа в виде инкрементального счетчика позволит встроенным механизмам удобнее и лучше распределять данные по шардам. Шардинг может привести к значительному повышению производительности. Разделение базы данных сжигание токенов обеспечивает распределение рабочей нагрузки, снижая нагрузку на отдельные серверы. У горизонтального шардирования есть большой недостаток – оно позволяет хорошо масштабировать только запросы, опирающиеся на ключ шардирования.
Способность перемещать данные открывает целый ряд возможностей. Например, чтобы модернизировать оборудование, можно перенести всех пользователей из старой секции в новую, не останавливая секцию целиком и не переводя ее в режим чтения. Жирные стрелочки на этом слайде указывают, где потекли данные. Например, https://www.xcritical.com/ видно, что жирные данные текут уже в два места.
Таким образом, он инкапсулирует логику распределения данных пользователей по шардам. Фактически — это единая точка информации о том, где находятся данные пользователя. Когда у кого-то из пользователей становилось слишком много данных, их нужно было переносить с одного шарда на шард другой — более свежий, с большим количеством свободного места.