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

Question

[Alex Mirgorodskiy]

Всем привет коллеги, появилась такая вот задача.
Пишу Api, раз в сутки на него будет приходить данные из базы пользователей в массиве json, мне нужно взять этих пользователей и по какой неб строке(пока не известно, id или номер телефона) сравнить со своей базой и вернуть json массив с статусом подписаны ли эти пользователи у меня в базе или нет. проблема в том что раз в сутки, прям в один момент, может приходить от 20 тыс записей, как бы мне быстрей их перебрать, и чтобы сервак не лег... Кто сталкивался? Не подскажите как лучше с этим справится?

Comments

[Сергей Соколов]

Где узкое место?

• приём файла от клиента
  
• декодирование json
  
• сравнение списка со своей базой
  
• кодирование json
  
• отправка ответа
  

[Alex Mirgorodskiy]

Пока на этапе проектирования, я подозреваю что сравнивать два больших массива будет накладно

[Максим Тимофеев]

20 тыс записей

а это много?
Ну ок. Пишите пришедший массив в базу (файл). Далее кроном партиями сравниваете. Видимо удаляя постепенно из базы (файла).

Answer 1

[Дмитрий Кузнецов]

На мой взгляд нужно:
Во первых: Перебирать записи не одним разом, а частями. При этом сохранять эти данные в кеш.
Во вторых: Использовать очереди.
PS: Если есть ещё варианты, то рад был бы я тоже услышать.

Answer 2

[Иван]

1) бить задачу на мелкие, результат складывать.
2) сделать реплику и выбирать в ней.

Comments

[Alex Mirgorodskiy]

Иван, что вы имели в виду "сделать реплику"?

[Дмитрий Кузнецов]

Alex Mirgorodskiy, как я понимаю - репликация бд или серверов для обработки

[Иван]

Дмитрий Кузнецов, Alex Mirgorodskiy, именно. Но в данном случае выгоднее делать репликацию БД. Причем сейчас большинство систем поддерживают репликацию "из коробки".
Ну или упрощенный вариант - делать бекап и поднимать его на другом сервере. Но ИМХО минусов тут больше чем плюсов.

[Дмитрий Кузнецов]

Иван, да, согласен, ручной бэкап потребует больше времени и сил, нежели делать по первому пункту.

Answer 3

[Сергей Соколов]

Сделать задачу асинхронной.

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

Comments

[Alex Mirgorodskiy]

Сергей Соколов, Спасибо, интересно, тоже рассматриваю больше асинхрон, вы имеете в виду cron верно? Работали уже с таким объемом такими методами или чисто теоретически?

[Сергей Соколов]

По такому принципу выполнения долгоиграющих задач делал проекты. Кодирование видео, отправка на YouTube, например.

Cron это всего лишь запуск по расписанию. Он тут, скорее, не при чём. Рабочие процессы обычно постоянно работают, ожидая поступления новой задачи.

[Alex Mirgorodskiy]

Сергей Соколов Не работал еще с такими большими объемами, могли бы вы немного подробней разъяснить по очередям, как их использовать, где почитать можно, что они дают...

[Сергей Соколов]

20 тыс. записей это очень маленький объём. При правильных индексах в БД, поиск даже на слабой VPS будет порядка нескольких миллисекунд.

Очередь задач это, по сути, просто буфер, который ещё и отвечает за то, чтобы одна задача ушла только одному исполнителю. «Задача» – это, например, JSON, в котором указано, где лежат данные, что с ними сделать, куда отправить результат.

Реализаций множество. И «большие» GearMan, RabbitMQ, и реализация в Laravel и Lumen.

Answer 4

[Виталий]

строке(пока не известно, id или номер телефона)

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

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

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