검색 엔진 소프트웨어의 스레딩 및 프로세스 아키텍처에 대한 제안

Question

이 소프트웨어는 고전적인 검색 엔진입니다. 크롤링/데이터 수집을 담당하는 앱의 한 부분이 있으며 데이터를 가져 와서 색인이나 데이터베이스를 만드는 앱이 있습니다. 마지막 부분은 클라이언트의 쿼리를 처리하고 결과를 검색하기 전에 데이터에 대한 검색을 수행합니다.

필자가 논의중인 특정 엔진은 데이터가 자주 업데이트되므로 (분당 한 번 이상) 쿼리가 항상 최신 데이터에서 작동해야하는 엔진입니다.

내 질문에 간단합니다. 이 세 가지 작업을 세 개의 개별 프로세스로 처리해야합니까? 아니면 하나의 프로세스에 다중 스레드를 각각 처리해야합니까?

내 질문에 대한 주요 이유는 메모리를 파티션하는 가장 좋은 방법에 관한 것입니다. 검색자가 인덱서에 사용할 수있는 데이터를 업데이트해야하고 인덱서가 쿼리 처리기의 데이터 집합을 업데이트해야하는 경우 모두가 동일한 프로세스에서 살면서 주소 공간이 같은 것이 합리적일까요? 또는 공유 메모리 맵 파일을 사용하는 별도의 프로세스를 사용할 수 있습니까?

나는 클러스터링, 배포 등을 가능하게하기 위해 각기 다른 시스템에 살 수 있도록 별도의 프로세스에 기울이고있다. 그러나 더 작은 데이터 세트의 원시 속도면에서 통합 접근 방식이 선호 될 것인가?

OS는 Windows이고 언어는 C++입니다.

Answer 1

저는 전문가는 아니지만 최적의 유연성, 확장 능력, 관리하기 쉬운 (한 서비스를 다시 시작하면 다른 서비스는 제대로 수행하지 못함) 성능을 제공하므로 별도의 프로세스 접근 방식에 기대고 있습니다.

다른 작업에도 다른 데이터베이스를 고려하고 싶습니다. 하나의 구성 요소가 하나의 작업을 수행하는 방식을 취하고 잘 수행하면 DB에이 원칙을 적용하는 것이 좋습니다.

나는 성능 병목이 어디서 어떻게 보이는지에 따라 다릅니다. 초기 수집 영역의 라인, 즉 준비 영역 (정렬 등)과 빠른 액세스 및 검색 전용 영역에 대해 생각하고 있습니다.

SQL/SQL 일괄 처리/ETL은 최상의 성능을 제공합니다.

생각해 보면 - 솔루션을 함께 구성한 3 개의 별도 애플리케이션을 구축 할 것입니다. 또한 이 실제로 인 경우 다른 작업에 서로 다른 기술을 사용할 수 있습니다. 보다 유연한 유지 보수 경로를 허용합니다.