Шардирование в HighLoad-системах
Как поступить, если данные больше не влезают на один сервер? Существуют 2 классических механизма масштабирования:
- Вертикальное масштабирование. Мы просто добавляем на сервер память и диски. Эффективно, но имеет свои пределы, например, мы ограничены по числу ядер на процессор, по числу самих процессоров, ну и, разумеется, по объёму памяти.
- Горизонтальное масштабирование. Мы применяем много машин, распределяя данные между ними. Наборы таких машин называют кластерами. Если мы хотим поместить данные в кластер, нам надо их шардировать — определить для каждой записи, на каком именно сервере она будет размещена.
Параметр, по которому наши данные распределяются между серверами (к примеру, идентификатор клиента либо организации), называют ключом шардирования.
Давайте представим, что нам надо записать в кластер информацию про всех жителей планеты. В роли ключа шарда мы можем взять, допустим, год рождения человека. В таком случае нам будет достаточно 116-ти серверов (правда, каждый год нам придётся добавлять новый сервер). Также мы можем взять в виде ключа страну проживания — тогда потребуется около 250-ти серверов. Однако первый вариант предпочтительнее, ведь дата рождения человека, в отличие от страны проживания, не меняется, следовательно, перекидывать данные о человеке между серверами не придётся.
Если речь идёт о работе облачной системы, например, по автоматизации бизнес-процессов, то здесь в качестве ключа шардирования можно взять и организацию. Но компания компании рознь, ведь организации отличаются по размеру и количеству пользователей. Присваивая организации определенный сервер, мы заранее не знаем, насколько она вырастет. А если компания использует сервис очень активно, может наступить момент, что её данные не будут вмещаться на один сервер, следовательно, придётся делать решардинг. А это уже совсем непросто, особенно если таких данных — терабайты. А теперь представьте хайлоад-систему, где каждую секунду осуществляются транзакции. Как перемещать данные с места на место в таких условиях? И остановить систему смерти подобно, ведь большие объёмы данных могут перекачиваться несколько часов, а бизнес-заказчики вряд ли переживут столь долгий простой.
Совет тут один — лучше всего в качестве ключа шардирования выбирать данные, которые меняются редко. К сожалению, далеко не всегда прикладная задача позволяет нам легко это сделать.
Статья подготовлена по материалам блога компании Pyrus.