You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now tarantool can provide a database read view for snapshot dump and replica join. It is implemented via several mechanisms, one of them is a a read view in matras data structure which is used in indexes.
Creation of a read view in matras is extremely cheap and O(1). But deletion of a read view is O(N) where N is close to the number of distinct changes in matras data. The good news are that is O(1) amortized and the coefficient before N is usually very small, like 0.03 or something like that.
Now tarantool read view is used only for snapshot dump (checkpoint) and for replica join, both happens very seldom (several times per day? hour?). But since we want to create user read views that could be created/deleted several times per second we have to have guarantee of O(1) matras deletion.
Since it is O(1) amortized it can be simply implemented with postponing some delete operations to further matras calls.
On a way it would be perfect to lower memory requirements for matras and its read view: now the first CoW operation clones 3 pages of 16kB each. Technically it's possible to reduce the number of pages if there are not so many tuples in a space.
The text was updated successfully, but these errors were encountered:
Now tarantool can provide a database read view for snapshot dump and replica join. It is implemented via several mechanisms, one of them is a a read view in matras data structure which is used in indexes.
Creation of a read view in matras is extremely cheap and O(1). But deletion of a read view is O(N) where N is close to the number of distinct changes in matras data. The good news are that is O(1) amortized and the coefficient before N is usually very small, like 0.03 or something like that.
Now tarantool read view is used only for snapshot dump (checkpoint) and for replica join, both happens very seldom (several times per day? hour?). But since we want to create user read views that could be created/deleted several times per second we have to have guarantee of O(1) matras deletion.
Since it is O(1) amortized it can be simply implemented with postponing some delete operations to further matras calls.
On a way it would be perfect to lower memory requirements for matras and its read view: now the first CoW operation clones 3 pages of 16kB each. Technically it's possible to reduce the number of pages if there are not so many tuples in a space.
The text was updated successfully, but these errors were encountered: