September 20, 2006
No locks, no logs — no problem?
There’s another cool-sounding part to the Netezza story, which straddles their chips and their software: The FPGA takes over the work of assuring database consistency. If the system attempts to read and write a record at the same time, the FPGA keeps thing straight. This eliminates the need for locks — at least if you don’t care about transactional integrity — and some of the reason for logs. (I guess that in lieu of any kind of rollback/rollforward they just rely on failover to mirrored disks.)
This isn’t exactly the way one would want to do OLTP, and in general my head is shaking as I write this — but it sure seems to suffice for some rather demanding data warehouse users.
Categories: Data warehouse appliances, Netezza, Theory and architecture
Subscribe to our complete feed!
Comments
2 Responses to “No locks, no logs — no problem?”
Leave a Reply
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
[…] 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.) […]