Wednesday, March 19, 2008

Xtensive.Indexing architecture: physical view

Physical view

As I've briefly described in previous post, any logical index is actually represented by a stack of physical indexes (slices) laying one over another. Each slice "contains" just the changes made to the logical index state described by a previous slice, and so on - till the "ground" slice. Ground slice contains the changes made to an empty index. Let's try to show this in the table:

Logical index: PK_Customers

Visible slices:
- Slice 0 (ground): size: 10Gb, transactions: 1...13352, status: on disk, read-only // All the changed made to an empty index in transactions 1...13352
- Slice 1: size: 4Gb, transactions: 13353...21249, status: on disk, read-only // All the changes made in transactions 13353...21249
- Slice 2: size: 3Gb, transactions: 21250...27498, status: on disk, read-only
...
- Slice 10: size: 100Mb, transactions: ..., status: on disk, read-only
...
- Slice 100: size: 100Kb, transactions: 32453...32460, status: in memory, read-only
- Slice 101: size: 10Kb, transactions: 32461...32462, status: in memory, read-only
- Slice 102: size: 1Kb, transactions: 32464...32464, status: in memory, read-only

Index merge process slices (not yet visible, but managed):
- Slice 1.M: size: 6Gb, transactions: 13353...27498, status: on disk, serializing // A result of merging Slice 1 & Slice 2
...
- Slice 99.M: size: 150Kb, transactions: ... ...32460, status: in memory, serializing // A result of merging Slice 99 & Slice 100

Active transaction slices (visible to a particular transaction)
...
- Slice 101.32463: size: 1Kb, transactions: 32463...32463, status: in memory, read-write // All the changes made in transaction 32463, that was started after commit of transaction 32462 (Slice 101), and isn't completed yet
- Slice 102.32465: size: 1Kb, transactions: 32463...32463, status: in memory, read-write // All the changes made in transaction 32465, that was started after commit of transaction 32464 (Slice 102), and isn't completed yet

So that's how everything should look like. Slice names here are just readable examples (real names will be different). Now let's study what benefits such index representation may give us, and what problems we may get with it comparing this to regular indexing approach (concurrent access to a single B+tree based index).


Pros. and Cons.

[To be continued...]

No comments:

Post a Comment