1. Предпосылки

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

2. Что такое расчет? Что такое хранение?

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

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

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

Поскольку разделение вычислений и хранения является псевдотребованием, почему так много людей все еще упоминают об этом? Затем нам нужно переопределить их значение.Мы обобщаем хранение в процессе вычислений в вычисление, и фокусируемся только на проблеме и результате.Это наше новое определение «хранилища», точно так же, как когда мы сдаем экзамен, черновик не нужно хранить. , можно разорвать по желанию.

Затем здесь мы дадим окончательное определение.«Хранилище», о котором мы поговорим позже, должно быть постоянным, это может быть U-диск, жесткий диск, сетевой диск и т. Д. «Расчет», о котором мы говорим, на самом деле является нашим процессом расчета. , Требуемый процессор и память и т. д.

3. Почему вам нужно рассчитать разделение и хранение

Разделение вычислений и хранилище не является новым термином, который появился только сейчас. 20 лет назад произошел присоединенный хранилище NAS-сеть, который по существу является файловым сервером Ethernet, использующий протокол TCP / IP. В то время, если вы хотите широкомасштабное хранилище, у вас будет возможность сохранить данные на NAS, но NAS был чрезвычайно дорогим и сложно расширить, поэтому NAS не подходит для быстроразвивающихся интернет-приложений.

В это время Google отказался от предыдущей концепции «мобильное хранилище для вычислений» и принял концепцию «мобильные вычисления для хранения», чтобы объединить вычисления и хранилище, потому что скорость сети в то время была в сотни раз медленнее, чем сейчас. и скорость сети не может идти в ногу с нашими потребностями. В типичном развертывании MapReduce и вычисления, и хранение выполняются в одном и том же кластере, например, последующем Hadoop. Это фактически заменяет скорость передачи по сети локальной скоростью ввода-вывода.

С развитием технологий скорость нашей сети становится все быстрее и быстрее, нашим узким местом больше не является скорость сети, но скорость ввода-вывода на нашем диске значительно не увеличилась, а архитектурные недостатки интеграции вычислений и хранения постепенно становятся все больше и больше. Разоблачать:

Отходы машин: в первую очередь бизнес сталкивается с узким местом в вычислениях или хранении. Эти две ситуации часто различны, часто в разное время. В архитектуре есть определенное количество отходов. Если расчета недостаточно, добавьте машину, если хранилища недостаточно, добавьте машину. Так что здесь будет много мусора.
Соотношение машин необходимо часто обновлять: вообще говоря, конфигурация машин в компании относительно фиксирована, например, сколько ядер, сколько памяти, сколько места для хранения и так далее. Однако из-за постоянного развития бизнеса конфигурация нашей машины также нуждается в постоянном обновлении.
Расширение — дело непростое: если у нас недостаточно хранилища, нам обычно нужно расширяться, а если мы расширяемся в режиме связанных вычислений и хранения, нам нужно перенести большой объем данных.

Из-за растущего количества недостатков в соединении вычислений и хранения, а также в скорости сети архитектура теперь снова начинает развиваться в направлении разделения вычислений и хранения.

4. кто использует вычисления и хранилище изолированно

Выше мы говорили о большом количестве теоретических знаний, я думаю, что у всех уже есть определенное понимание «разделения вычислений и хранения», так где же это используется? Есть две части, которые имеют относительно большое влияние, одна — это база данных, а другая — очередь сообщений.Далее я конкретно расскажу о том, как эти две части используют «разделение вычислений и хранения».

4.1 База данных

Когда дело доходит до баз данных, мы должны думать о MySql, которая также должна быть наиболее знакомой базой данных.Ниже приведена диаграмма архитектуры master-slave Mysql:

Видно, что наш мастер получает изменения данных, наша база данных считывает информацию binlog и воспроизводит binlog для репликации данных. В архитектуре master-slave Mysql есть много проблем:

Когда давление записи основной библиотеки относительно велико, задержка репликации master-slave станет относительно высокой.Поскольку мы реплицируем binlog, он завершит все транзакции.
Скорость добавления подчиненных узлов низкая, потому что нам нужно скопировать весь объем данных на подчиненные узлы.Если на главном узле в это время много данных, скорость расширения подчиненного узла будет очень медленной и высокой. .
Для баз данных с большим объемом данных скорость резервного копирования очень низкая.
Стоимость становится выше.Если емкость нашей базы данных относительно велика, то емкость всех наших соответствующих подчиненных узлов должна быть такой же большой, как база данных свиньи, и наша стоимость будет увеличиваться линейно с количеством необходимых нам подчиненных баз данных.

Все эти проблемы, кажется, ведут нас к разделению вычислений и хранения, что позволяет всем узлам совместно использовать одно хранилище. В 2014 году на конференции AWS компания AWS объявила о запуске Aurora. Это совместимое с MySQL ядро базы данных для сервиса реляционных баз данных (RDS) Amazon, и Aurora идеально подходит для систем баз данных корпоративного класса в отношении высокой доступности, производительности и масштабируемости, а также для размещения облачных сервисов. Текущая версия Aurora поддерживает 6-стороннюю репликацию в 3 зонах доступности, аварийное переключение в течение 30 секунд и быстрое восстановление после сбоя. С точки зрения производительности Aurora теперь в 5 раз быстрее, чем версии RDS MySQL 5.6 и 5.7.

Aurora превращает уровень хранения MySQL в независимый узел хранения.В Aurora журналы рассматриваются как данные, и журналы полностью извлекаются из вычислительного узла Mysql, который хранится узлом хранения, а также отменяется отмена журнала для уменьшения Расчет взаимодействия пропускной способности хранения и передачи данных.

Точно так же команда Али также позаимствовала идеи Aurora и сделала много оптимизаций.Поскольку механизм хранения Aurora Mysql-Innodb был сильно модифицирован, последующее обновление Mysql неизбежно будет стоить дорого.Поэтому команда Али запустила PolarDB на основе сохранения исходного пути ввода-вывода MySQL. Схема его архитектуры выглядит следующим образом:

Здесь нам нужно обратить внимание на следующие вещи:

libfis: это библиотека файловой системы, которая предоставляет интерфейс API для вычислительных узлов для доступа к базовому хранилищу и выполнения таких операций, как чтение и запись файлов и обновление метаданных.При этом вычислительным узлам не нужно заботиться о том, где хранятся данные. является.
ChunkServer можно рассматривать как независимый подузел хранения.Каждый ChunkServer управляет жестким диском SSD.Несколько ChunkServer образуют узел хранения Polardb.Что касается вычислительных узлов, его нужно рассматривать только как большой узел хранения.
PolarSwitch: это демон, развернутый на вычислительном узле.Он отвечает за получение файловых запросов ввода-вывода, отправленных libpfs.PolarSwitch делит его на один или несколько соответствующих фрагментов и отправляет запросы на ChunkServer, к которому принадлежит фрагмент, для завершения доступа .

Конечно, у PolarDB есть много других деталей.Если вам интересно, вы можете прочитать официальные документы Alibaba Cloud.Благодаря этому методу общего хранилища мы можем создавать различные приложения конфигурации в соответствии с нашим собственным бизнесом.Например, наши требования к параллелизму не высок. , требования к объему данных велики, тогда мы можем подать заявку на большой объем памяти, а вычислительные ресурсы могут быть относительно небольшими. Если у нас высокие требования к параллелизму, особенно запросы на чтение, то мы можем подать заявку на несколько читающие машины, пока наши требования не будут выполнены.

На самом деле не только эти, многие БД сейчас постепенно приближаются к "разделению вычислений и хранения", в том числе и нынешняя OceanBase , ТиБД и т.д. Поэтому «разделение вычислений и хранения» должно стать основным направлением развития будущих баз данных.

4.2 Очередь сообщений

Я написал много статей о очереди сообщений раньше, есть кафка, и RocketMQ, будь то кафка или Rocketmq его идея дизайна состоит в том, чтобы сохранить очередь сообщений с локальной машиной, поэтому на самом деле это определенный недостаток:

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

В ответ на эти проблемы появился Apache Pulsar, pulsar изначально разрабатывался Yahoo.В 2018 году Kafka одним махом два года подряд выигрывал награду InfoWorld за лучшую платформу данных с открытым исходным кодом.

В архитектуре Pulsar вычисления данных и хранение данных представляют собой две отдельные структуры:

Обработка данных также называется Broker. Его функция аналогична функции брокера Kafka. Он используется для балансировки нагрузки, обработки потребителей и производителей и т. д. Если в бизнесе слишком много потребителей и производителей, мы можем расширить этот уровень отдельно.
Хранилище данных Bookie, pulsar использует систему хранения Apache Bookkeeper и не слишком заботится о деталях хранения.На самом деле, мы также можем извлечь из этого уроки.При проектировании такой системы нам нужно перейти к деталям вычислений услуги сами.Подумайте о дизайне, и система хранения может использовать более зрелое решение с открытым исходным кодом.

Теория Пульсара в теории оказывается, что наши новости могут быть сохранены навсегда. Кто-нибудь говорит, что жесткий диск не хочет денег? Конечно, мы все еще хотим денег. В Пульсаре вы можете стрелять, мы перемещаем старые новости дешевой схеме хранения, такие как хранение AWS S3, и наши текущие последние новости все еще в наших более дорогих SSD. В этом режиме он не только хранится, но наши вычислительные расширения ресурсов также неограниченные, поскольку наши вычислительные ресурсы являются в основном без гражданства, расширение не стоит, поэтому Pulsar также имеет функцию мультиреанта. Без установления кластера Для каждой команды верно, что это правда в группе США. Сравнить BG в основном имеет свой собственный кластер Mafka, чтобы предотвратить взаимное влияние.

Некоторые из последних предложений Kafka также приближаются к этим аспектам. Например, они также обсуждают, поддерживать ли многоуровневое хранилище. Конечно, принятие архитектуры «разделения вычислений и хранения» не обязательно, но я думаю направление «разделение вычислений и хранения» Это также основное направление будущего развития очередей сообщений.

Суммировать

С развитием облачных вычислений «разделение вычислений и хранения» появляется все больше и больше в различных системах.Я надеюсь, что вы сможете получить простое представление об этом после прочтения этой статьи. В то же время при проектировании системы в дальнейшем эту схему также можно рассматривать как один из вариантов.

Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O: