Forum: Other

Post: Related DBMS

Related DBMS
henning
Apr 26, 2010
I found this list of databases at http://www.planetids.com/content/third-generation-database-technology-part-ii
I would be interested to learn about the differences they have, respectively, to VoltDB.


  • Oracle TimesTen
  • Sybase ASE 15.5 IMDB
  • ENEA’s Polyhedra
  • GeneroDB from Four Js
  • Xcelerix IMDB from Frontex
  • IBM’s SolidDB
  • eXtremeDB from McObject
re: Related DBMS
tcallaghan
Apr 28, 2010
Henning,

While I don't have enough experience with any of the RDBMS you listed, I can detail what makes VoltDB "different" than most. Particularly, VoltDB was purpose built to overcome the overhead of traditional RDBMS implementations, particularly: buffer management, logging, latching and locking.



  • Buffer Management - VoltDB is an in-memory database and does not have to manage IO to/from the filesystem.
  • Logging - VoltDB provides High Availability (HA) through k-safety within the cluster, it does not log to the filesystem.
  • Latching and Locking - In VoltDB stored procedures execute single-threaded to completion, there is no concurrent access to data.

The list you provided is primarily in-memory so they do not suffer from buffer management, I'm not sure of their implementation of logging, latching, and locking.

Also, VoltDB is built to scale as a cluster. I'd be interested to know which in your list are limited to a single server and which are not.

If anyone has information regarding Henning's list of databases (or others), please add to this post.

-Tim
Architecture comparation
aris_sety
May 16, 2010
Henning,

While I don't have enough experience with any of the RDBMS you listed, I can detail what makes VoltDB "different" than most. Particularly, VoltDB was purpose built to overcome the overhead of traditional RDBMS implementations, particularly: buffer management, logging, latching and locking.

Henning,
I have collect some of your list and I have another list, but maybe I'm incorrect and misinterpret their documentation. Another main memory DBMS beside VoltDB, they are all kept data in memory, but mostly still suffered from locking and latcing and mostly they log data to disk for durability for INSERT and UPDATE operation. Some of them can be configured with logging relaxed or logging off with combination with replication, but they didn't explicitly said ACID. Some of them lack in documentation or support.
Oracle TimesTen


  • Buffer Management - All data kept in memory
  • Logging - Durability is achieved through combination of transaction logging and database check pointing disk. Although they support clustering, it was not explained if we can configure logging relaxed, and so can achieved durability via synchronous replication and without logging
  • Latching and Locking - Multi-thread using row-level locking and committed-read isolation

Sybase ASE 15.5 IMDB: all data kept in memory but they not durable so they are not ACID, at first I doubt about it but it was clearly explained in the datasheet. Although they support clustering, it was not explained if we can configure logging relaxed, and so can achieved durability via synchronous replication and without logging . Another alternative they provide fully cache old RDBMS without logging so it still suffered from locking.
cSQL MMDB


  • Buffer Management - All data kept in memory
  • Logging - In single server, it uses checkpoint & redo log. But, it can be configured as a cluster with Logging relaxed.
  • Latching and Locking - Row Level Locking, lock free index structures
  • Server - Provides standard active – standby data replication for fail over mechanism as well as update anywhere clusters with synchronous and asynchronous update propagation between CSQL nodes in the cluster for load balancing database access

Blackray


  • Buffer Management - All data kept in memory
  • Logging - Implement database level locking to log data to disk in INSERT or UPDATE operation
  • Latching and Locking - Database Level Locking
  • Server - Support multiple node replication

FastDB


  • Buffer Management - All data kept in memory
  • Logging - Implement database level locking to log data to disk in INSERT or UPDATE operation
  • Latching and Locking - they manage locking
  • Server - Support fail over mechanism. Only support embedded, didn't support client server configuration.

HSQLDB/HXSQLDB


  • Buffer Management - In-memory tables for fastest operation, disk based tables for large data sets.
  • Logging - If In-memory tables used, in INSERT operation, HSQLDB employs a redo log for data recovery.
  • Latching and Locking - HSQLDB 2.0 is fully multithreaded. Three transaction control models, including lock based and MVCC models
  • Server - Single server

Another list are Datablitz, RaimaDB, and Altibase.
re: comparisons
tcallaghan
May 17, 2010
Henning,
I have collect some of your list and I have another list, but maybe I'm incorrect and misinterpret their documentation. Another main memory DBMS beside VoltDB, they are all kept data in memory, but mostly still suffered from locking and latcing and mostly they log data to disk for durability for INSERT and UPDATE operation. Some of them can be configured with logging relaxed or logging off with combination with replication, but they didn't explicitly said ACID. Some of them lack in documentation or support.
Oracle TimesTen..


Aris,

Thanks for compiling this list and sharing your findings.

-Tim
Re: Other databases
TodoInTX
May 25, 2010
Conspicuously missing from the list I think is MySQL Cluster (NDB).

* Buffer Management - All data kept in memory, with the option to store non-indexes columns on disk.
* Logging - All operations which modify data are written to a REDO log on disk, with periodic syncing of all data to disk avoiding data loss during node or full cluster restarts.
* Latching and Locking - Multi-thread using row-level locking, committed-read isolation and non-locking reads.
* Server - Automatic or manual partitioning with online add-node, replication and recovery of data between nodes with optional asynchronous replication between multiple clusters.
re: MySQL Cluster (NDB)
tcallaghan
May 26, 2010
Conspicuously missing from the list I think is MySQL Cluster (NDB)....


Thanks for adding this, if you have additional experience with any others please add them as well.

-Tim
NoSQL Products
henning
May 31, 2010
Here are additional products, the NoSQL phalanx, from two lists I ran across:

NoSQL meetup, report: http://www.zemanta.com/fruitblog/nosql-meetup-reporton/
Highly Scalable Datastores: http://spreadsheets.google.com/ccc?key=0Ale_YaCwKEUVclVFVFlrUWt5aWhQaGQ0OXVCMUl4Vmc&hl=en



  • key‐value‐cache – memcached, repcached, coherence, infinispan, eXtreme scale, jboss cache, velocity, terracoqa
  • key‐value‐store – keyspace, flare, schema‐free, RAMCloud
  • eventually‐consistent key‐value‐store – dynamo, voldemort, Dynomite, SubRecord, Mo8onDb, Dovetaildb
  • ordered‐key‐value‐store – tokyo tyrant, lightcloud, NMDB, luxio, memcachedb, actord
  • data‐structures server – redis
  • tuple‐store – gigaspaces, coord, apache river
  • object database – ZopeDB, db4o, Shoal
  • document store – CouchDB, Mongo, Jackrabbit, XMLDatabases, ThruDB, CloudKit, Perservere, Riak Basho, Scalaris
  • wide columnar store – BigTable, Hbase, Cassandra, Hypertable, KAI, OpenNeptune, Qbase, KDI



  • ...
  • GlusterFS
  • MogileFS