ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray <ray...@cisco.com>
Subject Performance of SQL query by partial primary key
Date Fri, 14 Sep 2018 06:45:16 GMT
I have some trouble understanding how Ignite maintain primary key.
This document
https://apacheignite.readme.io/docs/memory-architecture#section-b-trees-and-index-pages
says "The cache keys are also stored in B+ trees and are ordered by their
hash code values."

So if I create a table using this command, create table t(a varchar, b
varchar, c varchar, primary key(a,b));
The primary key for this table is a custom object consists of a and b.

So my question is when I try to query this table using this sql "select c
from t where a= 'some value' " , will there be a performance issue when
table t contains billions of records?


Quote from
"https://apacheignite.readme.io/docs/memory-architecture#section-b-trees-and-index-pages"

"For instance, when myCache.get(keyA) operation is executed, it will trigger
the following execution flow:

1. Ignite will look for a memory region to which myCache belongs to.
2. The meta page pointing to the hash index B+ tree of myCache will be
located.
3. Based on the keyA hash code, the index page the key belongs to will be
located in the B+ tree.
4. If the corresponding index page is not found in the memory or on disk,
then Ignite concludes that the key does not exist and will return null.
5. If the index page exists, then it will contain all the information needed
to find the data page of the cache entry keyA refers to.
6. Ignite will locate the data page for keyA and will return the value to
the user."


When I use the above query to get records, the where statement only contains
partial primary key.
So there's no way for calculate the key hash code in step 3, right?
I wonder how Ignite handles this case, does Ignite perform a whole table
scan?




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Mime
View raw message