What is a Compressed Prefix B+-Tree (CPBTree) in SAP HANA? I'm studying the SAP HANA main memory database.
There is an index called CPBTree in it. In its documentation, it is described as follows:

CPB+-tree stands for Compressed Prefix B+-Tree; this index tree type
is based on pkB-tree. CPB+-tree is a very small index because it uses
'partial key' that is only part of full key in index nodes.

This is a bit vague. There are no other explanations about the CPBTree's structure on the Internet.
Is there anyone who can provide an explanation more or refer me to good documentation/URLs/&amp;c.?
I'll assume you know what a B-Tree is. In a B+-Tree the leaf nodes contain all the column of the rows. A compressed B-Tree uses some form of compression to fit more information on each page. Compression is desirable because it maximizes the amount of information passed for each data movement. In a disk-based system the movements are between disk and RAM. For HANA the transfers are between RAM and CPU cache; memory stalls and cache flushes are significant in this architecture.
One possible compression is prefix compression. Here index key values are compared. When a common set of leading characters (a prefix) are identified they are removed from the key and stored separately. At run-time the prefix is implicitly re-attached to the remainder.
For example, say we have an index on the names of people from the Doomsday Book.
William of Braose
William of Ecouis
William of Falaise
William of Keynes
William of Poilley

To store these as-is requires 88 bytes at least. We note that the first 11 characters of each key is identical. This can be extracted as the prefix meaning only the unique part consumes space:
&quot;William of &quot;..
Braose
Ecouis
Falaise
Keynes
Poilley

This needs 44 characters - a 50% reduction in IO, cache miss etc.
This is likely to be effective because a B-Tree is an ordered list of keys. Keys which sort together are likely to be physically adjacent. Further, for large datasets the keys must be long since they have to distinguish between many rows. This means there will be many keys where the most significant (i.e. left-most) bytes are identical. (For small datasets without shared prefixes who cares! They're small and will be processed quickly whatever.)
The same applies to numeric values. Imagine a table whose primary key is a system-assigned incremental integer. After one hundred million rows have been added, the next rows will have values
100,000,001
100,000,002
100,000,003
...

The prefix can be the 4-byte integer &quot;100,000,000&quot; and the unique part held in a single byte each. For numbers this is also known as delta encoding.

I haven't watched it but one would imagine this would be relevant since it's presented by Dr. Plattner, The &quot;P&quot; of SAP.
https://open.hpi.de/courses/imdb2017/items/3S9yMQPPAjYHzgYwFd2DMF