@AlexWeb6667
Web-дизайнер с опытом FullStack разработки

Как быстро перебрать большой объем данных?

Всем привет коллеги, появилась такая вот задача.
Пишу Api, раз в сутки на него будет приходить данные из базы пользователей в массиве json, мне нужно взять этих пользователей и по какой неб строке(пока не известно, id или номер телефона) сравнить со своей базой и вернуть json массив с статусом подписаны ли эти пользователи у меня в базе или нет. проблема в том что раз в сутки, прям в один момент, может приходить от 20 тыс записей, как бы мне быстрей их перебрать, и чтобы сервак не лег... Кто сталкивался? Не подскажите как лучше с этим справится?
  • Вопрос задан
  • 179 просмотров
Пригласить эксперта
Ответы на вопрос 4
dima9595
@dima9595
Junior PHP
На мой взгляд нужно:
Во первых: Перебирать записи не одним разом, а частями. При этом сохранять эти данные в кеш.
Во вторых: Использовать очереди.
PS: Если есть ещё варианты, то рад был бы я тоже услышать.
Ответ написан
@LiguidCool
1) бить задачу на мелкие, результат складывать.
2) сделать реплику и выбирать в ней.
Ответ написан
sergiks
@sergiks Куратор тега PHP
♬♬
Сделать задачу асинхронной.

  1. присылают объёмный json с данными пользвателей, полем сравнения, (ключами авторизации) и uuid задачи и адресом callback куда ваш api отправит ответ – потом, позже;
  2. данные приняли, сохранили, создали задачу, поместили её в очередь задач, клиенту на запрос ответили "ОК, приняли, сделаем - ответим". Ведь если клиент не один, может, сразу десятку клиентов вздумается именно в полночь прислать по миллиону своих пользователей – итого 10 млн. «В очередь, с*кины дети, в очередь!» «Вас много, а я одна!» : )
  3. один или несколько «рабочих» (серверов, процессов) из очереди забирают каждый по одному заданию и как могут быстро их выполняют, готовят ответ, отправляют по адресу callback. Если отправка не удалась, что-то сглючило на стороне клиентов, в очередь помещается подзадача только повторной отправки ответа через N секунд, не более M раз.
Ответ написан
rim89
@rim89
программист-велосипедист
строке(пока не известно, id или номер телефона)

если ID уникальный индекс, имхо по нему будет дешевле

не вникая в подробности как вариант:
пришли данные и callback url
реализация обмена через long pooling( если сервер не будет успевать обработать по классической схеме) , как будет сформирован массив-ответ - отправить его в колбэк url

со стороны БД ( если SQL) , как вариант - создание временной таблицы из пришедших данные + LEFT JOIN в нее из существующих подписок: если подписан то в столбце будет 1 , если нет , то NULL
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы