Yes MVCC is implemented by many database management systems, typically this is a tweak of isolation levels to determine to what extent to read uncommitted data. We have a complete description of the multiple techniques and styles of this in our book.
What BASE seems to be aimed at is an alternative to 2PC for ensuring consistency of updates across replicated data sets, especially in memory. Eric On Thu, Jul 23, 2009 at 5:58 AM, Reinier Zwitserloot <reini...@gmail.com>wrote: > > Am I missing something? > > Postgresql, MS SQL Server, H2, MySQL/InnoDB, Oracle, and even CouchDB > - *ALL* use MVCC to implement transactions. > > That's easily over 90% of all transactional db usage in the world. > > http://en.wikipedia.org/wiki/Multiversion_concurrency_control > > > On Jul 23, 8:39 am, kirk <kirk.pepperd...@gmail.com> wrote: > > Alex Turner wrote: > > > Guess you've never heard of MVCC? > > > > I have. but putting it into practice is a wee bit difficult. You > > typically end up with a big "point in time" abstraction mess. > > > > Regards, > > Kirk > > > > > > > > > On Mon, Jul 20, 2009 at 1:05 AM, kirk<kirk.pepperd...@gmail.com> > wrote: > > > > >> Hi Steven, > > > > >> Just got back from vacation and this thread jumped out at me and maybe > I > > >> jumped in a bit early. Now that I've read more of the discussion.... > > > > >> I'm not a historian also but my experience with hierarchical is that > > >> they were limiting in what you could model with them. This wasn't a > > >> problem with network dbs. The problems you've pointed out with > > >> hierarchical I've not found with network db. But then my experiences > > >> with them are limited and fairly old. I'll focus on the tooling thing > > >> 'cos I think that it's the most important mention in your response. > > > > >> I worked with OO databases for a number of years, first as a user and > > >> then as an employee of GemStone. When I first ran into them the > project > > >> rejected them because of the schema migration problem (object > > >> versioning). It appears that RDBMS gives you a huge win with schema > > >> migration even though it suffers from the same problem. One of the big > > >> differences is, the data model has been abstracted away from the code > > >> (anti-OO). This allows DBA's to be draconian in allowing changes to > the > > >> db schema without affecting app developers too seriously most of the > > >> time. Investment in RDB tooling is such that schema migrations are > less > > >> painful. OODB didn't have the time to get these tools into the market > > >> place and they seriously needed them as restricting schema in OO is a > > >> serious restriction to place on the developers. Obviously Hierarchical > > >> and Network technologies suffered from the same lack of funding as > > >> investment in relational sucked up all the capital. > > > > >> The other comment that struck a cord was one in the initial email > > >> suggesting that in order to make a DB scale one had to front it with a > > >> big cache. This was suggested to be an indication of a problem. I'm > not > > >> sure that I agree that it's an indication of a problem to the point > > >> where we need to throw the baby out with the bath water. After all, > > >> caching is used every where you'd like to short-circuit a call path. > > >> Think CPU cache short-circuiting a call to memory. What it does > suggest > > >> is that we need to seriously think about how we are using the > technology > > >> and recognizing that the A in ACID equates to a big fat lock that > using > > >> current practices results in *every* thread in your system.. in your > > >> cluster... in your server farm pass through it. If we want to increase > > >> concurrency in our systems, adding a big fat lock that every thread > must > > >> pass through doesn't seem like a wise thing to do. However, just as > RAM > > >> is still useful, so it relational persistence technology. We just need > > >> to learn how to use it to build the types of systems we are building > > >> today, not the ones that we built yesterday. > > > > >> Regards, > > >> Kirk > > > > >> Steven Herod wrote: > > > > >>> I'm not a historian, and I acknowledge that a better theory can be > > >>> ruined by a crappy implementation but what I've noticed over the > past > > >>> 2.5 years hanging around a mainframe hierarchical db is that it takes > > >>> a COBOL programmer and hours, weeks or months for questions/changes > > >>> like the ones below to be dealt with: > > > > >>> 1. Can I get the structure of the database? > > >>> 2. Can I get a copy of the data in this table? > > >>> 3. Can we increase the size of this column by 5 chars? > > >>> 4. Can we increase the number of addresses we can store? > > >>> 5. Can we find out what the distinct values of this col are in this > > >>> table? > > >>> 6. Can you tell me how many customers we have which own <this > > >>> product>? > > > > >>> Obviously each of these things can be done in seconds in SQL and with > > >>> freely available inexpensive tooling. > > > > >>> We also have issues with data quality. Lack of constraints and > > >>> foreign keys... it catches up with you after 20 years of data > > >>> collection :). > > > > >>> I'm in the process of reading the Amazon Dynamo paper, very > > >>> interesting, but it strikes me again that its a very, very specific > > >>> type of problem, something that isn't appropriate for a vast number > of > > >>> businesses who process data. (Just as a RDBMS isn't appropriate for > > >>> Amazon). > > > > >>> On Jul 20, 7:10 am, kirk <kirk.pepperd...@gmail.com> wrote: > > > > >>>> Steven Herod wrote: > > > > >>>>> I think you might be overlooking how revolutionary SQL/Relational > > >>>>> storage is compared to what came before it. > > > > >>>> like hierarchical and network databases? > > > > >>>> Seriously, of the 3 types of databases.. network was by far the best > but > > >>>> least understood by decision makers so we're stuck with Relational. > > > > >>>> Regards, > > >>>> Kirk > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
