Ниже приводится выдержка из главы 1 База данных в масштабе (книга с открытым доступом, доступная бесплатно).Следуйте очень вымышленным приключениям Джоан с некоторыми слишком реальными вызовами для производительности баз данных. Вы будете смеяться. Вы будете плакать. Вы будете удивляться, как мы превратили эту "черную историю" в глубоко техническую книгу. База данных в масштабе Привлекшись впечатляющими шутками, такими как «гибридное облако», «безсерверное» и «крайнее первое», Джоан легко присоединилась к новой компании и начала поймать свой технологический запас. Ее первый проект недавно начал переход от их внутреннего внедрения системы баз данных, которая, как оказалось, не масштабируется в том же темпе, что и количество клиентов, к одному из стандартных решений для управления базами данных в отрасли. гарантии, известные в мире SQL. кислоты Из-за нескольких новых законов о защите данных, которые, как правило, появляются ежегодно в наши дни, совет директоров компании решил, что они будут поддерживать свой собственный дата-центр, а не использовать одного из популярных поставщиков облачных технологий для хранения конфиденциальной информации. На очень высоком уровне основной продукт компании состоял только из двух слоев: Фронт-энд, точка входа для пользователей, которая фактически работает в их собственных браузерах и общается с остальной системой для обмена и сохранения информации. All-else, обычно известный как «backend», но на самом деле включает в себя балансировщики нагрузки, аутентификацию, авторизацию, несколько слоев кэша, базы данных, резервные копии и так далее. Первая вводная задача Джоан заключалась в том, чтобы реализовать очень простую услугу для сбора и обобщения различных статистических данных из базы данных, а также интегрировать эту услугу во всю экосистему, чтобы она получала данные из базы данных в режиме реального времени и позволяла командам DevOps проверять статистику в режиме реального времени. Чтобы произвести впечатление на руководство и убедить их в том, что найм Джоан было их абсолютно лучшим решением в этом квартале, Джоан решила представить имплементацию доказательства концепции в свой первый день!Несказанная политика компании состояла в том, чтобы писать программное обеспечение в Rust, поэтому она захватила первый драйвер для своей базы данных из короткого поиска crates.io и сел на свой самоорганизованный хакатон. День прошел очень гладко, а экосистема Rust, ориентированная на эргономику, обеспечивала превосходный опыт разработчиков. Но потом Джоан провела свои первые дымовые тесты на реальной системе. Неверие превратилось в разочарование и беспомощность, когда она поняла, что каждый третий запрос (в среднем) закончился ошибкой, хотя весь кластер баз данных сообщил, что находится в здоровом, операционном состоянии. К сожалению, водитель Джоан поспешно выбрал для основания ее работы, хотя открытый исходный код сам по себе был всего лишь тонкой оболочкой над предварительно скомпилированным, унаследованным кодом С, без источника, который можно было найти. И она сделала образованное предположение, что В базе данных, используемой компанией, ключи хешируются для последующих запросов маршрута в соответствующие узлы.Если значение хеширования вычисляется неправильно, запрос может быть перенаправлен на неправильный узел, который может отклонить его и вернуть ошибку вместо этого. Wireshark Буг должен находиться в выполнении ключа хаширования Неспособная проверить заявление из-за отсутствия исходного кода, Джоан решила проще — отказаться от первоначально выбранного драйвера и повторно реализовать решение на одном из официально поддерживаемых драйверов с открытым исходным кодом, поддерживаемых поставщиком базы данных, с прочной базой пользователей и регулярно обновляемым графиком выпуска. Дневник Иоанны уроков, изученных, часть I Первые уроки включают: Выбирайте драйвер внимательно, он лежит в основе производительности, надежности и надежности вашего кода. У водителей тоже есть ошибки, и их невозможно избежать. Если нет уважительной причины, предпочтите официально поддерживаемый водитель (если он есть); Драйверы с открытым исходным кодом имеют преимущества: они не только проверяются сообществом, но и позволяют проводить глубокую проверку его кода и даже модифицировать код драйвера, чтобы получить еще больше представлений для дебютирования; Лучше полагаться на драйверы с установленным графиком выпуска, так как они с большей вероятностью получат исправления ошибок (в том числе для уязвимостей безопасности) в течение разумного периода времени. Wireshark - отличный инструмент с открытым исходным кодом для интерпретации сетевых пакетов; попробуйте, если вы хотите заглянуть под крышку вашей программы. Вводная задача в конечном итоге была успешно завершена, что подготовило Джоан к получению ее первого реального задания. Туннинг Вооружившись опытом работы над вводным заданием, Джоан начала планировать, как подходить к своей новой задаче: неправильно поведению приложения.Одно из приложений, как известно, вызывало проблемы со стабильностью для всей системы, нарушая другие нагрузки каждый раз, когда она испытывала какие-либо проблемы. Этот конкретный сервис отвечал за введение данных, резервируемых из прежней системы, в новую базу данных. Поскольку компания не была в большой спешке, приложение было написано с низким сопутствием в виду, чтобы иметь низкий приоритет и не мешать рабочей нагрузке пользователей. К сожалению, раз в несколько дней что-то продолжало вызывать аномалию. Обычно мирное приложение, казалось, пыталось осуществить атаку отказа в обслуживании на свою собственную базу данных, наводняя ее запросами до тех пор, пока резервный край не стал достаточно перегружен, чтобы вызвать проблемы для других частей экосистемы. Когда Джоан наблюдала за показателями, представленными в панели Grafana, что ясно указывало на то, что уровень запросов, генерируемых этим приложением, начал увеличиваться в то время, когда произошла аномалия, она задумалась, как на Земле эта рабочая нагрузка могла вести себя таким образом. Поскольку сотрудничество было сильно рекламировано как один из «духовных и культурных фундаментов» компании во время сеансов на борту с тренером на месте, она решила, что лучше обсудить этот вопрос со своим коллегой Тони. «Посмотрите, Тони, я не могу обернуть голову вокруг этого, — объяснила она. — Эта служба не отправляет никаких новых запросов, когда 100 из них уже находятся в полете. «Хорошо, спасибо Тони, ты дорогой – лучший Всегда!», — завершила она и вернулась, чтобы исправить код. резиновый дук Наблюдение, которое привело к обнаружению корневой причины, было довольно простым: запрос на самом деле не *вернул* ошибку времени, потому что сервер базы данных никогда не отправлял обратно такой ответ. Запрос был просто квалифицирован как назначенный драйвером, и был отброшен. Но единственный факт, что драйвер больше не ждет ответа на конкретный запрос, не означает, что база данных закончена его обработкой! вполне возможно, что запрос был вместо этого просто застоял, занимая больше времени, чем ожидалось, и только драйвер отказался ждать своего ответа. С этими знаниями легко представить, что, как только на стороне клиента выйдет 100 запросов, приложение может ошибочно подумать, что они больше не проходят, и с удовольствием отправить 100 дополнительных запросов в базу данных, увеличив общее количество запросов в полете (т.е. параллельно) до 200. Дневник Иоанны Учителей, Часть II Уроки продолжаются: Временные промежутки на стороне клиента удобны для программистов, но они могут плохо взаимодействовать с временными промежутками на стороне сервера. Правило большого пальца: сделать временные промежутки на стороне клиента примерно в два раза дольше, чем на стороне сервера, если у вас нет очень хорошей причины сделать иначе. Некоторые драйверы могут быть в состоянии выпустить предупреждение, если они обнаружат, что временные промежутки на стороне клиента меньше, чем на стороне сервера, или даже изменить временные промежутки на стороне сервера, чтобы соответствовать, но в целом лучше всего дважды проверить. Проверка журналов и панелей инструментов полезна при расследовании таких случаев, поэтому убедитесь, что инструменты наблюдения доступны как в кластере баз данных, так и для всех клиентских приложений. При правильно измененных временных промежутках на стороне клиента приложение задыхалось гораздо реже и в меньшей степени, но это все еще не было идеальным гражданином в распределенной системе. Время от времени он выбирал узел базы данных жертвы и продолжал беспокоить его с слишком большим количеством запросов, игнорируя тот факт, что семь других узлов были значительно менее загружены и могли помочь справиться с рабочей нагрузкой тоже. В другие времена, его сопутствующее было сообщено быть точно на 200% больше, чем ожидалось конфигурацией. Всякий раз, когда две аномалии сближались во времени, плохой узел не мог справиться со всеми запросами, с которыми он был бомбардирован, и должен был отказаться от справедливой части из них. Формат и сохраненный достаточно актуально, помог Джоан облегчить эти боли тоже. mdbook Первая проблема заключалась просто в неправильной конфигурации политики сбалансирования нагрузки, которая пыталась слишком усердно выбирать «менее загруженный» узл базы данных из всех доступных, основываясь на эвристике и статистике, иногда обновляемой самой базой данных. К сожалению, эта политика также была «лучшим усилием» и опиралась на тот факт, что статистика, поступающая из базы данных, всегда была легитимной – но узел базы данных, подвергшийся стрессу, мог стать настолько перегруженным, что он не отправлял обновленную статистику вовремя! Вторая проблема (временное удвоение конкурирующей валюты) была вызвана еще одной ошибкой: чрезмерной политикой спекулятивного ретринга. После ожидания заранее сконфигурированного периода времени без получения признания из базы данных, водители спекулятивно пересылали запрос, чтобы максимизировать его шансы на успех. Этот механизм очень полезен для увеличения успеха запросов. Однако, если первоначальный запрос также преуспевает, это означает, что спекулятивный был отправлен напрасно. Чтобы сбалансировать плюсы и минусы, спекулятивный ретринг должен быть настроен на пересылку только запросов, если очень вероятно, что первоначальный провалился. В противном случае, как в случае с Джоан, спекулятивный ретринг может действовать Whew, ничто не дает одновременный порыв эндорфина и дофамина, как сеанс дебютирования качества, который заканчивается потрясающим успехом (за исключением написания сытной истории в глубоко технической книге, естественно). В конце Если вы дошли до этого и не можете получить достаточно сырых историй о производительности базы данных, посмотрите, что случилось с бедным старым Патриком в " И если вы цените это чувство юмора, смотрите книгу Петра. . Editor’s note: Оригинальное название: A Tale of Database Performance Woes: Patrick's Unlucky Green Fedoras Новая книга о написании инженерных блогов
