Comments on: H-Store is now VoltDB http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/ Choices in data management and analysis Thu, 09 Feb 2012 09:22:14 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Clustrix may be doing something interesting | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-169379 Clustrix may be doing something interesting | DBMS2 -- DataBase Management System Services Thu, 20 May 2010 23:36:40 +0000 http://www.dbms2.com/?p=818#comment-169379 [...] Akiban or VoltDB, Clustrix makes database appliances. The Clustrix software seems to assume a Clustrix [...] [...] Akiban or VoltDB, Clustrix makes database appliances. The Clustrix software seems to assume a Clustrix [...]

]]> By: Notes on the evolution of OLTP database management systems | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-164713 Notes on the evolution of OLTP database management systems | DBMS2 -- DataBase Management System Services Tue, 06 Apr 2010 04:20:55 +0000 http://www.dbms2.com/?p=818#comment-164713 [...] VoltDB is the main exception that jumps to mind. [...] [...] VoltDB is the main exception that jumps to mind. [...]

]]> By: NoSQL? | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-152422 NoSQL? | DBMS2 -- DataBase Management System Services Sat, 12 Dec 2009 04:20:29 +0000 http://www.dbms2.com/?p=818#comment-152422 [...] often-unspecified — “overhead” are interesting to view through the lens of the H-Store/VoltDB project. Mike Stonebraker et [...] [...] often-unspecified — “overhead” are interesting to view through the lens of the H-Store/VoltDB project. Mike Stonebraker et [...]

]]> By: Jags Ramnarayan http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-137369 Jags Ramnarayan Sun, 30 Aug 2009 23:10:45 +0000 http://www.dbms2.com/?p=818#comment-137369 Scale out OLTP products has been around for a while as "object" data management products, extensively used in trading environments (where VoltDB is positioned) offering memory only storage, variety of replication, partitioning strategies and varying levels of concurrency control, all designed to tackle the high scale and reliability problem for OLTP data. GemStone recently announced a SQL centric horizontally partitioned memory oriented product called GemFire SQLFabric (http://community.gemstone.com/display/sqlfabric/SQLFabric). Scale out OLTP products has been around for a while as “object” data management products, extensively used in trading environments (where VoltDB is positioned) offering memory only storage, variety of replication, partitioning strategies and varying levels of concurrency control, all designed to tackle the high scale and reliability problem for OLTP data. GemStone recently announced a SQL centric horizontally partitioned memory oriented product called GemFire SQLFabric (http://community.gemstone.com/display/sqlfabric/SQLFabric).

]]> By: What are the best choices for scaling Postgres? | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-133102 What are the best choices for scaling Postgres? | DBMS2 -- DataBase Management System Services Wed, 29 Jul 2009 06:16:05 +0000 http://www.dbms2.com/?p=818#comment-133102 [...] option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch.  But this client’s database is terabyte-scale, so hardware costs [...] [...] option for OLTP performance and scale-out is of course memory-centric options such as VoltDB or the Groovy SQL Switch.  But this client’s database is terabyte-scale, so hardware costs [...]

]]> By: The Groovy SQL Switch | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-133083 The Groovy SQL Switch | DBMS2 -- DataBase Management System Services Wed, 29 Jul 2009 01:58:10 +0000 http://www.dbms2.com/?p=818#comment-133083 [...] One obvious concern about Groovy’s approach is RAM cost. If you’re interested in the Groovy SQL Switch, you probably have a large transaction volume, in which case you probably also have a fast-growing database. Absent some kind of manual partitioning, the Groovy SQL Switch currently requires you to have enough RAM to hold that in its entirety. The same comment, of course, is probably true about VoltDB. [...] [...] One obvious concern about Groovy’s approach is RAM cost. If you’re interested in the Groovy SQL Switch, you probably have a large transaction volume, in which case you probably also have a fast-growing database. Absent some kind of manual partitioning, the Groovy SQL Switch currently requires you to have enough RAM to hold that in its entirety. The same comment, of course, is probably true about VoltDB. [...]

]]> By: Hasso Plattner calls for in-memory OLTP column stores | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-129595 Hasso Plattner calls for in-memory OLTP column stores | DBMS2 -- DataBase Management System Services Wed, 08 Jul 2009 16:47:59 +0000 http://www.dbms2.com/?p=818#comment-129595 [...] technology. There also are strong similarities to the MPP in-memory row store project H-Store/VoltDB, although I don’t know whether Plattner would go so far as to adopt the H-Store view that all [...] [...] technology. There also are strong similarities to the MPP in-memory row store project H-Store/VoltDB, although I don’t know whether Plattner would go so far as to adopt the H-Store view that all [...]

]]> By: Daniel Weinreb http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-127888 Daniel Weinreb Mon, 29 Jun 2009 04:31:09 +0000 http://www.dbms2.com/?p=818#comment-127888 During discussions I had with VoltDB (as it is now called) engineers, I suggested how useful it would be to have a way to migrate OLTP data gradually out of VoltDB and into Vertica, as particular items of data cease to change and become archival in nature. I suggested this to them and it turns out that they had been thinking along those lines already. None of this means anything about future product plans or anything, just that they do know about that idea. During discussions I had with VoltDB (as it is now called) engineers, I suggested how useful it would be to have a way to migrate OLTP data gradually out of VoltDB and into Vertica, as particular items of data cease to change and become archival in nature. I suggested this to them and it turns out that they had been thinking along those lines already. None of this means anything about future product plans or anything, just that they do know about that idea.

]]> By: Curt Monash http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-127270 Curt Monash Fri, 26 Jun 2009 18:39:09 +0000 http://www.dbms2.com/?p=818#comment-127270 Coincidentally, Vertica just gave me a heads-up on something specific Stonebraker plans to do for them. Details are confidential, but I figure it's OK to mention the general point ... ;) Coincidentally, Vertica just gave me a heads-up on something specific Stonebraker plans to do for them. Details are confidential, but I figure it’s OK to mention the general point … ;)

]]> By: Jay Allen http://www.dbms2.com/2009/06/22/h-store-horizontica-voltdb/#comment-127033 Jay Allen Thu, 25 Jun 2009 17:56:27 +0000 http://www.dbms2.com/?p=818#comment-127033 In response to the first comment, I think the evidence is quite to the contrary. Mike Stonebraker has suggested very strongly that "one size does not fit all" for database management systems anymore. Vertica, Streambase and H-Store (now VoltDB) attack different problems. Vertica isn't an OLTP database and VoltDB isn't for data warehousing. For me, the interesting problem to solve will be how to get data from an OLTP database (say, VoltDB) into a data warehouse database (say, Vertica) to address both the operational and "informational" requirements of most businesses today. Never underestimate Mike Stonebraker's insights. With Ted Codd and Jim Gray gone, Dr. Stonebraker (along with the remaining original System R researchers) is one of the world's foremost experts on database technology. In response to the first comment, I think the evidence is quite to the contrary. Mike Stonebraker has suggested very strongly that “one size does not fit all” for database management systems anymore. Vertica, Streambase and H-Store (now VoltDB) attack different problems. Vertica isn’t an OLTP database and VoltDB isn’t for data warehousing. For me, the interesting problem to solve will be how to get data from an OLTP database (say, VoltDB) into a data warehouse database (say, Vertica) to address both the operational and “informational” requirements of most businesses today.

Never underestimate Mike Stonebraker’s insights. With Ted Codd and Jim Gray gone, Dr. Stonebraker (along with the remaining original System R researchers) is one of the world’s foremost experts on database technology.

]]>