Indexation en masse et API Bulk

Indexing documents one HTTP request at a time is slow. The Bulk API packs many operations into a single request, dramatically improving throughput.

Bulk requests use newline-delimited JSON: each action line is followed by its source line (for index/create/update). Every line ends with a newline, including the last.

Here two documents are indexed in one call.

Bulk supports four actions:

• index — create or replace
• create — fail if the id exists
• update — partial update
• delete — no source line needed

A single bulk body can mix actions and even target different indices via the action metadata.

Crucially, the bulk request itself returns 200 OK even if some items fail. You must inspect the errors flag and per-item status.

There is no perfect number, but 1,000 to 5,000 documents (or a few megabytes) per bulk request is a good starting range. Measure and adjust for your data.

For huge initial loads, temporarily disable the refresh interval and reduce replicas, then restore them afterward.

Once the bulk load finishes, re-enable refresh and replicas so the data becomes searchable and durable.

A status of 429 (too many requests) means the cluster is overloaded. Retry only the failed items with exponential backoff, not the whole batch.

Official clients provide bulk helpers that chunk, send, and retry automatically, so you rarely build NDJSON by hand in production.

A bulk request returns HTTP 200. Is everything fine?

You learned the Bulk API: the NDJSON format, the four actions, why partial failures need per-item inspection, sensible batch sizes, load-time tuning of refresh and replicas, and retrying 429s with backoff.