Auto sharding

https://habr.com/ru/companies/otus/articles/703790/

Ваша база данных — это первоисточник информации для бизнеса, и при принятии решений на ее основе рисковать не желательно. Хотя многие организации могут менять свою платформу несколько раз за период эксплуатации продукта, однако причиной вашей неуверенности становится то, что характер данных или то, как вы их используете, также может естественным образом эволюционировать с течением времени.

Если ваши данные неструктурированы или недостаточно хорошо структурированы, то преимущество варианта NOSQL очевидно, но если вы работаете со структурированными данными и/или будете выполнять много запросов, то вам лучше использовать SQL для обеспечения производительности, надежности и, возможно, соответствия нормативным требованиям.

SQL — это предметно-ориентированный язык, используемый для управления данными в реляционной системе управления базами данных (РСУБД - RDBMS). Он стабилен, существует с 1970-х годов, и работает. Есть причина, по которой он повсеместно распространен и сегодня.

Одним из преимуществ баз данных NOSQL, таких как MongoDB, например, традиционно является возможность горизонтального масштабирования по сравнению с SQL. При бессерверном подходе вертикальное масштабирование легко и практически доступно с любым вариантом SQL или NOSQL, находящимся в сфере возможностей вашего облачного провайдера.

Вертикальное масштабирование — это увеличение памяти или повышение производительности процессора для инстанса, и со временем вы столкнетесь с техническими аппаратными ограничениями в зависимости от поставщика облачных услуг.

Горизонтальное масштабирование, в свою очередь, с помощью SQL традиционно не реализуется. В отличие от него, MongoDB использует шардинг, что дает ей возможность создавать наборы реплик и, таким образом, осуществлять горизонтальное масштабирование.

Но что, если нам все-таки нужна база данных SQL для управления и доступа к структурированным данным и при этом мы хотим получить превосходную производительность и надежность, на которые мы рассчитывали? Неужели мы навсегда застряли с FOMO (синдром упущенной выгоды) горизонтального шардинга?

Существует технология, позволяющая устранить этот недостаток баз данных MySQL. Я говорю о Vitess, на которой работают многие крупнейшие и наиболее посещаемые сайты в Интернете, такие как YouTube, Pinterest, Slack и другие. Vitess — это ранний проект Go, который реализует горизонтальный шардинг и управляет им, повышает производительность запросов и устраняет накладные расходы памяти на соединения для баз данных MySQL.

Звучит здорово, правда? Я лично согласен! Но есть одна загвоздка: Vitess может быть достаточно сложным при внедрении в продакшн. Для успеха вам, скорее всего, понадобится команда инженеров с опытом работы в этой области.

PlanetScale функционирует на базе Vitess. Это наполовину обеспечивает его потрясающую эффективность, с моей точки зрения, поскольку они упростили для вас этот сложный процесс.

PlanetScale — это совместимая с MySQL бессерверная платформа баз данных с горизонтальным шардингом и неограниченным количеством соединений. Вертикальное и горизонтальное масштабирование больше не является проблемой, и это позволит вам обеспечить задел на будущее без каких-либо неудобств в этом плане.

Но есть еще одно преимущество PlanetScale, и я считаю его инновацией, которая устраняет еще один недостаток баз данных SQL: неблокируемые миграции схемы с нулевым временем простоя.

Миграции могут выводить разработчиков из равновесия. Когда все идет не так, как вы ожидаете, то в худшем случае это может привести к простою и потере данных.

Такое происходит.

Но как становится осуществима эта неблокируемая миграция схемы с нулевым временем простоя? С помощью ветвления (бранчинг — branching). Ветвление, вероятно, напомнит вам, как и мне, ту же концепцию, что и в случае с git branches (команда для управления ветвями в репозитории Git).

У вас есть ветвь, назовем ее main (главная), вы добавляете данные и переводите ее в продакшн. Схема теперь заблокирована, и будущие изменения схемы потребуют от вас создания development-ветви (разработки) main-ветви. Когда будет установлено, что в development-ветви нет конфликтов схем, вы сможете создать запрос на деплой, чтобы перевести ее в продакшн без каких-либо сбоев в работе вашего сервиса.

Мое впечатление от PlanetScale на данный момент таково: это высококачественный продукт, который может помочь вам с легкостью начать работу. Вы получаете самую передовую производительность и масштабирование. Мне также приятно, что он так хорошо работает с Prisma, внося лишь некоторые изменения в мой обычный рабочий процесс.

Это мой честный обзор и первые впечатления от PlanetScale. Ветвление и неблокируемая миграция схемы с нулевым временем простоя — это революционное решение, оно меняет правила игры, и я с нетерпением жду всего, что будет дальше.

Всех желающих приглашаем на открытое занятие «Алгоритмы распределенного консенсуса (RAFT, PAXOS)». На занятии разберем, для чего используются алгоритмы распределенного консенсуса и какие они бывают. Посмотрим, как работают алгоритмы RAFT, PAXOS, а также византийский консенсус. Регистрация открыта по ссылке.