 | |
DDS for MVCC Support now Available
comp.databases.ingres comp.databases.ingres
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
DDS for MVCC Support now Available -
10-26-2009
, 03:05 PM
#2
| |||
| |||
|
|
The Design Specifications for MVCC Support in Ingres is available for review at 'MVCC - Ingres Community Wiki' (http://community.ingres.com/wiki/MVCC) |
few exceptions, the architecture of this is almost identical to Oracle's
MVCC design and implementation for acquiring a CR version of a block, which
is heavily patented for not only a single-server software architecture, but
also multi-server clustered architectures as well. For example, 4.1.9.1
lists CR buffers as being linked from the current version. While this is a
seemingly obvious implementation for all chained hash table-based DB buffer
management implementations, it is no different for Oracle. In Oracle, all
versions of a buffer similarly hash to the same bucket, and all are chained
to the current version. Likewise, the process listed in 4.1.9.4 is quite
close to Oracle's implementation in that they determine whether a CR version
needs to be created (by comparison of the SCN [similar to the comparison
against crib_low_lsn]), and perform iterative UNDO on that block
accordingly. While the high-level design is similar, in addition to the
coarse-grained block-level UNDO, Oracle can also follow a single tuple back
through multiple versions, which I don't see any conflict with here. Both
Oracle and SQL Server now support Postgres-like tuple-based MVCC for various
things, and both are using a fairly basic multi-version timestamp ordering
(MVTO) algorithm. Oracle's buffer manager still relies on UNDO-based MVRC,
but they use MVTO (rowscn) in a few other areas.
In my experience, UNDO-based MVRC is much more preferable to MVTO from both
a performance and manageability standpoint. It's just that Oracle has quite
a few patents on optimized MVRC designs whereas MVTO is so blatantly obvious
that it's an easy choice to make from a legality standpoint. Though, I'd be
happy to see Ingres get MVRC.
Regardless, I just wanted to make sure you guys are aware of the striking
similarities in the design, especially having referenced Oracle's own
documentation in the DDS. The only other system I know of which performed a
similar UNDO-to-reach-a-CR-version-of-the-block (albeit a little different
than Oracle's traditional method) is InnoDB, which of course is now Oracle's
IP as well. I'm not sure whether Oracle's patent policy has changed, but I
believe they have 3-6 fairly detailed patents for their MVCC implementation.
--
Jonah H. Harris, Senior DBA
myYearbook.com
#3
| |||
| |||
|
|
On Mon, Oct 26, 2009 at 5:05 PM, Ingres Forums info-ingres (AT) kettleriverconsulting (DOT) com> wrote: The Design Specifications for MVCC Support in Ingres is available for review at 'MVCC - Ingres Community Wiki' (http://community.ingres.com/wiki/MVCC) It's nice to see such a fairly detailed specification. However, with very few exceptions, the architecture of this is almost identical to Oracle's MVCC design and implementation for acquiring a CR version of a block, which is heavily patented for not only a single-server software architecture, but also multi-server clustered architectures as well. For example, 4.1.9.1 lists CR buffers as being linked from the current version. While this is a seemingly obvious implementation for all chained hash table-based DB buffer management implementations, it is no different for Oracle. In Oracle, all versions of a buffer similarly hash to the same bucket, and all are chained to the current version. Likewise, the process listed in 4.1.9.4 is quite close to Oracle's implementation in that they determine whether a CR version needs to be created (by comparison of the SCN [similar to the comparison against crib_low_lsn]), and perform iterative UNDO on that block accordingly. While the high-level design is similar, in addition to the coarse-grained block-level UNDO, Oracle can also follow a single tuple back through multiple versions, which I don't see any conflict with here. Both Oracle and SQL Server now support Postgres-like tuple-based MVCC for various things, and both are using a fairly basic multi-version timestamp ordering (MVTO) algorithm. Oracle's buffer manager still relies on UNDO-based MVRC, but they use MVTO (rowscn) in a few other areas. In my experience, UNDO-based MVRC is much more preferable to MVTO from both a performance and manageability standpoint. It's just that Oracle has quite a few patents on optimized MVRC designs whereas MVTO is so blatantly obvious that it's an easy choice to make from a legality standpoint. Though, I'd be happy to see Ingres get MVRC. Regardless, I just wanted to make sure you guys are aware of the striking similarities in the design, especially having referenced Oracle's own documentation in the DDS. The only other system I know of which performed a similar UNDO-to-reach-a-CR-version-of-the-block (albeit a little different than Oracle's traditional method) is InnoDB, which of course is now Oracle's IP as well. I'm not sure whether Oracle's patent policy has changed, but I believe they have 3-6 fairly detailed patents for their MVCC implementation. |
and a newsgroup is a fine place to do it, but I doubt very many
people are going to take the time I just took to look up some of the
acronyms. Any chance you could post a more easily comprehended
version?
--
Roy
UK Ingres User Association Conference 2010 will be on Tuesday June 8 2010
Go to http://www.iua.org.uk/join to get on the mailing list.
#4
| |||
| |||
|
|
Jonah, this is interesting stuff that deserves to be widely discussed, and a newsgroup is a fine place to do it, but I doubt very many people are going to take the time I just took to look up some of the acronyms. Any chance you could post a more easily comprehended version? |
I may have time for that a bit later.
For reference:
- MVCC = Multi-version Concurrency Control (a concurrency method which is
based on versioning rather than locking)
- MVRC = Multi-version Read Consistency (an isolation level component of
MVCC)
- CR = Consistent Read (a version of the block applicable to an individual
transaction)
- MVTO = Multi-version Timestamp Ordering (an algorithm for versioning
tuples using timestamp-based transaction snapshots)
- UNDO-based MVRC = A method by which UNDO recovery data is used to convert
blocks from their current state to a state relevant to an individual
transaction.
If anyone is interested, Transactional Information Systems: Theory,
Algorithms, and the Practice of Concurrency Control and Recovery (
http://www.amazon.com/Transactional-.../dp/1558605088)
is a pretty good reference which describes several different algorithms for
performing MVCC.
--
Jonah H. Harris, Senior DBA
myYearbook.com
#5
| |||
| |||
|
#6
| |||
| |||
|
#7
| |||
| |||
|
#8
| |||
| |||
|
|
Would you know how EnterpriseDB protect themselves from Larry lawyers, because EnterpriseDB's Advanced Server Oracle compatibility is a blatant rip-off, If you ask me?! |
Sr. Software Architect working on Oracle Compatibility, I *can* tell you
exactly how they protect themselves: EnterpriseDB does not violate any
Oracle patents. Similarly, EnterpriseDB does not architect or develop
features based on Oracle documentation. Feature development is based only
on publicly available third-party sources, such as books, articles, etc. In
that respect, software specs are already one degree away from Oracle and is
along the lines of clean room design.
EnterpriseDB's PL/SQL Compatibility
EnterpriseDB implemented a PL/SQL-compatible programming language called SPL
(the Superset Procedural Language). Aside from the fact that PL/SQL is
basically just Ada, it's a programming language and as such, is not
patentable. Anyone write their own compiler for PL/SQL, just as there are
many compilers for BASIC, C, C++, Pascal, etc. Now, Oracle's PL/SQL user
guide, reference guide, etc. is copyrighted to Oracle, so EnterpriseDB has
to write their own SPL user documentation, but the language itself is
generally fair game.
EnterpriseDB's Data Access Compatibility
If you're familiar with Oracle, the main C/C++ data access interface used is
OCI (the Oracle Call Interface). If you look, EnterpriseDB has a product
called OCL, which they originally bought from me in order to allow some
applications written against the OCI API to work with EnterpriseDB. While
the API is *copyrighted* to Oracle, because it's used to access the
database, copying the function call signatures is allowed for
interoperability purposes (there's a long history of legal precedence for
that).
EnterpriseDB's Oracle-compatible Utilities
EDB*Plus is EnterpriseDB's version of SQL*Plus. EDB*Plus was written to be
compatible with SQL*Plus commands and report formatting. There's nothing
(in patent law) that says you can't have a program that looks like another
program or acts like another program to the end user.
The main problem is not in what the program *looks like*, it's in how it
works. For example, I architected a complete redesign of MVCC for Postgres
(on which EnterpriseDB is based) to avoid doing MVTO (due to the significant
overhead in both performance and manageability) and prefer a more
block-based read consistency approach. The problem I ran into was the
number of patents Oracle (and IBM) have on buffer management and recovery,
which made it difficult to come up with a scheme that didn't violate them in
some way.
Personally, I think software patents are stupid. Unfortunately, not
everyone shares my opinion :-(
--
Jonah H. Harris, Senior DBA
myYearbook.com
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.