Instagram top media api «распределенный» поиск по многим пользователям дизайн базы данных

#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. Мое текущее решение основано на следующих предположениях:

  1. Для каждого пользователя я могу использовать их access_token для запроса 30 уникальных хэштегов из API Instagram (не обязательно хэштеги, которые их интересуют).
  2. Возможно, для поиска по пользователям могут быть дубликаты хэштегов, поэтому мне не нужно искать один и тот же хэштег дважды.

Теперь, выясняя, как это сделать, я бы сделал следующее.

  1. Запросите каждого пользователя через API Instagram, чтобы получить его последние материалы и извлечь из них хэштеги.
  2. Храните каждый уникальный хэштег в таблице базы данных под названием hashtags . Я хочу найти эти значения позже.
  3. Сохраните связь между каждым элементом мультимедиа и соответствующим идентификатором хэштега media_to_hashtag .
  4. Сохраните ключ доступа пользователей в таблице базы данных ( 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)
     

На отдельной ежедневной или двухразовой «работе» я могу тогда

  1. Запросите все хэштеги, которым в настоящее время не присвоен ключ доступа, и выберите один из таблицы access_token с использованием, превышающим 0, и уменьшите значение usage .
  2. Запросите в 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, но затем я сохраню его для последующих вызовов