Basic concepts

⚠️ Only tables with incremental data can be updated. Full tables cannot be updated.

Background

• In iGraph, data additions, deletions, and modifications are all processed as incremental updates. These update messages are also known as incremental messages or incremental data.

• iGraph uses a producer-consumer model that is based on the SWIFT message queue service. In this model, iGraph acts as the consumer of incremental messages, and you act as the producer.

• iGraph uses an asynchronous update pattern and ensures eventual consistency.

• You can update data using the iGraph client, Blink, Porsche, or other custom methods. The update paths are as follows:

• iGraph client: iGraphClient --> swift gateway --> swift --> iGraph Searcher

• swift client: swiftClient --> swift --> iGraph Searcher

Validity of incremental messages

• Purely incremental data from a SWIFT data source has a time to live (TTL).

• iGraph does not guarantee persistence for incremental messages.

Traffic limits

• The client update API has a maximum tested throughput of 1,400 queries per second (QPS) on a single machine.

• SWIFT supports a write throughput of up to 100,000 QPS.

• The maximum QPS for an iGraph Searcher on a single machine to pull updates from SWIFT is 50,000. A single instance can achieve 200,000 to 1,600,000 QPS. This capacity is shared across all tables within the instance.

Update latency

• Client update API latency: The average latency is 2 ms to 5 ms within the same data center.

• Incremental data propagation time: Data is available within 1 second in most cases, but this can occasionally increase to 3 seconds.

• The client update API is asynchronous. It returns a response after sending the message to the SWIFT message queue. Therefore, a delay occurs between when the update is confirmed and when the data is available in query results.