<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance Optimization on Kinetica Docs</title><link>/7.2/tuning/</link><description>Recent content in Performance Optimization on Kinetica Docs</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="/7.2/tuning/index.xml" rel="self" type="application/rss+xml"/><item><title>Distributed Ingest</title><link>/7.2/tuning/multihead/multihead_ingest/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/7.2/tuning/multihead/multihead_ingest/</guid><description>Distributed Ingest (Multi-Head Ingest) is a mechanism that allows sharded data to be ingested directly into cluster nodes, bypassing the overhead of pushing the data through the head node to the cluster nodes. This greatly increases the speed of ingest by spreading the network traffic across multiple nodes.
Operationally, the ingest mechanism calculates the target shard key of each record to insert, and sends batches of co-located records to their respective target nodes.</description></item><item><title>Distributed Ingest &amp; Key Lookup Use Case</title><link>/7.2/tuning/multihead/multihead_use_case/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/7.2/tuning/multihead/multihead_use_case/</guid><description>A common, highly-performant use case for Kinetica is distributed ingest into a fact table and distributed key lookup from a materialized view created from that fact table, periodically refreshed at some interval.
The example given below can be downloaded &amp;amp; run to demonstrate the use case on a local Kinetica instance.
This guide will demonstrate a simple use case, implemented in Java &amp;amp; SQL, consisting of four entities:
Distributed Ingest Client Fact Table (ingestion target) Materialized View from Fact Table (key lookup source) Distributed Key Lookup Client Distributed Ingest &amp;amp; Key Lookup</description></item><item><title>Distributed Key Lookup</title><link>/7.2/tuning/multihead/multihead_egress/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/7.2/tuning/multihead/multihead_egress/</guid><description>Distributed Key Lookup (Multi-Head Egress) is a mechanism that allows sharded data to be retrieved directly from cluster nodes, bypassing the overhead of pulling the data through the head node from the cluster nodes. This greatly increases the speed of retrieval by spreading the network traffic across multiple nodes.
Operationally, the key lookup mechanism is the retrieval of a given shard key value in a given table or view, filtering out any records that don't match an optional expression.</description></item><item><title>Geospatial Queries</title><link>/7.2/tuning/cs/geo/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/7.2/tuning/cs/geo/</guid><description>Geospatial Partitioning Geospatial partitioning is a method for organizing geospatial data, grouping spatial entities in close proximity to each other. This geospatial grouping allows for accelerated geospatial processing of the grouped data.
Geospatial joins, specifically, will take advantage of this process improvement. An increase in performance using this technique will be proportional to the size of the data being joined.
Example The goal of the geospatial join in this example is to show flights that landed at (or passed over) JFK airport.</description></item></channel></rss>