#mysql #database-design #architecture #instagram-api #system-design
Вопрос:
В настоящее время я пытаюсь сопоставить статистику лучших СМИ в instagram по различным хэштегам. Как бы то ни было, мой стек будет представлять собой nodejs с базой данных mysql, но на самом деле это всего лишь структура базы данных, о которой я здесь спрашиваю. Конечно, если люди видят лучший способ сделать это, пожалуйста, скажите.
Просматривая документы api Instagram ( https://developers.facebook.com/docs/instagram-api/reference/ig-user/recently_searched_hashtags ), токен доступа пользователя может выполнять поиск только по 30 уникальным хэштегам в течение 7 дней.
Существует несколько инструментов, которые ищут хэштеги и, похоже, делают это для более чем 30 хэштегов на пользователя (один из которых даже указан в качестве примера https://developers.facebook.com/products/instagram/success-stories/ ). Я пытаюсь найти способ сделать это самостоятельно, используя только официальные API. Мое текущее решение основано на следующих предположениях:
- Для каждого пользователя я могу использовать их access_token для запроса 30 уникальных хэштегов из API Instagram (не обязательно хэштеги, которые их интересуют).
- Возможно, для поиска по пользователям могут быть дубликаты хэштегов, поэтому мне не нужно искать один и тот же хэштег дважды.
Теперь, выясняя, как это сделать, я бы сделал следующее.
- Запросите каждого пользователя через API Instagram, чтобы получить его последние материалы и извлечь из них хэштеги.
- Храните каждый уникальный хэштег в таблице базы данных под названием
hashtags
. Я хочу найти эти значения позже. - Сохраните связь между каждым элементом мультимедиа и соответствующим идентификатором хэштега
media_to_hashtag
. - Сохраните ключ доступа пользователей в таблице базы данных (
access_token
) с «доступным» количеством хэштегов, по которым он может выполнять поиск.table hashtag id int PK AI hashtag varchar(100) igid unsigned bigint (Instagram ID) access_token text last_searched timestamp table media_to_hashtag media_id bigint PK, hashtag_id int PK stats.... table access_token access_token_id INT AI PK, token text, usage int default 30, user_id unsigned bigint. (in case we need to invalidate/delete a user)
На отдельной ежедневной или двухразовой «работе» я могу тогда
- Запросите все хэштеги, которым в настоящее время не присвоен ключ доступа, и выберите один из таблицы access_token с использованием, превышающим 0, и уменьшите значение
usage
. - Запросите в Instagram все хэштеги и обновите любую статистику в
media_to_hashtag
таблице
Кажется ли это жизнеспособным решением?
Вопрос, с которым я борюсь, заключается в том, является ли это жизнеспособным способом сопоставления маркеров доступа или его можно каким-то образом улучшить, учитывая необходимость обновления маркеров доступа и их потенциального удаления. Было бы мне лучше с другой таблицей отображения, например
hashtag_to_access_token
hashtag_id int PK,
access_token_id int PK
Таким образом, я сохраняю токен доступа только в одной таблице, что поможет в сценариях обновления. Я не уверен, что в любом случае я могу использовать ограничение, чтобы гарантировать, что маркер доступа используется только 30 раз таким образом.
Это довольно многословно, но я пытался предоставить как можно больше информации.
Заранее спасибо
Комментарии:
1. «используйте их access_token» — но этот столбец есть в таблице
hashtag
. Звучит неправильно. Я вижуaccess_token_id
, что это не используется. Давайте посмотримSELECTs
, что вам понадобится.2. Для начала это связано с API Instagram, чтобы я мог заполнить свою таблицу хэштегов. Я могу получить их маркер доступа из API, но затем я сохраню его для последующих вызовов