Distributed
In a distributed deployment, part of the data stays where it already is, in a gateway at a site, a service next to the devices or a system you can't move. Andromeda registers each of these as a context source and answers for it. A client queries one broker and gets one set of entities, wherever each of them is held.
- ConsumersApplications, dashboards
- answers, notifications
- AndromedaDistribution broker, keeps the registrations
- answers to what the broker forwards
- Site gatewayEntities of one siteLegacy adapterOne attribute familyAnother brokerWhole entities
When it fits
- The data has a natural home, and copying it into the broker would mean keeping two copies in step.
- The sources belong to the same deployment, run by the same team or by teams close enough to agree on a data model.
- Consumers shouldn't need to know where an entity lives.
When the sources are whole brokers run by other teams, federated fits better. The parts are the same, and what changes is who runs them.
What runs
- One Andromeda and its PostgreSQL server, as in a single broker. The broker can hold data of its own beside what the sources hold.
- The sources. Each one needs to serve only the NGSI-LD operations its registration lists, and none of them has to be Andromeda, or even a broker.
The broker is its own registry. Registrations are stored in it, and a consumer can read them at GET /ngsi-ld/v1/csourceRegistrations and go to a source directly if it prefers. A consumer that doesn't care asks the broker and never learns which of the two answered.
What a registration decides
A registration's mode decides how a source relates to the broker's own data. The Distributed guide goes through the four modes with examples.
A registration also lists the operations its source accepts. By default only reads are forwarded, so a source never receives a write it didn't ask for.
What to set
Example deployment
One broker with its database, and one source. sensor-gateway stands for your own service. Any image that serves the NGSI-LD query operations on port 8080 will do, and the image name here is a placeholder.
Start it
echo "POSTGRES_PASSWORD=$(openssl rand -hex 24)" > .env
name: andromeda
services:
postgresql:
image: ghcr.io/mskvarc/postgresql:18.6-timescaledb2.31.0-postgis3.6.4-tsl
restart: unless-stopped
environment:
POSTGRES_USER: andromeda
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
POSTGRES_DB: andromeda
mem_limit: 4g
cpus: 2
volumes:
- postgresql-data:/var/lib/postgresql
andromeda:
image: ghcr.io/mskvarc/andromeda:1.0.0
restart: unless-stopped
depends_on:
postgresql:
condition: service_healthy
environment:
ANDROMEDA__DATABASE__CONNECTION: postgres://andromeda:${POSTGRES_PASSWORD}@postgresql:5432/andromeda
ANDROMEDA__SERVER__PUBLIC_URL: http://andromeda:1056/
ANDROMEDA__FEDERATION__IDENTITY__SOURCE_ALIAS: andromeda
ANDROMEDA__FEDERATION__COOLDOWN__MODE: exponential
ANDROMEDA__FEDERATION__FORWARDING__REQUEST_TIMEOUT: 3s
ports:
- "1056:1056"
# Your own service, standing for the source. Replace the image.
sensor-gateway:
image: registry.example.org/sensor-gateway:1
restart: unless-stopped
expose:
- "8080"
volumes:
postgresql-data:
Start it with docker compose up -d.
Register the source
Register the gateway as the source of the Vehicle entities it holds.
curl -i http://localhost:1056/ngsi-ld/v1/csourceRegistrations \
-H 'Content-Type: application/json' \
-d '{
"id": "urn:ngsi-ld:ContextSourceRegistration:sensor-gateway",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"type": "Vehicle"
}
]
}
],
"endpoint": "http://sensor-gateway:8080/"
}'
Query through the broker
A query for Vehicle entities at the broker now reaches the gateway as well.
curl -s 'http://localhost:1056/ngsi-ld/v1/entities?type=Vehicle' \
-H 'Accept: application/ld+json'
If the gateway is down, the broker still answers with everything else and adds a warning that names the registration.