Хотел уточнить про раскидывание по конвейерам. Имеется ввиду делать N потоков, обслуживающих M соединений?
Про вынос TCP стека в user space ещё хотел уточнить - ради избавления от context switch, походов в ядро? Благодаря этому будет буст производительности?
if(request_type1) {
Для получения shard_key взять из запроса значение определенного поля
} else if(request_type2) {
Для получения shard_key взять из запроса значение определенные поля.
Произвести над ними арифметическую операцию.
} else if(request_type3) {
Для получения shard_key cходить в сторонний сервис
} else ... {
Для получения shard_key реализовать комбинации перечисленных выше действий
}
А у вас список требований больше, чем у такого готового решения?
По идее, готовое решение решает большинство типов задач шардинга. Если вы говорите, что не подходит, значит у вас не типовые задачи? Как вариант, привести задачи к типовым? Или настолько сильная специфика взаимодействия с данными, уникальная инфраструктура?
Consistent hashing, будучи простым по своей природе, довольно сложен в настройке и обслуживании, поэтому давайте придумаем гибридный подход между ним и предыдущим со степенями 2.
Почему сложен? Мне кажется, что вы как-раз его и реализовали.
Взяли круг из 65536 значений. Каждые данные попадают в какое-то значение. За интервал значений отвечает какой-нибудь сервер. Сервер отвечает даже за несколько интервалов. Чтобы распределить нагрузку более равномерно по серверам.
Это же и есть consistent hashing с виртуальными серверами?
"Сначала мы вычисляем значение хэш-функции для переданного значения шард-ключа и вычисляем индекс бакета, разделив его по модулю на наше фиксированное количество виртуальных бакетов, равное 65536" 1. Пришли такие-то данные. 2. У них взяли поле, которое для этого типа данных является shardKey. 3. Вычислили hash(shardkey) % 65536. 4. Получили номер "виртуального бакета". 5. Теперь нужно понять, какой сервер отвечает за данный бакет. 6. Сходили в БД конфигуации == master node: a) Дали этот номер == $Offset (где bucket_index_start == 0, bucket_index_end == 65536 ?) б) Получили адрес сервера
Класс! Спасибо! По поводу балансировки. Какой алгоритм используете?
К примеру, окажется так, что у вас 10 back-end сервисов("приложений" как Вы называете). Пришло 100 запросов. Каждый 10ый тяжелый. И у вас round-robin. Тогда все эти 10ый запросы на 10ом сервисе. Его грузит.
Load balancer балансирует нагрузку между подами k8s?
У каждого back-end сервиса свой пул(in-memory cache сервиса) уже созданных соединений к различным шардам?
Выше писали "само приложение знает конфигурацию шардов". Зачем ему тогда знать, если этим знанием обладает back-end сервис? Который и роутит запрос в нужный шард. Тогда приложение умеет лишь слать запрос back-end сервису. Или я что-то не так понял?
Про коннекты. Мы сейчас находимся в нашем обсуждение на мобильном устройстве, в приложение ali. У него есть коннекты к различным шардам. Вы это имеете ввиду?
Что зашли в местный кэш(который, кстати, обновляется по push модели? К нему приходит push уведомление от сервера конфигурации?), получили connection string, посмотрели в некий местный хэш: "по данному connection string уже есть connection" и пользуемся им? Верно понял?
После того как бакет был вычислен, мы находим диапазон бакетов, в который он попадает. Мы можем возложить эту задачу на SQL-сервер, который содержит конфигурацию.
Затем останется просто создать экземпляр соединения с соответствующей строкой подключения, открыть его и вернуть.
То есть клиентское приложение сделало запрос. Вычислился shard key. Обратились к БД конфигурации/master node. Она посмотрела в какой диапазон этот key попадает.
Суть такая что за каждый диапазон key отвечает какой-то один сервер, на котором данные под данный key.
И master node выдала connection string этого сервера.
Далее клиентское приложение создаёт подключение по такому connection string. И выполняет запрос.
А какого формата данные раскиданы по шардам? Одна табличка? Или разные? И знаете на уровне приложения что сейчас надо идти в такую-то табличку, которая на таких-то шардах?
Хотел уточнить про раскидывание по конвейерам. Имеется ввиду делать N потоков, обслуживающих M соединений?
Про вынос TCP стека в user space ещё хотел уточнить - ради избавления от context switch, походов в ядро? Благодаря этому будет буст производительности?
А что у вас?
Как мне кажется, в consistent hashing теже интервалы, за которые отвечает сервер.
И у вас в таблице у master'а строка с сервером и интервал, за который он отвечает.
Пока всё тоже самое, на мой взгляд. Что я упускаю?
Как минимум, есть 1 сервер. В этом случае он отвечает за весь интервал:
min - 1
max - 65k
Спасибо!
То есть:
1) Сервис понимает тип запроса;
2) В зависимости от типа запроса реализует логику
?
Понятно!
в зависимости от запроса может быть либо явным полем, либо вычисляемым
Можно пару живых примеров? Чтобы почувствовать лучше реальную реализацию.
А у вас список требований больше, чем у такого готового решения?
По идее, готовое решение решает большинство типов задач шардинга. Если вы говорите, что не подходит, значит у вас не типовые задачи? Как вариант, привести задачи к типовым? Или настолько сильная специфика взаимодействия с данными, уникальная инфраструктура?
Классно, спасибо!
Consistent hashing, будучи простым по своей природе, довольно сложен в настройке и обслуживании, поэтому давайте придумаем гибридный подход между ним и предыдущим со степенями 2.
Почему сложен? Мне кажется, что вы как-раз его и реализовали.
Взяли круг из 65536 значений. Каждые данные попадают в какое-то значение. За интервал значений отвечает какой-нибудь сервер. Сервер отвечает даже за несколько интервалов. Чтобы распределить нагрузку более равномерно по серверам.
Это же и есть consistent hashing с виртуальными серверами?
"Сначала мы вычисляем значение хэш-функции для переданного значения шард-ключа и вычисляем индекс бакета, разделив его по модулю на наше фиксированное количество виртуальных бакетов, равное 65536"
1. Пришли такие-то данные.
2. У них взяли поле, которое для этого типа данных является shardKey.
3. Вычислили hash(shardkey) % 65536.
4. Получили номер "виртуального бакета".
5. Теперь нужно понять, какой сервер отвечает за данный бакет.
6. Сходили в БД конфигуации == master node:
a) Дали этот номер == $Offset
(где bucket_index_start == 0, bucket_index_end == 65536 ?)
б) Получили адрес сервера
Верно?
Класс! Спасибо!
По поводу балансировки. Какой алгоритм используете?
К примеру, окажется так, что у вас 10 back-end сервисов("приложений" как Вы называете). Пришло 100 запросов. Каждый 10ый тяжелый. И у вас round-robin. Тогда все эти 10ый запросы на 10ом сервисе. Его грузит.
Почему?
Спасибо, понятно!
Load balancer балансирует нагрузку между подами k8s?
У каждого back-end сервиса свой пул(in-memory cache сервиса) уже созданных соединений к различным шардам?
Выше писали "само приложение знает конфигурацию шардов". Зачем ему тогда знать, если этим знанием обладает back-end сервис? Который и роутит запрос в нужный шард. Тогда приложение умеет лишь слать запрос back-end сервису. Или я что-то не так понял?
То есть, само приложение понимает к каким данным обратились. И знает где эти данные лежат(на каком шарде)?
То есть, работает без прослойки/proxy/routing'а?
Спасибо за ответ!
Про коннекты. Мы сейчас находимся в нашем обсуждение на мобильном устройстве, в приложение ali. У него есть коннекты к различным шардам. Вы это имеете ввиду?
Что зашли в местный кэш(который, кстати, обновляется по push модели? К нему приходит push уведомление от сервера конфигурации?), получили connection string, посмотрели в некий местный хэш: "по данному connection string уже есть connection" и пользуемся им? Верно понял?
Классная статья! Закрыла некоторые вопросы. К примеру, вариант доступа к шардированной системы непосредственно из клиентского приложения.
Недавно перевёл начало главы "Шардирование" из книги Web Scalability for Startup Engineers на своём тм канале System Design World.
После того как бакет был вычислен, мы находим диапазон бакетов, в который он попадает. Мы можем возложить эту задачу на SQL-сервер, который содержит конфигурацию.
Затем останется просто создать экземпляр соединения с соответствующей строкой подключения, открыть его и вернуть.
То есть клиентское приложение сделало запрос. Вычислился shard key. Обратились к БД конфигурации/master node. Она посмотрела в какой диапазон этот key попадает.
Суть такая что за каждый диапазон key отвечает какой-то один сервер, на котором данные под данный key.
И master node выдала connection string этого сервера.
Далее клиентское приложение создаёт подключение по такому connection string. И выполняет запрос.
Правильно?
Спасибо за статью!
А какого формата данные раскиданы по шардам? Одна табличка? Или разные? И знаете на уровне приложения что сейчас надо идти в такую-то табличку, которая на таких-то шардах?
Прошёл?)
Ещё книжка Web Scalability for Startup Engineers. Вроде как, полегче кабанчика.
Набор задач - Grokking the System Design Interview
Телеграм канал - System Design World
Таблица прогресса по задачам с ключами решений от упомянутого neetcode:
https://docs.google.com/spreadsheets/u/0/d/1A2PaQKcdwO_lwxz9bAnxXnIQayCouZP6d-ENrBz_NXc/htmlview
Можно делать свою. Вроде как, позволяет лучше помнить, что сделал и как.
Думаю, это вопрос склонения.
Есть такие примеры:
Стань частью молодой и амбициозной команды Тинькофф
В видео рассказываю о личном опыте работы в Тинькофф
Как устроена работа представителя Тинькофф
Книга Web Scalability for Startup Engineers
Блог по подготовке к System Design Interview - System Design World