Skip to main content

High-throughput ingestion

A common job: push a steady, high-volume stream of sensor readings in so a dashboard or alerting rule can act on them. The SDK does the heavy lifting — it chunks the data into batches and sends them concurrently, retrying transient failures.

How it works

Datapoints are split into batches (default 10,000 per request — the store is optimised for large batches), sent concurrently up to a bounded in-flight limit, and transient failures (HTTP 429/5xx, network) are retried. The Java client returns an IngestResult summarising what landed and what didn't.

Ingest a million readings

ingest groups datapoints by series external id and returns an IngestResult.

var client = DatahubClient.fromEnv();

// readings: Map<String, List<Datapoint>> grouped by time-series external id
IngestResult result = client.timeseries().ingest(readings,
IngestOptions.builder()
.batchSize(10_000) // datapoints per request
.parallelism(16) // concurrent in-flight batches
.maxRetries(3)
.build());

System.out.printf("ingested %,d, failed %,d%n", result.succeeded(), result.failed());

Tuning (Java)

The ingest knobs let you trade throughput against load on the server:

OptionDefaultMeaning
batchSize10_000Datapoints per request.
parallelism8Concurrent in-flight requests.
maxRetries3Retries for transient failures.
failFastfalseAbort on the first failed batch instead of collecting errors.

When failFast is off, inspect result.errors() for the per-batch failures. See the Time-series reference for the full result shape.

Then chart the trend

Once the data is in, roll it up to hourly or daily buckets for a dashboard — see Query & aggregate time-series.

Ordering

Batches are sent in parallel, so there is no cross-batch ordering guarantee — which is fine for time-stamped data, since each datapoint carries its own timestamp.