Comments on: Logless, lockless Netezza more carefully explained http://www.dbms2.com/2006/09/27/logless-lockless-netezza-more-carefully-explained/ Choices in data management and analysis Fri, 08 Aug 2008 00:30:18 +0000 http://wordpress.org/?v=2.5.1 By: DBMS2 — DataBase Management System Services»Blog Archive » Are row-oriented RDBMS obsolete? http://www.dbms2.com/2006/09/27/logless-lockless-netezza-more-carefully-explained/#comment-16346 DBMS2 — DataBase Management System Services»Blog Archive » Are row-oriented RDBMS obsolete? Mon, 22 Jan 2007 11:23:53 +0000 http://www.dbms2.com/2006/09/27/logless-lockless-netezza-more-carefully-explained/#comment-16346 [...] Timestamps are used for inserts and deletes; otherwise, there are no data changes. (Without that kind of approach, the update strategy in Point #2 couldn’t be viable.) A big benefit to these timestamps is that you can assure integrity via “snapshot isolation”; i.e., by a virtual rollback to a recent point in time. Thus, Vertica can get away without any kind of locks or, for that matter, transaction/redo logs. Row-oriented Netezza uses a similar logless, lockless approach. [...] [...] Timestamps are used for inserts and deletes; otherwise, there are no data changes. (Without that kind of approach, the update strategy in Point #2 couldn’t be viable.) A big benefit to these timestamps is that you can assure integrity via “snapshot isolation”; i.e., by a virtual rollback to a recent point in time. Thus, Vertica can get away without any kind of locks or, for that matter, transaction/redo logs. Row-oriented Netezza uses a similar logless, lockless approach. [...]

]]> By: Stuart Frost http://www.dbms2.com/2006/09/27/logless-lockless-netezza-more-carefully-explained/#comment-12632 Stuart Frost Sat, 21 Oct 2006 18:51:05 +0000 http://www.dbms2.com/2006/09/27/logless-lockless-netezza-more-carefully-explained/#comment-12632 Curt, If I understand this right, there's no real way to have multiple 'transactions' at the same time, which would seem to be a significant limitation if multiple users want to do updates etc. at the same time (which is remarkably common, even in DW systems). Also, does this mean that an updated row effectively changes position on the disk? If so, how does this affect Netezza's zone maps? Zone maps only work well in systems that load data in strict date order (thereby providing a kind of date partitioning). If the row order is changed later, the performance benefits of zone maps will degrade over time. Stuart DATAllegro Curt,

If I understand this right, there’s no real way to have multiple ‘transactions’ at the same time, which would seem to be a significant limitation if multiple users want to do updates etc. at the same time (which is remarkably common, even in DW systems).

Also, does this mean that an updated row effectively changes position on the disk? If so, how does this affect Netezza’s zone maps? Zone maps only work well in systems that load data in strict date order (thereby providing a kind of date partitioning). If the row order is changed later, the performance benefits of zone maps will degrade over time.

Stuart
DATAllegro

]]>