Предложения для потоковой обработки и архитектуры процесса для программного обеспечения для поисковых систем

Question

Программное обеспечение является классической поисковой системой. Есть одна часть приложения, которому поручено обходить/собирать данные, а есть еще один, который берет эти данные и строит индекс или базу данных. Последняя часть обрабатывает запросы от клиентов и выполняет поиск по данным, прежде чем извлекать результаты.

Конкретный движок, который я обсуждаю, - это тот, где данные часто обновляются (не реже одного раза в минуту), поэтому запросы всегда должны работать с последними данными.

Мой вопрос прост. Должны ли эти три задачи обрабатываться тремя отдельными процессами или одним процессом с несколькими потоками, предназначенными для каждого?

Основная причина моего вопроса - наилучший способ разделить память. Если поисковик должен обновить доступные данные для индексатора, а индексирующее устройство должно обновить наборы данных для обработчика запросов, будет ли смысл, чтобы все они жили в одном процессе и имели одно и то же адресное пространство? Или было бы приемлемо иметь отдельные процессы, которые используют файлы с распределенной памятью?

Я склоняюсь к отдельным процессам, чтобы каждый мог жить на другой машине, позволяя кластеризовать, распределять и т. Д. Но с точки зрения необработанной скорости для меньших наборов данных предпочтительным был бы консолидированный подход?

ОС - это Windows, язык C++.

Answer 1

Я не эксперт, но я бы склонялся к индивидуальному подходу к процессам, поскольку это дает максимальную гибкость, способность масштабироваться, легко управляется (перезапуск одной службы не влияет на других) и производительность.

У меня также возникнет соблазн рассмотреть различные базы данных для различных задач. Если вы примете подход к тому, чтобы один компонент выполнял одно задание - и делаете это хорошо, тогда имеет смысл применить этот принцип к БД.

Это зависит от того, где вы видите, как вы делаете это. Я размышляю о линиях начальной области сбора, возможно, о промежуточной области (сортировка и т. Д.) И о последней области, предназначенной для быстрого доступа и поиска.

SQL-SQL пакетных процессов/ETL даст лучшую производительность, я думаю.

Подумайте об этом - я бы построил 3 отдельных приложения, которые вместе сформировали решение. Это также позволило бы использовать различные технологии для разных задач, если бы вы действительно хотели. Позволяет использовать более гибкий путь обслуживания.