Warning: mkdir(): No space left on device in /var/www/tgoop/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/system_design_world/--): Failed to open stream: No such file or directory in /var/www/tgoop/post.php on line 50
System Design World@system_design_world P.83
SYSTEM_DESIGN_WORLD Telegram 83
📗 Книгу "Web scalability for startup engineers" советуют как более лёгкую, в сравнение с Клеппманом.
Встретил её совсем недавно.

Давайте по ней изучим Шардирование. Сделал перевод начала раздела стараясь выразить суть и уложится в формат поста телеграмма.

Сценарий
📈 Возрастают нагрузки на 1 сервер с Базой Данных. Необходимо разделить данные по серверам.

Проблема
➡️ Для получения данных, нужно не опрашивать все сервера, а пойти на целевой - где эти данные находятся.

Решение
🔑 Использовать ключ шардирования - сущность, которая позволит определить целевой сервер.

Пример
📦 Онлайн магазин. Сервис изначально имел одну Базу Данных. Для горизонтального масштабирования необходимо распределить данные по серверам.
Необходимо понять, по какому признаку произвести распределение. Поскольку пользователи в магазине не взаимодействуют друг с другом, можно распределить по пользователям.
Тогда при необходимости обновления или получения данных о пользователе запрос пойдёт в определенный инстанс БД.
Пользователя можно идентифицировать по полю user_id - уникальному идентификатору пользователя. Такой id и будет называться ключом шардирования.

Алгоритм шардирования
⚙️ Осталось понять какой user_id к какому серверу будет отнесен. Для этого выбирается алгоритм маппинга/роутинга/маршрутизации/распределения.
Для простоты, у нас есть 2 сервера БД == 2 шарда. В качестве алгоритма будет определение чётности.
Его можно реализовать с помощью операции взятия остатка от деления: user_id % 2 => 1, 0
Получаем распределение данных по признаку "чётности".
Шардировать можно средствами самой БД. Или же создать дополнительный слой/сервис для маршрутизации.

#Books #Sharding
👍3👏1



tgoop.com/system_design_world/83
Create:
Last Update:

📗 Книгу "Web scalability for startup engineers" советуют как более лёгкую, в сравнение с Клеппманом.
Встретил её совсем недавно.

Давайте по ней изучим Шардирование. Сделал перевод начала раздела стараясь выразить суть и уложится в формат поста телеграмма.

Сценарий
📈 Возрастают нагрузки на 1 сервер с Базой Данных. Необходимо разделить данные по серверам.

Проблема
➡️ Для получения данных, нужно не опрашивать все сервера, а пойти на целевой - где эти данные находятся.

Решение
🔑 Использовать ключ шардирования - сущность, которая позволит определить целевой сервер.

Пример
📦 Онлайн магазин. Сервис изначально имел одну Базу Данных. Для горизонтального масштабирования необходимо распределить данные по серверам.
Необходимо понять, по какому признаку произвести распределение. Поскольку пользователи в магазине не взаимодействуют друг с другом, можно распределить по пользователям.
Тогда при необходимости обновления или получения данных о пользователе запрос пойдёт в определенный инстанс БД.
Пользователя можно идентифицировать по полю user_id - уникальному идентификатору пользователя. Такой id и будет называться ключом шардирования.

Алгоритм шардирования
⚙️ Осталось понять какой user_id к какому серверу будет отнесен. Для этого выбирается алгоритм маппинга/роутинга/маршрутизации/распределения.
Для простоты, у нас есть 2 сервера БД == 2 шарда. В качестве алгоритма будет определение чётности.
Его можно реализовать с помощью операции взятия остатка от деления: user_id % 2 => 1, 0
Получаем распределение данных по признаку "чётности".
Шардировать можно средствами самой БД. Или же создать дополнительный слой/сервис для маршрутизации.

#Books #Sharding

BY System Design World


Share with your friend now:
tgoop.com/system_design_world/83

View MORE
Open in Telegram


Telegram News

Date: |

The optimal dimension of the avatar on Telegram is 512px by 512px, and it’s recommended to use PNG format to deliver an unpixelated avatar. Ng Man-ho, a 27-year-old computer technician, was convicted last month of seven counts of incitement charges after he made use of the 100,000-member Chinese-language channel that he runs and manages to post "seditious messages," which had been shut down since August 2020. Your posting frequency depends on the topic of your channel. If you have a news channel, it’s OK to publish new content every day (or even every hour). For other industries, stick with 2-3 large posts a week. With the administration mulling over limiting access to doxxing groups, a prominent Telegram doxxing group apparently went on a "revenge spree." In the “Bear Market Screaming Therapy Group” on Telegram, members are only allowed to post voice notes of themselves screaming. Anything else will result in an instant ban from the group, which currently has about 75 members.
from us


Telegram System Design World
FROM American