Сказка из производительности базы данных в масштабе
8 августа 2025 г.Производительность базы данных является серьезным бизнесом, но почему бы не немного повеселиться, изучая его проблемы и сложности? 😉 Вот довольно причудливая история, которую мы представили в главе 1Производительность базы данных в масштабе, бесплатная книга открытого доступаПолем
Технические темы, рассмотренные здесь, расширены на протяжении всей книги. Но это единственный раз, когда мы говорим о бедном Патрике. Пусть его борьба принесет вам несколько ценных уроков, утешение в вашей собственной базе данных о предложениях о производительности базы данных ... и, может быть, также несколько смешков.
***
Потеряв работу в компании Faang Maang (Manga?), Патрик решил самостоятельно снять и основал нишевой интернет -магазин, посвященный обмену его абсолютному фавориту среди головных уборов, Green Fedoras. Заметив, что определенная база данных NOSQL недавно была в тренде на первой странице Hacker News, Патрик выбрал ее для своего бэкэнд -стека.
После некоторых экспериментов с бесплатным уровнем предложения Патрик решил подписать однолетний контракт с крупным поставщиком облаков, чтобы получить значительную скидку на предложение базы данных NOSQL как услуги. Благодаря обеспечению пропускной способности, способной обслуживать до 1000 клиентов каждую секунду, технологический стек был готов, и магазин открыл свои виртуальные двери для клиентов. К разочарованию Патрика, менее десяти клиентов ежедневно посещали сайт. В то же время, новый блестящий кластер базы данных продолжал работать, заправленный постоянным притоком денег из его кредитной карты и ожидая использования его потенциала.
Дневник извлеченных уроков Патрика, часть I
Уроки начались сразу:
- Хотя некоторые базы данных рекламируют себя как универсальные, большинство из них работают лучше всего для определенных видов рабочих нагрузок. Анализ перед выбором базы данных для ваших собственных потребностей должен включать оценку характеристик вашей собственной рабочей нагрузки:
- Вероятно, будет ли это предсказуемый, устойчивый поток запросов (например, обновления, извлекаемые из других систем периодически)?
- Является ли дисперсия высокой и трудной для прогнозирования, а система простаивает в течение потенциально длительных периодов времени, со случайными ударами активности? Предложения базы данных как услуга часто позволяют выбирать между пропускной способностью и покупкой по требованию. Хотя первое является более экономичным, он несет определенную стоимость независимо от того, насколько занята база данных. Последний стоит дороже за запрос, но вы платите только за то, что используете.
- Дайте себе время, чтобы оценить свой выбор и избежать совершения долгосрочных контрактов (даже если вы заманивают скидкой), прежде чем вы увидите, что настройка работает для вас устойчивым образом.
Первый всплеск
17 марта казался чрезвычайно счастливым днем. Патрик был рад заметить множество новых заказов, начиная с раннего утра. Но когда количество активных клиентов взлетело за полдень, настроение Патрика начало ухудшаться. Это было строго коррелировано с температурой звонков, которые он получил от гневных клиентов, сообщающих о своей неспособности выполнить свои заказы.
После короткого мозгового штурма с самим собой и веб -поисковой системой, Патрик понял, к своему ужасу, что ему не хватало каких -либо инструментов наблюдения в своем драгоценном (и довольно дорогого) кластере баз данных. Вскоре после того, как лихорадочно установить Графана и просмотр метрик, Патрик увидел, что, хотя количество входящих запросов продолжало расти, их успех был ограничен на определенном уровне, что намного ниже ожидаемого трафика сегодняшнего дня.
«Случай пропускной способности снова», - застонал Патрик для себя, прокручивая тысячи сообщений об ошибках «пропускная способность превышенной», которые начали появляться около 11 часов утра.
Дневник извлеченных уроков Патрика, часть II
Это то, чему узнал Патрик:
- Если ваша рабочая нагрузка подвержена шипам, будьте готовы к ней и постарайтесь архитектуры вашего кластера, чтобы выжить временно повышенную нагрузку. Решения в области базы данных как услуга, как правило, позволяют динамично настраивать пропускную способность, что означает, что порог принятых запросов может иногда временно подниматься до ранее настроенного уровня. Или, соответственно, они позволяют временно уменьшаться, чтобы сделать решение немного более экономичным.
- Всегда ожидайте шипов. Даже если ваша рабочая нагрузка абсолютно устойчивая, временный аппаратный сбой или неожиданная атака DDOS может привести к резкому увеличению входящих запросов.
- Наблюдение является ключевым в распределенных системах. Это позволяет разработчикам ретроспективно исследовать неудачу. Он также обеспечивает оповещения в режиме реального времени, когда обнаружен вероятной сценарий неудачи, что позволяет людям быстро реагировать и либо предотвратить больший сбой, либо, по крайней мере, минимизировать негативное влияние на кластер.
Первая потеря
Патрику даже не удавалось оправиться от травмы потери большей части своего потенциального дохода в единственный день в течение года, в течение которого Зеленая Федора испытывал какой -либо вид спроса, когда появилось письмо. Это включало гневную напыщенную речь от потенциального клиента, который успешно приступил к своему заказу и заплатил за него (с квитанцией от оператора обработки платежей в качестве доказательства), но теперь не может увидеть никаких подробностей своего заказа-и он все еще ждет доставки!
Без лишних слов Патрик просмотрел базу данных. К его удивлению, он тоже не нашел никаких следов порядка. Для полноты, Патрик также применил свое желаемое мышление на практике, просматривая каталог резервного снимка. Это оставалось пустым, так как одно из первоначальных исполнительных решений Патрика было сэкономить время и деньги, не планируя каких -либо периодических процедур резервного копирования.
Как с ним произошла потеря данных всех людей? После изучения модели согласованности по выбору в базе данных Патрик понял, что существует консенсус между гарантиями согласованности, производительности и доступностью. Настройка запросов, можно либо потребовать либо линейность, основанную на выходе из стоимости снижения пропускной способности, либо снизить гарантии согласованности и соответствующим образом повысить производительность. Более высокие возможности пропускной способности были нелегкими для Патрика несколько дней назад, но в конечном итоге данные клиентов приземлились на одном сервере без каких-либо реплик, распределенных в системе. Как только этот сервер не удастся - что случается с оборудованием на удивление часто, особенно в масштабе, данные исчезли.
Дневник извлеченных уроков Патрика, часть III
Дальнейшие уроки включают:
- Резервные копии жизненно важны в распределенной среде, и нет такого понятия, как установление резервных процедур «слишком рано». Системы терпят неудачу, и резервные копии существуют, чтобы восстановить как можно больше важных данных.
- Каждая система баз данных имеет определенную модель согласованности, и при разработке вашего проекта крайне важно учитывать это. Там могут быть компромиссы, чтобы сделать. В некоторых вариантах использования (например, финансовые системы) последовательность является ключом. В других из них приемлемость, если она сохраняет систему очень доступной и отзывчивой.
Спайк снова поражает
Прошли месяцы, и график сна Патрика даже начал показывать признаки стабилизации. С регулярными резервными копиями, моделью консистенции переработанной консистенции и напоминанием в его календаре на 16 марта, чтобы расширить кластер для управления повышенным трафиком, он чувствовал себя умеренно безопасным.
Если бы только он знал, что десятисекундное видео о кошке, одетой как лепрекоун, только что стало вирусным в Малайзии ... что, учитывая часовой пояс, произошло около 2 часов утра Патрика, разрушив вышеупомянутые усилия по стабилизации сна.
С одной стороны, набор наблюдений выполнял свою работу и рано отложил предупреждение, что позволило бы быстро получить быстрый ответ. С другой стороны, хотя Патрик отреагировал вовремя, базы данных редко могут масштабироваться мгновенно, и его система выбора в этом отношении не была исключением. Спайк в одновременном месте был очень высоким и концентрированным, поскольку тысячи малазийских подростков бросились к зеленым шляпам на объемах, чтобы стремиться к постоянно меняющимся интернет-тенденциям. Патрик смог соблюдать реальную экземплярЗакон Литтл, который он смутно помнил со своих дней в университете. С красивой краткой формулой, l = λw, закон может быть упрощен до того факта, что параллелизм равняется задержке времени пропускной способности.
КОНЧИК:Для тех, кто испытывает проблемы с запоминанием формулы, подумайте. Параллелизм - это всего лишь число, задержка может быть измерена в секундах, в то время как пропускная способность обычно выражается в 1/с. Затем вызывает разбор, что для того, чтобы подразделения соответствовали, параллелизм должен быть получен путем умножения задержки (секунд) на пропускную способность (1/с). Пожалуйста!
Пропускная способность зависит от аппаратного обеспечения и, естественно, имеет свои пределы (например, вы не можете ожидать, что диск NVME, приобретенный в 2023 году, будет обслуживать данные для вас в терабайтах в секунду, хотя мы пересекаем пальцы, чтобы это предположение было недействительным в ближайшем будущем!)) Тогда ясно, что по мере роста параллелистики, как и задержка. Для конечных пользователей-малайзийских подростков в этом сценарии-это означает, что задержка в конечном итоге будет преодолеть магический барьер для среднего человеческого восприятия нескольких секунд. Как только это произойдет, пользователи слишком расстроены и просто отказываются от проборов вообще, предполагая, что система нарушается до ремонта. Легко найти онлайн -статьи, цитируя, что «Amazon обнаружил, что 100 мс задержки стоит им 1 процент в продажах»; Хотя это звучит слишком упрощено, это также достаточно верно.
Дневник извлеченных уроков Патрика, часть IV
Уроки продолжаются:
- Неожиданные шипы неизбежны, и масштабирование кластера может быть недостаточно быстрым, чтобы смягчить негативные последствия чрезмерной параллелистики. Ожидание, что база данных будет правильно обработать ее, не без заслуг, но не каждая база данных способна. Если возможно, ограничивайте параллелизм в вашей системе как можно раньше. Например, если база данных никогда не затрагивается непосредственно клиентами (что является очень хорошей идеей по нескольким причинам), но вместо этого доступ к набору микросервисов под вашим управлением, убедитесь, что микросервисы также знают о пределах параллелизма и придерживаются их.
- Имейте в виду, что закон Литтл существует - это фундаментальные знания для всех, кто заинтересован в распределенных системах. Цитирование его часто также заставляет вас выглядеть исключительно умным среди сверстников.
Резервное копирование возвращается
После перепроектирования своего проекта снова принять ожидаемые и неожиданные колебания параллелистики, Патрик с радостью ждал, когда его бизнес Fedora, наконец, станет прибыльным раменом.
К сожалению, следующее 17 марта не прошло так гладко, как и ожидалось. Патрик провел большую часть дня, наслаждаясь устойчивыми панелями Grafana, которые продолжали уверять его, что трафик находится под контролем и способен обрабатывать нагрузку клиентов со здоровой безопасной маржой. Но затем приборные панели остановились, любезно упомянув, что диски стали сильно переоценены. Это казалось совершенно неуместным, учитывая наблюдаемое параллелизм. В поисках возможного источника этой аномалии Патрик заметил, к своему ужасу, что запланированная процедура резервного копирования совпала с годовой пиковой нагрузкой…
Дневник извлеченных уроков Патрика, часть V
Заключительные мысли:
- Системы баз данных вряд ли когда -либо простаивают, даже без входящих пользовательских запросов. Операции по техническому обслуживанию часто происходят, и вы должны принять их во внимание, потому что они являются внутренним источником параллелизма и потребления ресурсов.
- Когда это возможно, планируйте варианты технического обслуживания на время с ожидаемым низким давлением на систему.
- Если ваша система управления базой данных поддерживает какое -либо качество конфигурации обслуживания, рекомендуется исследовать такие возможности. Например, можно было бы установить сильный приоритет для запросов пользователей в отношении регулярных операций по техническому обслуживанию, особенно в часы пик. Соответственно, периоды с низкой деятельностью, вызванной пользователем, могут быть использованы для ускорения фоновых действий. В мире баз данных системы, которые используют вариант деревьев LSM для базового хранилища, должны выполнять довольно много уплотнений (своего рода операции обслуживания в данных), чтобы сохранить производительность чтения/записи предсказуемой и устойчивой.
Конец.
О ПИОТР САРНА
Piotrявляется инженером-программистом, который заинтересован в проектах с открытым исходным кодом и языками Rust и C ++. Ранее он разработал распределенную файловую систему с открытым исходным кодом и имел краткое приключение с ядром Linux во время обучения в Samsung Electronics. Он также давний участник и сопровождающий Scylladb, а также Libsql. PIOTR окончил Университет Варшавы с степенью магистра в области компьютерных наук. Он является соавтором книг «Производительность базы данных в масштабе» и «Письмо для разработчиков: блоги, которые читаются».
Оригинал