Рассмотрим блох. Это крошечное существо, едва видимое невооруженным глазом. И все же он мощный, способен прыгнуть более 100 раз большую длину тела. А теперь представьте, что масштабируйте блохи до размера человека. Предположим, что вы можете сделать его физически идентичным своей меньшей форме, просто больше в каждом измерении.
Этот масштаб Super Flea может прыгнуть на тридцатиэтажное здание. Но это не может. Причина касается принципа биомеханики, называемого законом о квадратном кубике. По мере того, как блох «масштабируется», ее объем (масса) увеличивается быстрее, чем площадь поверхности. Чем больше он растет, тем менее способным он поддерживает себя. В конце концов, блохня рухнет под его весом.
Урок? Вы не можете просто расширить маленький, чтобы получить гигантскую блох. Вам нужно спроектировать другую блоху.
Что -то подобное верно в отношении масштабируемости и архитектуры базы данных. Система, оптимизированная для обеспечения производительности X в небольшом масштабе, вероятно, не обеспечит 10 000 -кратную производительность в масштабе 10 000x. Его производительность, вероятно, ухудшатся по мере роста. По мере увеличения количества узлов и ссылок, так же сложность управления базой данных. В первую очередь это связано с повышенной потребностью в управлении распределением данных и межзметочной связи и поддержанием согласованности во всех узлах. Это может привести к задачам конфигурации, мониторинга и устранения неполадок, особенно в больших кластерах со многими узлами. Чем больше узлов вы добавляете, тем тяжелее он становится, чтобы отслеживать, где находятся данные и как эффективно получить к ним доступ через кластер.
Характер оперативной сложности
Сложность имеет два основных источника: технологические и оперативные. Как следует из названия, технологическая сложность относится к чисто техническим аспектам создания системы, которая может работать в масштабе. Они могут включать автоматизацию масштабирования, управления контейнерами, распределение хранилища, обеспечивающие сложные сети и операции по абстрагированию ручных операций. Большинство людей думают об этих проблемах, когда думают о масштабировании программного обеспечения.
Оперативная сложность является обратной стороной технологической сложности. Это относится к сложности управления и использования системы в масштабе. Это время и налог на рабочую силу, которую технологическая система налагает на своих операторов. Это вся работа, которая не автоматизирована, но должна быть выполнена для работы системы. Поскольку он охвачен человеческим фактором, который трудно количественно оценить, оперативная сложность менее ценится и понятна, чем технологическая сложность. Тем не менее, я бы сказал, что это так же важно.
В облаке мы выяснили, как создавать базы данных, которые могут расти столь же большими, как любой хочет. Аннотация умоливающая сложность гиперспектной инфраструктуры, облако позволило создавать технологически простые системы, обеспечивая «скорость и корма», которые были бы ошеломляющими только короткое время назад.
Это звучит великолепно. Но есть недостаток. Мы создали базы данных, которые могут технически работать в любом размере, но не практические для работы в масштабе. Как индустрия, мы все еще боремся с человеческими проблемами управления и управления гиперсмассовыми системами.
Оперативная сложность — шар
Классическим примером этого явления является Sharding, которая является практикой подразделения хранилища данных в более управляемые фрагменты. Наиболее распространенная форма шарда, «наивное осколок», предполагает равномерное распределение данных (важное предположение, но мы доберемся до этого). Выступление фантастическое. Задержка низкая. Пропускная способность высока. Все хорошо. С технологической точки зрения, Sharding кажется отличным способом поддерживать производительность по мере роста базы данных.
С оперативной точки зрения, он выглядит по -разному. Оболочник базы данных создает новую проблему: поиск данных в осколках. В наивном шарнинге база данных не знает, где живет данная часть данных. Информация о «шарнинге» живет на уровне приложения. Это означает, что отслеживание данных теперь является проблемой разработчика.
Когда база данных относительно мала, скажем, 10 ГБ, а количество осколков относительно немного, это управляемая задача. Но теперь база данных выросла до 100 ГБ или 200 ГБ. Каждый осколок теперь во многом больше размер всей базы данных, когда произошло начальное осколок. Данные больше не распределены между осколками. Как следствие, начинают появляться массивные горячие точки. Производительность падает. Пришло время сбросить базу данных.
Теперь операционная сложность начинается. Данные должны быть перераспределены вручную и перебалансированы, создавая новые клавиши Shard. Шарки, которые уже прилагаются в существующие приложения, должны быть обновлены, потому что шардинг в этом дизайне явно. Приложение должно знать о местоположении данных. Каждая строка кода, которая использует шарнинг, должна быть рассмотрена. Данные, которые жили на одном и том же осколках до сейчас, должны быть назначены вручную для отдельных осколков, и код должен быть переработан соответствующим образом.
Эта задача — кошмары. Никакая Grep Find и замена не может обрабатывать его автоматически. Благодаря их ограничениям люди должны бороться с созданием оперативной сложности.
Оперативная сложность — масштабирование
Оперативная сложность увеличивается, когда организация добавляет серверы или узлы в систему. Узлы обычно добавляются для избыточности и совместного использования нагрузки, поэтому изменения на одном узле должны быть отражены на других, или данные должны быть распределены, чтобы избежать горячих точек. Перемещение данных такая же, как и зарядка. Вы хотите, чтобы движение данных в кластере было невидимым для пользователя. Это задача распределенных узлов Front-Tend SQL, чтобы получить данные из какого-либо узла, на котором он находится.
В большинстве баз данных, в том числе MySQL, изменение, совершенное в один узел, может, в худшем случае, потребуется секунды или даже минуты, чтобы зарегистрироваться на других из -за задержки репликации. В качестве примера, одним из виновников отставания репликации является DDL. Операция DDL на первичном узле может блокировать распространение событий в узлы последователей. В результате, до тех пор, пока изменение не распространилось во всех узлах в базе данных, пользователь может увидеть разные результаты, в зависимости от того, на какой узел направлен их запрос. Это компромисс, известный как «возможная последовательность». Это правило с MySQL и Amazon Aurora, MySQL Postgres и любыми базами данных, основанными на модели MySQL. (Mysql Group Replication, технически, предлагает интенсивный режим согласованности, но редко используется, поскольку документация указывает на то, что его следует использовать на собственном риске.)
Почему это имеет значение? Это, вероятно, не так, если рассматриваемое изменение является «похожим» на социальном посте. Но если кто -то снимает деньги из своего банка или пытается войти после изменения своего пароля, очень важно, имеет ли у каждого узла одинаковую информацию одновременно.
Здесь снова бремя падает на разработчика. Поскольку базовая система не гарантирует сильную согласованность, разработчику необходимо разработать обходной путь в коде. Эти ограничения не очевидны в базе данных с одним узлом. Они являются результатом архитектурных решений, которые имеют смысл в меньшем масштабе. Тем не менее, этот более слабый режим согласованности делает работу разработчика труднее и сложнее по мере роста системы.
Компромиссы и решения
В области разработки программного обеспечения, как и в жизни, нет бесплатного обеда. Свалить на автоматизацию и абстракцию (т.е. технологическую сложность), и вы получаете более операционную сложность. Упростить операции, и вам нужна более сложная технология для компенсации. База данных NOSQL MongoDB была частично вдохновлена разочарованием операциями DDL на основе схемы. Тем не менее, разделение схем, как это делают MongoDB и другие решения NOSQL, создают проблемы масштабируемости. Среди других вопросов аналитика делает аналитику гораздо более сложной для участия в крупной организации. Как я писал в другом месте, именно поэтому реализации NOSQL, как правило, терпят неудачу в масштабе. Это не потому, что им не хватает чистого технологического потенциала, а потому, что у них возникают проблемы с удовлетворением оперативных потребностей крупного предприятия.
Сложность неизбежно. Это просто вопрос того, какую форму она принимает, в каких пропорциях — и кто «платит» за это. Мы не можем устранить технологическую и оперативную сложность, но мы можем попытаться найти середину между крайностями.
Самыми последними попытками сделать это являются распределенные решения SQL, такие как Tackroachdb и TIDB, на основе технологии проекта Google Spanner. Распределенные системы SQL полагаются на традиционную реляционную схему, но автоматизируют горизонтальный масштаб, репликацию DDL и другие функции, которые исторически ограничивали способность структурированных баз данных. Распределенный SQL не стремится достичь довольно необработанных уровней скорости хранения и поиска. База данных NOSQL может предоставить или воспроизвести простоту простоты базы данных MySQL с одним узлом. Цель состоит в том, чтобы найти место между производительностью (то есть скоростью, задержкой), надежностью, универсальностью и простотой управления. На практике это означает увеличение технологической сложности под капотом, чтобы снизить налог на оперативную сложность у конечного пользователя.
Прямо сейчас большинство больших систем данных похожи на наш гипотетический гигантский блох, на стадии, где не хватает. Они по -прежнему узнаваемы сами. Но они функционируют хуже, чем когда были меньше. И чем больше они получают, тем хуже они делают.
Большая часть разработки базы данных посвящена переоценке блоши. Это может занять множество форм. Распределенный SQL является одним из подходов, а другие возможны. Однако они подходят к проблеме, они должны найти решение для оперативной сложности. То, что у нас есть сейчас, это масштаб на бумаге. Что нужно предприятиям, так это масштаб на практике.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Sunny Bains — архитектор программного обеспечения в Pingcap, компании TIDB. Он работал над хранилищами более 22 лет. Его первое знакомство с работой ядра базы данных было в 2001 году, когда ему было поручено написать … Подробнее от Sunny Bains
