patternMinor
Versioning: Is this technology used in DBMS other than spatial?
Viewed 0 times
thisusedthanotherdbmsversioningspatialtechnology
Problem
ESRI's spatial database management systems, called geodatabases (more), use a technology called versioning.
A version represents a snapshot in time of the entire geodatabase and
contains all the datasets in the geodatabase.
Versions are not separate copies of the geodatabase. Instead, versions
and the transactions that take place within them are tracked in system
tables. This isolates a user's work across multiple edit sessions,
allowing users to edit without locking features in the production
version or immediately impacting other users and without having to
make copies of the data.
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/basicprinciples/state.htm
When you register a dataset (a feature class, feature dataset, or
table) as versioned, two delta tables are created: the A (or adds)
table, which records insertions and updates, and the D (or deletes)
table, which stores deletions. Each time you update or delete a record
in the dataset, rows are added to one or both of these tables. A
versioned dataset, therefore, consists of the original table (referred
to as the base or business table) plus any changes in the delta
tables. The geodatabase keeps track of which version you were
connected to when you made the edits that populated the delta tables.
When you query or display a dataset in a version, ArcGIS assembles the
relevant rows from the original table and the delta tables to present
a seamless view of the data for that version.
To be honest, I find the documentation to be rather vague; it doesn't tell me much about how the technology actually works, or what part of traditional database theory it is based on.
I don't imagine many DBA SE community members would have experience with ESRI's versioning technology. So I won't ask something like 'how does it work?'.
Instead, I'm wondering, are there any technologies in the non-spatial database world that are similar to ESRI versioning?
A version represents a snapshot in time of the entire geodatabase and
contains all the datasets in the geodatabase.
Versions are not separate copies of the geodatabase. Instead, versions
and the transactions that take place within them are tracked in system
tables. This isolates a user's work across multiple edit sessions,
allowing users to edit without locking features in the production
version or immediately impacting other users and without having to
make copies of the data.
http://help.arcgis.com/en/geodatabase/10.0/sdk/arcsde/concepts/versioning/basicprinciples/state.htm
When you register a dataset (a feature class, feature dataset, or
table) as versioned, two delta tables are created: the A (or adds)
table, which records insertions and updates, and the D (or deletes)
table, which stores deletions. Each time you update or delete a record
in the dataset, rows are added to one or both of these tables. A
versioned dataset, therefore, consists of the original table (referred
to as the base or business table) plus any changes in the delta
tables. The geodatabase keeps track of which version you were
connected to when you made the edits that populated the delta tables.
When you query or display a dataset in a version, ArcGIS assembles the
relevant rows from the original table and the delta tables to present
a seamless view of the data for that version.
To be honest, I find the documentation to be rather vague; it doesn't tell me much about how the technology actually works, or what part of traditional database theory it is based on.
I don't imagine many DBA SE community members would have experience with ESRI's versioning technology. So I won't ask something like 'how does it work?'.
Instead, I'm wondering, are there any technologies in the non-spatial database world that are similar to ESRI versioning?
Solution
What you are describing seems really similar to MMVC- https://en.wikipedia.org/wiki/Multiversion_concurrency_control Where different clients can have a different "view" or "version" of the same database, and edits done withing a transaction cannot be seen by other sessions until they decide so by executing "COMMIT".
That concept is not exclusive to spatial databases (the wiki cites a 1981 paper as one of the first descriptions of it: https://en.wikipedia.org/wiki/Multiversion_concurrency_control#cite_note-3 ) but the concept has to be older than that. And while I see some special needs and implementations for extra dimensions, the essentials would be the same.
The implementation, of course, can vary widely from engine to engine. Git, even if not a database, it has to implement concurrency control in a particular way, and that will be completely different to how postgres does it. If then we go to distributed databases, we arrive to the wild west of keeping consistency thought heterogenous systems over the net. You want an implementation that is performant for the most useful cases, and all optimizations imply a trade off for operations considered not as important. One that is fast for small transaction sizes may be too expensive or unbearable for large edits. Also, different database engines interpret thing like consistency levels on its own way.
The good news is that with the rise of open-source database systems, you do not need to read large manuals anymore to understand what is happening internally- you can read the source code directly yourself and understand how those are written. For example, for Innodb:
That concept is not exclusive to spatial databases (the wiki cites a 1981 paper as one of the first descriptions of it: https://en.wikipedia.org/wiki/Multiversion_concurrency_control#cite_note-3 ) but the concept has to be older than that. And while I see some special needs and implementations for extra dimensions, the essentials would be the same.
The implementation, of course, can vary widely from engine to engine. Git, even if not a database, it has to implement concurrency control in a particular way, and that will be completely different to how postgres does it. If then we go to distributed databases, we arrive to the wild west of keeping consistency thought heterogenous systems over the net. You want an implementation that is performant for the most useful cases, and all optimizations imply a trade off for operations considered not as important. One that is fast for small transaction sizes may be too expensive or unbearable for large edits. Also, different database engines interpret thing like consistency levels on its own way.
The good news is that with the rise of open-source database systems, you do not need to read large manuals anymore to understand what is happening internally- you can read the source code directly yourself and understand how those are written. For example, for Innodb:
- https://www.percona.com/live/mysql-conference-2013/sessions/innodb-journey-core
- https://github.com/mysql/mysql-server/blob/5.7/storage/innobase/row/row0undo.cc
Context
StackExchange Database Administrators Q#168411, answer score: 4
Revisions (0)
No revisions yet.