Endeca Server is the control center for Endeca data stores.
Endeca Server uses a database-like operational model to manage the Endeca data stores running on the machine. You install one (and only one) Endeca Server on a Linux or Windows machine that will host your Endeca data stores.
When you first install Endeca Server, it will have no Endeca data stores. You then create named data stores (potentially more than one per Endeca Server). In the simplest case, no information is needed to create and start a data store, other than a name for the data store. In this simple case, Endeca Server will figure out which port to start the data store and which Dgraph configuration flags to use. In the more complex case, you can specify the ports and configuration flags to be used (such as how many threads) and the location of the data files for the newly-created data store.
Once an Endeca data store is created, you only need to use the name of the data store to manage it. You don't even need to know which port the data store is running on, as Endeca Server keeps track of that information (which it stores in its own database). This name-only reference makes it much easier to stop and start data stores, as well as perform other management operations.
Endeca Server has a set of commands with which you create and control the data stores. These commands are documented in the chapter Oracle Endeca Server Commands.
Endeca Server is responsible for keeping each Endeca data store up and running, and therefore constantly monitors each data store.
If an Endeca data store crashes, Endeca Server attempts to re-start it. If the re-start attempt is unsuccessful, Endeca Server does not try to re-start it again.
By default, these logs are stored in the endeca-server\logs directory.
Each Endeca data store is serviced by a Dgraph process. The Dgraph uses proprietary data structures and algorithms that allow it to provide real-time responses to client requests. It stores the data files that were created from loading the data into it. After the data files are stored, the Dgraph receives client requests via the application tier, queries the data files, and returns the results.
The Dgraph is designed to be stateless. This design requires that a complete query be sent to it for each request. The stateless design facilitates the addition of Dgraph processes for load balancing and redundancy — any replica of a Dgraph can reply to queries independently of other replicas.