Как улучшить производительность множественного JOIN для базы данных SQL

Question

Предположим, у меня есть приложение, которое понравилось Spotify, и его схема показана ниже:

введите описание изображения здесь

После входа пользователя в систему и нажатия кнопки «Мои песни» запрос должен вернуть все купленные песни для этого пользователя.

Согласно приведенной выше схеме, мне нужно написать SQL например:

select s.name, al.name, ar.name, g.genres
from users u 
join purchases p on u.id = p.userid
join purchaseitem pi on p.id= pi.purchaseid
join songs s on pi.itemid = s.id
join albums al on al.id = s.albumid
join genres g on g.id = s.genreid
join artists ar on ar.id = al.artisted

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

1. Какое улучшение мы можем сделать с самим запросом?

2. Если мы ничего не можем сделать с запросом SQL, как можно изменить схему базы данных, чтобы расширить эту возможность?

3. Если мы возможность разбиения базы данных SQL, то есть индексация, поможет ли это повысить производительность?

4. Если производительность является единственной проблемой, будет ли база данных No SQL, такая как Cassandra или MongoDB лучший выбор?

Answer 1

Вы можете денормализовать таблицу предметов покупки и сохранить все остальные данные (название альбома, имя исполнителя и т. Д. c) в таблице покупок. После совершения покупки данные не изменятся.

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

Не нужно хранить историю покупок в системе. ?

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

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

Переход на NO SQL не будет серебряной пулей. Вы можете обрабатывать миллионы записей в системе реляционной базы данных при правильном проектировании. Кроме того, шаблон микросервисов можно использовать для масштабируемости, но он усложнит ваш дизайн и стек технологий.