Как лучше ... учитывая производительность

Question

В моей таблице около 5 000 000 пользователей, и каждый пользователь связан с некоторыми книгами (has_many)

Я хочу отобразить всех пользователей вместе с их книгами ....

Я не буду отображать всех пользователей на одной странице, они будут разбиты на страницы.

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

Answer 1

Было бы неразумно отображать всех пользователей и их книги на одной странице. Существует два возможных подхода к решению этой проблемы:

1. У вас может быть страница индекса для пользователей, где вы перечисляете всех пользователей. Для каждого пользователя у вас может быть «показать» страницу, где вы отображаете книги пользователя. Это значительно упростит итоговые запросы к базе данных, поскольку вам нужно будет загружать только пользователей для страницы индекса и загружать только книги одного пользователя на его / ее странице показа. Это означает, что нет сложных объединений и не много данных каждый раз.

2. Если вы действительно хотите, чтобы несколько пользователей и их книги отображались на одной странице, то, как и кто-то, упомянутый в комментариях выше, вам нужно использовать нумерацию страниц, скажем, загрузить 5 пользователей на страницу. Тем не менее, чтобы добавить к этому, вам также необходимо использовать энергичную загрузку, поскольку это может легко превратиться в проблему N + 1. Вы можете прочитать больше в " Стремительная загрузка ассоциаций ".

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

Answer 2

Запросы с большими смещениями неэффективны в MySQL;При оценке запроса со смещением 100000 MySQL должен фактически найти эти 100 000 строк и отбросить их, прежде чем сможет найти десять строк, которые вы в конечном итоге отобразите.

Одним из способов решения этой проблемы является предоставление подсказок для вашего приложения: вместо того, чтобы произносить страницу 10000, скажем, что это страница, где id > x, если вы сортировали в порядке первичного ключа.

Также важно, чтобы у вас были соответствующие индексы.

На percona.com есть хорошая статья под названием " Эффективное разбиение на страницы с использованием MySQL " с различными подходами к разбивке на страницы больших наборов.

Answer 3

Немного мыслей -

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

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

Лучшим вариантом может быть отображение списка пользователей в алфавитном порядке, не обязательно A-Z, но также как AB, AC, AD и так далее. Таким образом, ваши посетители могут напрямую перейти к определенному списку. Попробуйте добавить нумерацию страниц, если число пользователей в данном списке слишком велико.

Я не уверен, насколько важно, чтобы ваш веб-сайт отображал последние обновления как можно скорее, но вы также можете подумать о создании файлов XML, сколько вам кажется необходимым, например, в алфавитном порядке и создании веб-страниц из файлов XML. , Вы можете обновлять эти XML-файлы один раз каждые 24 часа. Итак, минимальная загрузка БД.

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

Надеюсь, это поможет!