IgGusev commented on code in PR #6553: URL: https://github.com/apache/ignite-3/pull/6553#discussion_r2348189830
########## docs/_docs/developers-guide/clients/overview.adoc: ########## @@ -105,6 +105,89 @@ For each key that needs updating, the client will get the name of the node holdi NOTE: Partition awareness assumes that the cluster is stable. Client receives information about cluster data assignments in the background, and it may be outdated by the time an update is sent. If it is, nodes will automatically redirect requests to correct nodes until data on the client is updated. +=== Limitations + +* As for now, Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. Review Comment: ```suggestion * Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. ``` ########## docs/_docs/developers-guide/clients/overview.adoc: ########## @@ -105,6 +105,89 @@ For each key that needs updating, the client will get the name of the node holdi NOTE: Partition awareness assumes that the cluster is stable. Client receives information about cluster data assignments in the background, and it may be outdated by the time an update is sent. If it is, nodes will automatically redirect requests to correct nodes until data on the client is updated. +=== Limitations + +* As for now, Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. + +* DML queries, which can **not** be rewritten to key-value operations, are not supported yet. + +Apache Ignite can execute a query as key-value operation only if the query contains an equality condition on all key columns. +Partition awareness will only work for DML queries if the query can be rewritten to a single key-value operation. The explain plan will contains `KeyValueGet` or `KeyValueModify` node in that case. +Bulk DML operations (like ```INSERT FROM SELECT``` or multi-values ```INSERT FROM VALUES```) are not supported yet. + +* Equality condition on colocation key columns is required. + +Apache Ignite can only apply partition awareness optimization if the SQL query contains an equality condition on all colocated columns. This requirement allows the client to route the query to the node where the partition with the data resides. + + +* Partition awareness cache on client may miss required metadata + +Client nodes do not parse or executed query by themselves, they require query metadata with colocation information from the server node to utilize partition awareness optimization. The query metadata is cached on client after the first query execution and can be used in later query runs. However, it also can be evicted due to cache eviction policies. + +See ```org.apache.ignite.client.IgniteClient.Builder#sqlPartitionAwarenessMetadataCacheSize()```. + +=== How to Check if Partition Awareness is Applicable + +You can verify whether partition awareness is used for a given SQL query by inspecting the EXPLAIN command results. + +* The resulting plan should contain a `TableScan` node with equality conditions on all colocation columns of the table: +---- +TableScan + table: PUBLIC.T + predicate: AND(=(COLOCATION_COL_1, ?), =(COLOCATION_COL_2, ?)) +---- +* or a similar `IndexScan` that search bound has a prefix of all the colocation columns: Review Comment: ```suggestion * or a similar `IndexScan` where the search bound has a prefix of all the colocation columns: ``` ########## docs/_docs/developers-guide/clients/overview.adoc: ########## @@ -105,6 +105,89 @@ For each key that needs updating, the client will get the name of the node holdi NOTE: Partition awareness assumes that the cluster is stable. Client receives information about cluster data assignments in the background, and it may be outdated by the time an update is sent. If it is, nodes will automatically redirect requests to correct nodes until data on the client is updated. +=== Limitations + +* As for now, Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. + +* DML queries, which can **not** be rewritten to key-value operations, are not supported yet. + Review Comment: ```suggestion * DML queries, which **cannot** be rewritten to key-value operations, are not supported yet. + ``` ########## docs/_docs/developers-guide/clients/overview.adoc: ########## @@ -105,6 +105,89 @@ For each key that needs updating, the client will get the name of the node holdi NOTE: Partition awareness assumes that the cluster is stable. Client receives information about cluster data assignments in the background, and it may be outdated by the time an update is sent. If it is, nodes will automatically redirect requests to correct nodes until data on the client is updated. +=== Limitations + +* As for now, Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. + +* DML queries, which can **not** be rewritten to key-value operations, are not supported yet. + +Apache Ignite can execute a query as key-value operation only if the query contains an equality condition on all key columns. +Partition awareness will only work for DML queries if the query can be rewritten to a single key-value operation. The explain plan will contains `KeyValueGet` or `KeyValueModify` node in that case. +Bulk DML operations (like ```INSERT FROM SELECT``` or multi-values ```INSERT FROM VALUES```) are not supported yet. + +* Equality condition on colocation key columns is required. + +Apache Ignite can only apply partition awareness optimization if the SQL query contains an equality condition on all colocated columns. This requirement allows the client to route the query to the node where the partition with the data resides. + + +* Partition awareness cache on client may miss required metadata + +Client nodes do not parse or executed query by themselves, they require query metadata with colocation information from the server node to utilize partition awareness optimization. The query metadata is cached on client after the first query execution and can be used in later query runs. However, it also can be evicted due to cache eviction policies. + Review Comment: ```suggestion Client nodes do not parse or execute queries by themselves, they require query metadata with colocation information from the server node to utilize partition awareness optimization. The query metadata is cached on client after the first query execution and can be used in later query runs. However, it also can be evicted due to cache eviction policies. + ``` ########## docs/_docs/developers-guide/clients/overview.adoc: ########## @@ -105,6 +105,89 @@ For each key that needs updating, the client will get the name of the node holdi NOTE: Partition awareness assumes that the cluster is stable. Client receives information about cluster data assignments in the background, and it may be outdated by the time an update is sent. If it is, nodes will automatically redirect requests to correct nodes until data on the client is updated. +=== Limitations + +* As for now, Apache Ignite can only apply partition awareness optimization for queries over single partition of a single table. + +* DML queries, which can **not** be rewritten to key-value operations, are not supported yet. + +Apache Ignite can execute a query as key-value operation only if the query contains an equality condition on all key columns. +Partition awareness will only work for DML queries if the query can be rewritten to a single key-value operation. The explain plan will contains `KeyValueGet` or `KeyValueModify` node in that case. +Bulk DML operations (like ```INSERT FROM SELECT``` or multi-values ```INSERT FROM VALUES```) are not supported yet. + +* Equality condition on colocation key columns is required. + +Apache Ignite can only apply partition awareness optimization if the SQL query contains an equality condition on all colocated columns. This requirement allows the client to route the query to the node where the partition with the data resides. + + +* Partition awareness cache on client may miss required metadata + +Client nodes do not parse or executed query by themselves, they require query metadata with colocation information from the server node to utilize partition awareness optimization. The query metadata is cached on client after the first query execution and can be used in later query runs. However, it also can be evicted due to cache eviction policies. + +See ```org.apache.ignite.client.IgniteClient.Builder#sqlPartitionAwarenessMetadataCacheSize()```. Review Comment: ```suggestion See ```org.apache.ignite.client.IgniteClient.Builder#sqlPartitionAwarenessMetadataCacheSize()``` for more information. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
