Is there a correlation between Index INLINE_SIZE and Index Column Data(String Type) in Apache Ignite?

Question

1. Is there a correlation between Index INLINE_SIZE and Index Column Data(String Type) in Apache Ignite?

2. In the following situation, when I insert data, an exception related to sorted index occurs, a lock/unlock message occurs, and the node goes down.

• Pure In-Memory

• PK_INLINE_SIZE=2000,AFFINITY_INLINE_SIZE=200(Using SQL WITH)

• Created 3 columns of varchar type as primary key

• Apache Ignite 2.16.0 (H2 DB Engine, I tested Calcite DB Engine, have same problem)

• Table has 20 columns(All varchar type)

Exception occurred at

• https://github.com/apache/ignite/blob/7bde6a42b7fda05f8058350d30d67e57ada216d0/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java#L2737

When I observed the relevant variables with the debugger, the value of p.rootlvl kept increasing.(exception occurs at p.btmlvl=129, p.rootlvl=129)

When PK_INLINE_SIZE was set to 200, the value of p.rootlvl did not increase as much as before.

• https://github.com/apache/ignite/blob/7bde6a42b7fda05f8058350d30d67e57ada216d0/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java#L2691

What's going on with the index b+tree creation that is causing page locks and bringing the node down?

This does not happen for other datasets. But I can reproduce the same situation for a specific dataset (dataset sharing is not possible...)

I'm trying to understand the code, but is there anyone can help...?

1. tested using different datasets

2. the dataset causing the problem contains special characters, so I tried removing them.

3. changed the size of the PK column to fixed (archer -> varchar(2000)

4. made PK columns 3 to 2 but. same....

Answer 1

The reason is that your index inline size is too large. Currently Ignite is too permissive and allows misconfiguration. In case of a such configuration it's possible that b+tree degrades into too many layers and hits internal checks you faced (internal depth limit is 128). There's a ticket to improve validation and logging.

The problem is that a page can only contain one large element. Inline items are all the same size, and fit on one page each. For some datasets, this makes it fail very quickly - for example, when trying to insert lexicographically sorted (or even "almost" sorted) strings. It also depends on a few things that affect page layout, e.g. TDE. It's not your case as you have pure In-Memory.

You need to reduce your index inline size to make it more reasonable. If you really need it to be like this then consider increasing page size.