Comments on: No locks, no logs — no problem? http://www.dbms2.com/2006/09/20/no-locks-no-logs-no-problem/ Choices in data management and analysis Thu, 09 Feb 2012 09:22:14 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: DBMS2 — DataBase Management System Services»Blog Archive » Logless, lockless Netezza more carefully explained http://www.dbms2.com/2006/09/20/no-locks-no-logs-no-problem/#comment-7977 DBMS2 — DataBase Management System Services»Blog Archive » Logless, lockless Netezza more carefully explained Wed, 27 Sep 2006 22:47:14 +0000 http://www.dbms2.com/2006/09/20/no-locks-no-logs-no-problem/#comment-7977 [...] I talked at length with Bill Blake and Doug Johnson of Netezza today. (Bill is exactly the guy I complained of previously having had my access cut off to.) One takeaway was a clarification of their approach to transactions, which sounds even cooler than I first thought. It’s actually not a new idea; they just timestamp rows with CreateIDs and DeleteIDs, then exploit those to the hilt. Actually, it seems like this approach would be interesting in OTLP as well, although I’m not aware of it being used in any of the more successful OLTP DBMS systems. (Yes, this is an open invitation to fans of less-established DBMS products to tell me of their virtues, preferably in a flame-free manner.) [...] [...] I talked at length with Bill Blake and Doug Johnson of Netezza today. (Bill is exactly the guy I complained of previously having had my access cut off to.) One takeaway was a clarification of their approach to transactions, which sounds even cooler than I first thought. It’s actually not a new idea; they just timestamp rows with CreateIDs and DeleteIDs, then exploit those to the hilt. Actually, it seems like this approach would be interesting in OTLP as well, although I’m not aware of it being used in any of the more successful OLTP DBMS systems. (Yes, this is an open invitation to fans of less-established DBMS products to tell me of their virtues, preferably in a flame-free manner.) [...]

]]> By: Stuart Frost http://www.dbms2.com/2006/09/20/no-locks-no-logs-no-problem/#comment-6774 Stuart Frost Thu, 21 Sep 2006 04:12:32 +0000 http://www.dbms2.com/2006/09/20/no-locks-no-logs-no-problem/#comment-6774 Must admit, this is news to me. While avoiding locks and logs has performance benefits in some cases, it sounds like a pretty risky proposition if its your only choice and also rules out a lot of real-world insert/update scenarios. I don't really understand why failover is an alternative to roll-backs. Rolling back an insert/update isn't only done as the result of an internal system failure. If the process outside the database fails or the input data is bad, both of the failover partitions will have identical, bad contents. We offer the best of both worlds - bulk loads with no logging when you need raw performance and full transaction-safe inserts and updates when you need reliability. We haven't yet come across a customer project where we couldn't meet their requirements in terms of insert/update processing and load performance. This includes some very complex near-real-time systems with hundreds of millions of rows per day being 'upserted' (to borrow a Teradata phrase). Stuart DATAllegro Must admit, this is news to me. While avoiding locks and logs has performance benefits in some cases, it sounds like a pretty risky proposition if its your only choice and also rules out a lot of real-world insert/update scenarios.

I don’t really understand why failover is an alternative to roll-backs. Rolling back an insert/update isn’t only done as the result of an internal system failure. If the process outside the database fails or the input data is bad, both of the failover partitions will have identical, bad contents.

We offer the best of both worlds – bulk loads with no logging when you need raw performance and full transaction-safe inserts and updates when you need reliability. We haven’t yet come across a customer project where we couldn’t meet their requirements in terms of insert/update processing and load performance. This includes some very complex near-real-time systems with hundreds of millions of rows per day being ‘upserted’ (to borrow a Teradata phrase).

Stuart
DATAllegro

]]>