Масштабируемость постов комментариев: Top n на пользователя, 1 обновление, интенсивное чтение

Question

Вот ситуация. Многомиллионный пользовательский сайт. На странице каждого пользователя есть раздел сообщений. Любой может посетить страницу пользователя, где он может оставить сообщение или просмотреть последние 100 сообщений.

Сообщения - это короткие фрагменты текста с некоторыми дополнительными метаданными. Каждое сообщение должно храниться постоянно, единственное, что должно быть быстрым в режиме реального времени, - это обновление и чтение сообщения (люди используют его в чате). Количество сообщений будет читаться очень часто, чтобы проверить изменения. Периодически можно архивировать старые сообщения (те, что> 100), но они должны быть доступны.

В настоящее время все в одной большой таблице БД, и конфликт между людьми, читающими списки сообщений и отправляющими больше обновлений, становится проблемой.

Если бы вам пришлось перестроить систему, какой механизм хранения / кэширования вы бы использовали? какой вид обучения информатике можно использовать здесь? (например, коллекции, доступ к списку и т. д.)

Answer 1

Некоторые общие мысли, не относящиеся к какой-либо конкретной технологии:

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

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

3. Как и во многих других приложениях, мы можем предположить, что использование сервиса следует кривой степенного закона: лишь немногие страницы пользователя вызывают большую часть трафика, за которым следует длинный хвост. Схема кэширования может воспользоваться этим. Чем круче кривая, тем эффективнее будет кэширование. С учетом коротких сообщений, если на каждой странице отображается 100 сообщений, а каждое сообщение в среднем занимает 100 байтов, вы можете разместить около 100 000 верхних страниц в 1 ГБ кэш-памяти RAM. Эти кэшированные страницы могут быть лениво записаны в базу данных. Из 10 пользователей Mil 10000 находятся на стадионе, чтобы изменить ситуацию.

4. Разбейте веб-серверы, возможно, используя ту же схему хеширования. Это позволяет вам хранить отдельные кэши ОЗУ без конфликтов. Потенциальное преимущество заключается в увеличении размера кэша по мере роста числа пользователей.

5. Если это подходит для вашей среды, один из способов обеспечения того, чтобы новые сообщения в конечном итоге записывались в базу данных, - это помещать их в постоянную очередь сообщений сразу после помещения их в кэш-память ОЗУ. Очередь не испытывает конкуренции и помогает гарантировать, что сообщения не будут потеряны при сбое компьютера.

Answer 2

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

Это просто смещение узкого места с одного места в другое, но оно может переместить его куда-то, что не так сложно.