В прошлом, когда мы хотели хранить больше данных или увеличить вычислительную мощность, общим вариантом было вертикальное масштабирование (получить более мощные машины) или дальнейшая оптимизация преобладающей кодовой базы. Однако, с развитием многопроцессорных и распределенных систем, более распространенным было горизонтальное расширение или увеличение количества машин, чтобы попытаться решить эквивалентную задачу параллельно. Мы уже увидим кучу инструментов для манипулирования знаниями в рамках проекта Apache, таких как Spark, Hadoop, Kafka, Zookeeper и Storm. Однако, для того, чтобы эффективно подобрать инструмент выбора, важна базовая идея CAP Theorem. CAP Theorem может быть концепцией, что система распределенных баз данных может иметь только 2 из 3: Согласованность, Доступность и Толерантность разделов.

https://miro.medium.com/max/400/1*WPnv_6sG9k4oG3S1A09MDA.jpeg

CAP Theorem чрезвычайно важен в мире Больших данных, особенно после того, как мы должны сделать компромисс между тремя, поддержал наш уникальный случай использования. В этом блоге я смогу попытаться объяснить каждую из этих концепций и, следовательно, причины такого компромисса. Я смогу избежать использования конкретных примеров, так как СУБД быстро развивается.

Раздел Толерантность

https://miro.medium.com/max/731/1*qVoJNWH1osbrnOizRivF1A.png

Это условие гласит, что система продолжает работать, несмотря на количество сообщений, задерживаемых сетью между узлами. Система, устойчивая к разделам, может выдержать любое количество сетевых сбоев, которые не заканчиваются отказом всей сети. Записи данных в достаточной степени реплицируются по комбинациям узлов и сетей, чтобы система не выходила из строя из-за прерывистых сбоев. При работе с современными распределенными системами, толерантность разделов не является вариантом. Это необходимость. Следовательно, мы должны торговать между Согласованность и доступность.

Высокая Согласованность

https://miro.medium.com/max/864/1*UnG2G7_h0kqI9IHtnUk3qg.png

Это условие гласит, что каждый из узлов видит эквивалентные данные в эквивалентное время. Проще говоря, выполнение операции чтения вернет стоимость самой последней операции записи, в результате чего все узлы вернутся к эквивалентным данным. Система имеет консистенцию, если транзакция начинается с системой во время консистентного состояния и заканчивается с системой во время консистентного состояния. При такой модели система может (и может) перейти в противоречивое состояние во время выполнения транзакции, но при ошибке на любом этапе процесса вся транзакция откатится назад. Внутри изображения мы имеем 2 разные записи (“Бульбазавр” и “Пикачу”) на разных временных метках. Вывод на третий раздел – “Пикачу”, самый новый вход. Однако, для обновления узлов потребуется время, и они не могут быть так часто доступны в сети.

Высокая доступность

https://miro.medium.com/max/841/1*ABrjUrZAY6V1hEkFPYvC7A.png

Это условие гласит, что каждый запрос получает ответ об успехе/неудаче. Достижение доступности во время распределенной системы требует, чтобы система оставалась работоспособной 100% времени. Каждый клиент получает ответ, независимо от состояния человеческого узла в системе. Эта метрика тривиальна для измерения: либо вы будете подавать команды на чтение/запись, либо нет. Следовательно, базы данных не зависят от времени, потому что узлы должны быть доступны в режиме онлайн в наименьшие сроки. Это говорит о том, что, в отличие от предыдущего примера, мы не знаем, был ли первым добавлен “Пикачу” или “Бульбасаур”. Вывод может быть любым из них. Поэтому высокая доступность при анализе потоковых данных с высокой частотой нецелесообразна.

Заключение

Распределенные системы позволяют нам реализовать такой уровень вычислительной мощности и доступности, который был просто недоступен в прошлом. Наши системы имеют более высокую производительность, более низкую задержку и почти 100% время безотказной работы в центрах обработки данных, которые охватывают весь земной шар. Лучше всего то, что современные системы работают на товарном оборудовании, которое легко доступно и конфигурируется по доступной цене. Однако есть цена. Распределенные системы сложнее, чем их односетевые аналоги. При горизонтальном масштабировании важно понимать сложность, возникающую в распределенных системах, делать приемлемые компромиссы для поставленной задачи (CAP), а также подбирать подходящий инструмент для работы.