Я работаю над платформой, где уникальные идентификаторы пользователей являются идентификаторами из пула идентификаторов Amazon Cognito. Которые выглядят так: "us-east-1:128d0a74-c82f-4553-916d-90053e4a8b0f"
Платформа имеет базу данных MySQL с таблицей элементов, которые могут просматривать пользователи. Мне нужно добавить таблицу избранного, которая содержит все избранные элементы каждого пользователя. Эта таблица может вырасти до миллионов строк.
Схема таблицы "Избранное" будет выглядеть следующим образом:
userID, itemID, dateAdded
где userID и itemID вместе составляют составной первичный ключ.
Насколько я понимаю, этот тип идентификатора пользователя (практически расширенный UUID, который необходимо хранить в виде char или varchar) дает низкую производительность индексирования. Поэтому не рекомендуется использовать его в качестве ключа или индекса для миллионов строк.
Мой вопрос: Правильно ли я понимаю, и должен ли я беспокоиться о производительности позже из-за этого ключа? Какие меры я могу принять, чтобы снизить риски производительности?
Мои общие знания баз данных не так уж велики, поэтому, если это большая проблема... Я бы переместил список избранного в таблицу NoSQL (где идентификатор пользователя в качестве ключа обеспечивает постоянное время доступа) и извлечение массива идентификаторов избранных элементов для использования в запросе SELECT...WHERE IN, может быть приемлемой альтернативой?
Большое спасибо!
Другая потенциальная проблема заключается в том, что если вы случайно добавите больше федеративных удостоверений, идентификатор будет напрямую привязан к каждому удостоверению, поэтому, если у вас есть пользователь, поющий по-разному, у него будут записи, связанные с ним с разными идентификаторами, но для одного и того же пользователя в пул пользователей.