Re: Lock-free databases
Date: 9 Nov 2005 06:58:01 -0800
Joe Seigh wrote:
> VC wrote:
> > "Joe Seigh" <jseigh_01_at_xemaps.com> wrote in message
> > news:r4mdnWBDc5K56ezenZ2dnUVZ_v6dnZ2d_at_comcast.com...
> >>VC wrote:
> >>>"Mark D Powell" <Mark.Powell_at_eds.com> wrote in message
> >>>"ANTs 3.2 is also the only lock-free relational database management
> >>>system architected for popular 64-bit Linux operating system
> >>>implementations running on AMD Opteron and Intel Xeon platforms. The ANTs
> >>>Data Server sets a new precedent in the database industry, allowing large
> >>>OLTP, real-time analytical processing and enterprise reporting to run
> >>>concurrently in the same server. "
> >>Saying you're lock free isn't the same as being lock-free.
> > You may have a point, or you may not. You just don't know whether their
> > lock-free implentation helps the performance. They claim it does:
> > "The second interesting thing about ADS is that ANTs claims that it
> > typically runs 5 to 15 times faster than standard relational databases. The
> > fact that it offers a lock-free environment is one reason for this" (
> > http://www.it-director.com/article.php?articleid=12912 )
> > So why not give them the benefit of the doubt ? Did you run tests that
> > would indicate their claims are false ?
> I'm not saying their claims are false. But I'm not the one engaging
> in market hyperbole. The burden of proof is on them. They haven't
> provided any facts significant to anyone familiar with lock-free
> programming techniques.
> Lock-free techniques similar to the ones covered by their patents have
> be used in operating system kernels for decades and those operating systems
> weren't going around proclaiming they were lock-free.
Since they "haven't provided any facts significant to anyone familiar with lock-free programming techniques", how can you claim that " Lock-free techniques similar to the ones covered by their patents have be used in operating system kernels for decades and those operating systems weren't going around proclaiming they were lock-free".
> In fact use of lock-free
> techniques like RCU for significant performance benefits doesn't qualify
> Linux as lock-free since it still has plenty of locks left over.
> >>their bottlenecks are IPC related, I don't see how their lock-free
> >>patented techniques would help performance.
> > There is some evidence (
> > http://www.cs.chalmers.se/~phs/TechnicalReports/SunT02_Noble.pdf ) that
> > operations on lock-free data structures outperform similar lock-based
> > implementations (without dragging IPC into the picture).
> Under certain conditions. It helps if you have contention. In non-contention
> cases, regular locks are as fast or faster than lock-free based solutions.
It may be true for RCU, but not true for other approaches to
implementing lock-free data structures (you can easily find plenty of
research results by googling for "performance" and "lock-free").
Clearly, in some cases lock-based synchronization will outperform
lock-free algorithms, no one claims otherwise.
Of course not. In fact, performance improvements with operations on lock-free structures is a recently new phenomenon. Implementating lock-free structures requires much more effort than the traditional locking approach. But the point is that, judging by many independent results, it's possible to achieve performance gain by using such structures. Taking into account those results, the ANTS claims that lock-free data structures improve performace have more credibility that your wholesale denial of their claims.
> The reason I posted the OP was to find out if certain types of databases had
> enough contention to make it feasible to look into lock-free solutions. But
> that is more of a database internals question and most of the discussion here
> seems more focused on database externals.
Well, issues are pretty similar, whether one talk about synchronizing access to rows or internal memory structures.
> Joe Seigh
> When you get lemons, you make lemonade.
> When you get hardware, you make software.
Received on Wed Nov 09 2005 - 15:58:01 CET