Как Quora масштабировала MySQL до 100 тыс.+ запросов в секунду

Сегодня мы поговорим о

• Масштабирование MySQL в Quora

  • Quora использует сегментированный кластер MySQL для хранения вопросов, ответов, голосов «за», комментариев и т. д.

  • Масштабирование чтения базы данных с помощью кэширования и оптимизации запросов

  • Масштабирование хранилища базы данных путем перехода на RocksDB

  • Масштабирование операций записи в базу данных с помощью параллельной репликации

• Технические фрагменты

  • Полезные советы по повышению скорости и эффективности кодирования

  • Как Shopify использует парное программирование для наставничества

  • Ценность собственного опыта

  • Что делает хорошего менеджера из инженеров-программистов

  • Карьерные советы для младших разработчиков

Присоединение к группе разногласий для вашего любимого фреймворка/языка — это фантастический способ ускорить процесс обучения.

Appwrite запускает сообщество из более чем 16 000 разработчиков, который является очень дружелюбным, инклюзивным и наполнен опытными разработчиками.

Это фантастическое место, чтобы

• Поговорите о последних тенденциях в полностековой разработке.

• Найдите технических сооснователей для вашего следующего проекта

• Узнайте, как создавать высокомасштабируемые приложения.

Инженеры Appwrite также чрезвычайно активны в Discord, поэтому они являются отличным источником помощи, если вы запускаете веб-приложение, iOS, Android или Flutter с помощью Appwrite. Или вы можете поговорить о том, чему они научились, масштабируя Appwrite для обслуживания более чем 26 000 инженеров!

Quora — это сайт социальной сети, где вы можете публиковать вопросы, на которые сообщество может ответить. У них более 300 миллионов активных пользователей в месяц, и в день публикуются десятки тысяч вопросов.

Для обслуживания этого трафика они активно используют MySQL. У них есть сегментированная конфигурация, которая хранит десятки терабайт и может масштабироваться для обслуживания сотен тысяч QPS (запросов в секунду).

Если вам интересно, как они сегментировали MySQL, вы можете прочитать об этом. здесь.

Помимо добавления дополнительных компьютеров в кластер MySQL, Quora должна была убедиться, что существующая система работает максимально эффективно.

Вамси Поннеканти — инженер-программист в Quora, он написал фантастическую статья углубляясь в различные факторы загрузки базы данных и конкретные шаги, которые команды инженеров предприняли для оптимизации.

При загрузке базы данных необходимо масштабировать три основных фактора: нагрузка чтения, нагрузка записи и размер данных.

• Чтение тома – Сколько запросов на чтение вы можете обрабатывать в секунду. Quora масштабировала это, улучшив свою стратегию кэширования (изменив структуру, чтобы минимизировать промахи в кэше), а также оптимизировав неэффективные запросы на чтение.

• Объем записи – Сколько запросов на запись вы можете обрабатывать в секунду. Quora не является приложением с большим объемом записи. Основная проблема, с которой они столкнулись, заключалась в репликации между узлами первичной реплики. Они исправили это, изменив способ воспроизведения записи.

• Размер данных – Сколько данных хранится на ваших дисках. Quora оптимизировала это, переключив механизм хранения MySQL с InnoDB (по умолчанию) в RocksDB.

Мы углубимся в каждый из них более подробно.

У Quora большая нагрузка на чтение, поэтому оптимизация чтения очень важна. Однако разные виды чтения требуют разных оптимизаций.

Один из способов разделить избыточную нагрузку на трафик чтения — использовать

• Сложные запросы – Запросы, которые нагружают ЦП и перегружают базу данных (объединения, агрегации и т. д.).

• Запросы с высоким количеством запросов в секунду – Если у вас большой трафик, вы будете иметь дело с высоким количеством запросов в секунду, независимо от того, насколько хорошо вы спроектировали свою базу данных.

Вот как Quora справилась с каждым из этих случаев.

Для сложных запросов стратегия состоит в том, чтобы просто переписать их, чтобы они меньше нагружали базу данных.

• Большие запросы сканирования – Если у вас есть запрос, сканирующий большое количество строк, измените его на использование нумерация страниц так что результаты запроса извлекаются меньшими порциями. Это помогает гарантировать, что база данных не выполняет ненужную работу.

• Медленные запросы – Существует много причин, по которым запрос может выполняться медленно: нет хорошего индекса, запрашиваются ненужные столбцы, неэффективные соединения и т. д. Вот хороший пост в блоге о том, как находить медленные запросы и оптимизировать их.

Решением для снижения нагрузки от таких запросов является эффективная стратегия кэширования. В Quora обнаружили, что неэффективное кэширование (много промахов в кэше) является причиной большой ненужной загрузки базы данных.

Некоторые конкретные примеры, которые видел Quora, были

• Получение языковых предпочтений пользователя — Quora нужно было проверить, какие языки понимает пользователь. Раньше они запрашивали кеш с помощью (user_id, Language_id) и получите ответ да/нет. Запрос (carlos_sainz, испанский) будет проверять, понимает ли пользователь Карлос Сайнс по-испански. Они выполнили бы этот запрос для всех 25 языков, поддерживаемых Quora – (Карлос Сайнс, английский), (Карлос Сайнс, француз), и т. д.

  Это привело к большому пространству ключей для кэша (возможными ключами были все user_ids, умноженные на количество языков.), и это привело к огромному количеству промахов в кэше. Люди обычно знают только 1 или 2 языка, поэтому большинство этих запросов заканчивались Нет. Это вызывало большую ненужную нагрузку на базу данных.

  Quora изменила свой ключ кеша, чтобы использовать только идентификатор пользователя (Карлос Сайнс) и изменил полезную нагрузку, чтобы просто отправлять обратно все языки, которые знал пользователь. Это увеличило размер отправляемой обратно полезной нагрузки (список языков вместо просто да/нет), но это означало значительно более высокую скорость попадания в кеш.

  Благодаря этому Quora снизила количество запросов в секунду в базе данных более чем на 90% по этим типам запросов.

• Неэффективное кэширование для разреженных наборов данных – Еще одна проблема с кешированием, с которой часто сталкивался Quora, заключалась в редкий наборы данных в одном измерении. Например, им может потребоваться запросить базу данных, чтобы узнать, нужно ли перенаправить определенный вопрос на другой вопрос (это может произойти, если тот же вопрос будет повторно опубликован).

  Подавляющее большинство вопросов не необходимо перенаправить, чтобы Quora получала только несколько «перенаправлений» и большое количество «не перенаправлять».

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

  Вместо этого они начали кэшировать диапазоны. Если идентификаторы вопросов 123 – 127 не было никаких перенаправлений ни для одного из вопросов, тогда они кэшировали этот диапазон, в котором есть все «Нет», вместо кэширования каждого отдельного идентификатора вопроса.

  Это привело к значительному снижению нагрузки на базу данных для этих типов запросов, при этом количество запросов в секунду снизилось на 90%.

Другая часть масштабирования баз данных связана с огромным объемом данных, которые необходимо хранить.

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

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

• Время резервного копирования и восстановления увеличивается линейно с увеличением размера таблицы.

• Размер хранилища резервных копий также будет расти с линейной скоростью.

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

Теперь, чтобы оптимизировать способ хранения данных на диске, Quora сделала это, интегрировав РоксДБ.

RocksDB — это хранилище ключей-значений, разработанное в Facebook и являющееся ответвлением Google. УровеньБД. Его обычно заменяют в качестве механизма хранения (подсистема хранения отвечает за то, как данные хранятся и извлекаются с диска) для баз данных NoSQL.

MyRocks был впервые создан в Facebook, где они интегрировали RocksDB в качестве механизма хранения данных для MySQL. Вы можете прочитать подробный анализ преимуществ здесь.

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

В InnoDB размеры страниц фиксированы (по умолчанию — 16 КБ). Если данные не заполняют размер страницы, оставшееся пространство тратится впустую. Это может привести к дополнительной фрагментации.

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

Facebook смог сократить использование хранилища в половине перейдя на MyRocks.

В Quora они смогли увидеть сокращение места на 80% для одного из своих столов. В других столах пространство уменьшилось на 50-60%.

С Quora их база данных загружается не является писать тяжело. Если у них были какие-либо рабочие нагрузки с большим объемом записи, они использовали HBase (распределенная база данных, оптимизированная для записи, созданная по образцу Google Большой стол) вместо MySQL.

Однако одной из проблем, с которой они столкнулись, была чрезмерная задержка репликации между экземплярами MySQL. У них есть начальный экземпляр, который обрабатывает запись в базу данных, а затем у них есть копия экземпляры, которые обрабатывают чтение. Узлы-реплики отставали от основных в получении этих изменений.

Основная проблема заключалась в том, что записи воспроизведения репликации происходят. последовательно по умолчанию, даже если записи происходили одновременно на первичном сервере.

Временное решение, использованное Quora, заключалось в перемещении таблиц с интенсивной записью с одного основного узла MySQL на другой узел с меньшим давлением записи. Это помогло распределить нагрузку, но не поддавалось масштабированию.

Постоянное решение состояло в том, чтобы включить функцию записи параллельной репликации MySQL.

Все подробности вы можете прочитать в полной публикации в блоге. здесь.

Присоединение к группе разногласий для вашего любимого фреймворка/языка — это фантастический способ ускорить процесс обучения.

Appwrite запускает сообщество из более чем 16 000 разработчиков, который является очень дружелюбным, инклюзивным и наполнен опытными разработчиками.

Это фантастическое место, чтобы

• Поговорите о последних тенденциях в полностековой разработке.

• Найдите технических сооснователей для вашего следующего проекта

• Узнайте, как создавать высокомасштабируемые приложения.

Инженеры Appwrite также чрезвычайно активны в Discord, поэтому они являются отличным источником помощи, если вы запускаете веб-приложение, iOS, Android или Flutter с помощью Appwrite. Или вы можете поговорить о том, чему они научились, масштабируя Appwrite для обслуживания более чем 26 000 инженеров!