Стратегии для типа «один-ко-многим», когда «много» побочных записей в миллионах

Question

Дает аналогию: сценарий, подобный Twitter, где за человеком может следовать огромное количество людей (один ко многим),

Несколько вариантов, о которых я мог бы подумать

1. Используйте какой-либо инструмент сопоставления ИЛИ с отложенной загрузкой.Но когда вы обращаетесь к стороне «последователей» отношений, она все равно загружает все данные, даже лениво.Так что не подходящий вариант.

2. Не поддерживать отношение один-ко-многим (или не использовать сопоставление ИЛИ).Извлеките сторону "Последователи" в отдельном вызове и обработайте пейджинг и т. Д. Программно.

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

Пожалуйста, поделитесь своими мыслями / предложениями и любыми возможными библиотеками инструментов.Стек состоит из Java, MySQL.

Answer 1

Миллионы не должны быть проблемой для СУБД, поскольку она предназначена для таких ситуаций.

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