API Support
Configuration
Distributed operations are enabled through configuration:- Distributed operations needs to be enabled on the server (default)
- Client-accessible URLs need to be set for each node in the cluster
Server-Side
In order for the cluster nodes to receive data directly from an ingest client, the configuration on each node needs to be set to allow the incoming HTTP requests for that data. The/opt/gpudb/core/etc/gpudb.conf file
needs to have the following property set for distributed ingest to work
properly:
gpudb.conf:
public_url is not defined, each node can be connected to on any of its
available interfaces, taking HA and
HTTPD configurations, as well as any
general network security restrictions into account.
Client-Side
The list of URLs for connecting to each worker node is automatically created when using the following:- Java API default
BulkInserter - Python API
GPUdbTableconfigured for background distributed operations
public_url was configured on each server node,
workers may have more than one IP address, not all of which may be accessible to
the client. The API worker list constructor uses the first IP in the list
returned by the server for each worker, by default. To override this behavior,
a regular expression Pattern or prefix String can be used to match the
correct worker IP addresses:
Considerations
There are several factors to consider when using distributed ingest:- There is a small performance penalty for calculating the shard key of each record to be inserted into a sharded table.
- There is an additional per-record performance penalty for primary key collision checks for any target table that has a primary key that is not the same as its shard key (the shard key columns are a proper subset of the primary key columns)
- Randomly-sharded tables benefit more from distributed ingest than sharded tables do, as there is no target shard key to calculate for each record and, therefore, no associated performance penalty for that calculation.
- The batch size used to configure the bulk ingest object determines the record threshold for each of the insert queues targeting the worker nodes, not the record threshold for the bulk ingest object itself. Thus, ingestion into tables with non-uniform record distribution may require periodic flushes of the bulk ingest queues to ensure timely insertion of records in queues that infrequently reach their threshold.
Example
All the functionality for distributed ingestion is encapsulated in the bulk ingest object. See API Support for chart listing the API-specific object to use for bulk ingestion. The following is a Java API code block that demonstrates the use of theBulkInserter for ingesting data.
If the
BulkInserter is not declared as the resource in a
try-with-resources block, the close() method needs to be called
explicitly after use to release its resources.However, for a one-time use, as in this example, the flush() call can be
removed, as the close() method will automatically call flush().Java Distributed Ingest
There are several options for distributed ingest using the JavaBulkInserter.
Ingest Modes
While all ingest schemes using theBulkInserter provide automatic batching
of records and reduction in network traffic to, and processing load on, the head
node, many also provide the benefit of parallelizing the batch inserts.
Ingest Object Types
TheBulkInserter supports three types of record objects, each offering a
different balance of type safety, flexibility, and schema migration support.
Python Distributed Ingest
There are two options for distributed ingest using Python. Both objects provide automatic batching of records and reduction in network traffic to, and processing load on, the head node; though, neither offers the benefit of any inherent parallelism.
Note that the list insert functions are effectively wrappers for the single
insert functions in the examples below; they serve as a convenience and do not
provide any inherent performance benefit.
Cautions
If using the Java API and MapReduce, there is a conflict between the version of Avro used by Kinetica and the one used by MapReduce. This conflict can be overcome by using the Maven shade plug-in with therelocation tag: