/7.1/tuning/Recent content in Performance Optimization on Kinetica DocsHugo -- gohugo.ioen/7.1/tuning/cs/geo/Mon, 01 Jan 0001 00:00:00 +0000/7.1/tuning/cs/geo/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./7.1/tuning/multihead/multihead_egress/Mon, 01 Jan 0001 00:00:00 +0000/7.1/tuning/multihead/multihead_egress/Multi-Head Egress (Distributed Key Lookup) 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 egress mechanism is a lookup of a given shard key value in a given table or view, filtering out any records that don't match an optional expression./7.1/tuning/multihead/multihead_ingest/Mon, 01 Jan 0001 00:00:00 +0000/7.1/tuning/multihead/multihead_ingest/Multi-Head Ingest (Distributed 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. Operationally, the ingest mechanism calculates the target shard of each record to insert, and sends batches of would-be co-located records to their respective target nodes. To fully utilize multi-head ingest, the ingestion process should use a multi-node parallel processing framework, such as MapReduce, Storm, or Spark./7.1/tuning/multihead/multihead_use_case/Mon, 01 Jan 0001 00:00:00 +0000/7.1/tuning/multihead/multihead_use_case/A common, highly-performant use case for Kinetica is multi-head ingest into a fact table and multi-head egress from a materialized view created from that fact table, periodically refreshed at some interval. The example given below can be downloaded & run to demonstrate the use case on a local Kinetica instance. This guide will demonstrate a simple use case, implemented in Java & SQL, consisting of four entities: Multi-Head Ingest Client Fact Table (ingestion target) Materialized View from Fact Table (egress source) Multi-Head Egress Client Multi-Head Ingest/Egress