Ситуация такая: На сайт прилетают очень много входящих запросов где есть поле, предположим ФИО. Мы должны проверить есть ли в базе запись с этим ФИО, а если нет, то сохранить это ФИО там и потом запустить некий воркер, который будет собирать информацию по этому ФИО на ресурсах интернета.
Вопрос такой: Как организовать по правильному архитектуру для того чтобы не положить базу и чтоб просто все работало как положено?
Моё мнение, что по несколько тысяч раз в секунду дергать обычную MYSQL базу накладно.
Я думаю что надо использовать Эластик Сёрч для индексирования данных и при этом еще и кэшировать данные, чтоб, например, если пришел запрос "Иванов Иван Иванович" мы сначала брали из кэша результат, в котором ключем было бы как раз это ФИО, а значением было бы checked (проверен или не проверен). Если в кэше нет результата, то уже обращаться к эластику. Если в Эластике нет, то тогда добавлять запись в базу и запускать воркер и потом обновлять кэш как только вся информация будет собрана и переиндексировать Эластик.
Что еще можете посоветовать? Что использовать для кэширования.
1. Для начала стоит понять а как часто у вас прилетают запросы на одну и туже фамилию. Или у вас таких запросов 1% - остальные уникальны как вам кэш поможет?
2. А что вы будете искать в эластике и как. Я может ошибаюсь - но то что вы написали на эластик особо не тянет
Дмитрий, ну представь что это оператор сотовой связи к которому прилетают смс. и в смс указано слово. и вот если это слово принадлежит известному ресурсу то это одно. а если это с сайта-однодневки пришло, то такой сайт не интересен.
Слава,
еще раз. вы сказали у вас система с данными, систему дергают по одному полю - она должен отдать результат. Запросов много - хочу кеш и эластиксеарч. У вас спросили уникальность запросов - потому что если у вас из 5 тысяч запросов - 4 999 запросов уникальные - вы просто выкинете в мусор всю ту память что выделите под кеш. И все. По этому я у вас и спросил.
Эластик тоже не серебряная пуля. что вы в ней будете искать - это одно поле? И с чего вы взяли что эластик будет справляться лучше мускула? Потому что ELK стэк модно и популярно? Это так не работает.
Причем тут смс и сайты однодневки - до сих пор не понимаю.
Дмитрий, ладно. не ну поняли значит не поняли. если читать межу строк, то можно понять, что в самом топике приведен пример в виде ФИО чтоб не раскрывать суть основной задачи. Но потом пришлось более подробно сказать.
Слава, ну окей. но пока мне кажется не понимаете вы - и что такое кеш и когда он нужен, и где и когда используется эластик. Ибо ни первое ни второе - ни коим образом не зависит от того по какому ключу вас запрашивают, и каким образом
Тебе прилетает запрос, ты проверяешь его наличие в списке воркеров и в списке решенных (пусть к примеру уже обработанные запросы повторно обрабатываются через какой то интервал, т.е. этот кеш чистишь по таймеру или пометку ставишь что устарел) затем если это новый запрос, складываешь в базу как задачу к воркеру и все.
Отдельным демоном может мониторить изменения в воркерах и рассылать клиентам по websocket отмашку что решение найдено вот смотрите, а иначе показывать страничку - мы работаем.
Ну и само собой демон или много, берут задачи из списка воркера и ищут.
вот беда в том что куда-то же входящие запросы нужно класть. а их слишком много. и мы положим базу данных если будем так часто к ней обращаться чтоб положить их в очередь. да и демоны не будут поспевать. а эластик нужен чтоб хорошо проиндексировать данные и чтоб легко было искать эти данные в нем. более гибко чем в обычной базе данных.
чтобы положить базу запросами в одну табличку с одним индексом, надо десятки тысяч запросов в секунду, и те неплохо линейно масштабируются через партицирование
