CatgirlIntelligenceAgency/code
Viktor e8de468b0b
Make executor API talk GRPC (#75)
* (executor-api) Make executor API talk GRPC

The executor's REST API was very fragile and annoying to work with, lacking even basic type safety.  Migrate to use GRPC instead.  GRPC is a bit of a pain with how verbose it is, but that is probably a lesser evil.  This is a fairly straightforward change, but it's also large so a solid round of testing is needed...

The change set breaks out the GrpcStubPool previously residing in the QueryService, and makes it available to all clients.

ServiceId.name was also renamed to avoid the very dangerous clash with Enum.name().

The boilerplate needed for grpc was also extracted into a common gradle file for inclusion into the appropriate build.gradle-files.
2024-02-08 13:01:12 +01:00
..
api Make executor API talk GRPC (#75) 2024-02-08 13:01:12 +01:00
common Make executor API talk GRPC (#75) 2024-02-08 13:01:12 +01:00
features-convert (sample-exporter) Add some limits on sizes and lengths 2024-01-25 11:51:53 +01:00
features-crawl (doc) Update docs 2024-02-06 16:29:55 +01:00
features-index (index-construction) Split repartition into two actions 2024-02-06 17:20:07 +01:00
features-qs (search/index) Add a new keyword "count" 2023-12-25 20:38:29 +01:00
features-search (*) Replace EC_DOMAIN_LINK table with files and in-memory caching 2024-01-08 15:53:13 +01:00
libraries (array) Update documentation, make unsafe configurable 2024-02-07 12:26:47 +01:00
process-models (crawler) Extract additional configuration properties 2024-01-20 10:36:04 +01:00
processes (index-construction) Split repartition into two actions 2024-02-06 17:20:07 +01:00
services-application (search) Fix broken !w handling 2024-02-08 12:11:33 +01:00
services-core Make executor API talk GRPC (#75) 2024-02-08 13:01:12 +01:00
tools (doc) Update docs 2024-02-06 12:41:28 +01:00
readme.md (doc) Update docs 2024-02-06 12:41:28 +01:00

Code

This is a pretty large and diverse project with many moving parts.

You'll find a short description in each module of what it does and how it relates to other modules. The modules each have names like "library" or "process" or "feature". These have specific meanings. See doc/module-taxonomy.md.

Overview

A map of the most important components and how they relate can be found below.

image

The core part of the search engine is the index service, which is responsible for storing and retrieving the document data. The index serive is partitioned, along with the executor service, which is responsible for executing processes. At least one instance of each service must be run, but more can be run alongside. Multiple partitions is desirable in production to distribute load across multiple physical drives, as well as reducing the impact of downtime.

Search queries are delegated via the query service, which is a proxy that fans out the query to all eligible index services. The control service is responsible for distributing commands to the executor service, and for monitoring the health of the system. It also offers a web interface for operating the system.

Services

Processes

Processes are batch jobs that deal with data retrieval, processing and loading. These are spawned and orchestrated by the executor service, which is controlled by the control service.

Features

Features are relatively stand-alone components that serve some part of the domain. They aren't domain-independent, but isolated.

Libraries and primitives

Libraries are stand-alone code that is independent of the domain logic.

  • common elements for creating a service, a client etc.
  • libraries containing non-search specific code.
    • array - large memory mapped area library
    • btree - static btree library