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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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