У меня есть REST API, который состоит из разных ресурсов. Некоторые из этих ресурсов также индексируются и синхронизируются в ES, и я реализую систему очередей для управления этими операциями асинхронным способом. Я решил пойти на Beanstalkd в качестве системы очередей.Очередь Beanstalkd для индексирования документов в Elasticsearch
Мои
училДля каждого ресурса я буду иметь другую трубку, и я разделюсь индексирования работы по ресурсам. Например, у меня будет трубы, как «index_users», «index_posts», которые получат рабочие места с идентификаторы ресурсов для индексации в ES:
->useTube('index_users')->put(json_encode([ 'ids' => [ 33, 35, 66 ] ]));
имеют разные трубки для различных ресурсов, помогает мне держать вещи разделены (для Например, я могу решить остановить индексирование пользователей, просто удалив индекс index_users), работа будет анализироваться быстрее, потому что будет меньше заданий на одну очередь, а огромное количество операций индексирования на одном ресурсе не повлияет на индексацию других ресурсов.
Мои вопросы
- Может быть, это хороший способ обработки?
- Какие недостатки могут иметь это решение?
- Кто-то сказал мне, что в beanstalk лучше иметь 1 трубу с 1000000 заданиями (относящимися к 2 ресурсам), а не 2 трубки (по 1 для каждого ресурса) с 5000 заданий каждый. Они предлагают мне пойти на решение только с одной трубкой и для потребления памяти. Это правда?