БД фильма - хранилище Актеров / Актрисы / Теги?

Question

Создание фильма БД, и мне не нравится идея давать каждому актеру / актрисе, а также каждому тегу свой собственный ряд, как если бы в общей сложности было 10 миллионов мотивов, у каждого из которых было по меньшей мере 20-30 человек, у нас будет 200- 300 миллионов строк в таблице.

И это становится более сложным с тегами, которые могут быть неограниченными для каждого фильма. Так как же лучше хранить эти 3 предмета? В идеале они могут быть смоделированы как «многие ко многим», но все равно они будут иметь сотни миллионов строк. Есть лучшие предложения по хранению этих? Я использую MySQL.

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

Answer 1

10 миллионов фильмов кажутся довольно амбициозными. Текущая статистика IMDb показывает, что у них менее 1,8 млн. Титулов и около 3,9 млн. Человек.

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

Answer 2

10 миллионов фильмов с 20-30 актерами (хотя число звучит выше, чем в реальной жизни) неизменно приведет к 200-300 миллионам ассоциаций. Если вы храните свои данные в реляционной базе данных, каждая ассоциация, естественно, будет одной строкой в ​​таблице, связывающей фильмы с актерами. Каждый ряд будет очень маленьким (два столбца - фильм PK и актер PK; возможно, дополнительный столбец суррогатного ключа); большая часть данных будет храниться в таблице фильмов и актеров.

Любое другое решение (в базе данных SQL) будет хранить тот же объем данных в менее оптимальном формате.

Answer 3

Здесь звучит, пожалуй, немного преждевременная оптимизация .Вы могли бы денормализовать всех актеров в какой-то столбец TEXT в таблице Movie, но ваша производительность + поиск пострадают, а также потерятся все преимущества реляционных данных.

Suggestчтобы сохранить нормализованную схему, как вы изначально думали:

Movie (ID)
Actor (ID)
Tag (ID) --horror, comedy, etc.

MovieActor (MovieID, ActorID)
MovieTag (MovieID, TagID)

• Создать индексы в соответствии с нормой для ассоциативных объектов: MovieActor и MovieTag.
• Загрузить некоторыефиктивные данные в тестовой среде.10 миллионов фильмов с 100 миллионами актеров с 1 миллионом тегов.При необходимости создайте ассоциативные записи для каждого.
• Базовый тест и тест производительности.
• Горизонтальное разбиение (разбиение) , если ваши показатели производительности требуют большей производительности.

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

Answer 4

В чем причина вашего отвращения к миллионам строк? Воспринимаемая проблема производительности?

У него где-то будут сотни миллионов отношений. Вы должны захватить соответствие между актером и фильмом, и, как вы говорите, их 200–300 миллионов (хотя я не верю, что существует 10 миллионов фильмов?)

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