Fork me on GitHub

H-Store is an experimental main-memory, parallel database management system that is optimized for on-line transaction processing (OLTP) applications. It is a highly distributed, row-store-based relational database that runs on a cluster on shared-nothing, main memory executor nodes.

The H-Store project is a collaboration between MIT, Brown University, Carnegie Mellon University, Yale University, and Intel.

Final Release (June 2016)

June 3rd, 2016 at 1:21 pm

The H-Store project is pleased to announce the release of the final version of its transaction processing database management system. This version is forever known as the “We All Got Jobs” release to celebrate the fact that the core students that were working on the H-Store project have graduated from their respective universities and moved on to full-time employment. We thought about calling this the “Turing Award” release, but that seemed a bit garish. Plus Mike didn’t have to spend hours trying to figure out JVM garbage collection problems like we all did.

The final version means that there is unlikely to be any more major development in the system. There may be some bug fixes H-Store in the years that follow, but you should not expect any new features or projects. There will probably be one or two more H-Store papers published this year as well. If you want to use a more state-of-the-art DBMS that is based on H-Store’s architecture, then you should use VoltDB. Yes, VoltDB is open-source. Stop asking. There is also the S-Store project that is adding support for in-memory stream processing on top of the H-Store architecture.

So this is the end. All of the project’s papers, presentations, and posters are available on the publications page. We would like to thank the many students, collaborators, and friends that have helped us over the last eight years.

Some of us are also now building the next system

Major highlights of this release:

  1. Improved the anti-caching architecture in the system to be smarter about moving in and out of secondary storage. This includes the use of a CountMin Sketch to selectively merge a cold data block back into memory if the data is accessed a lot in a window. There is also support for multi-tier anti-caching to allow you to define a hierarchical storage layout for spilling tuples from DRAM to durable storage. [8d19ab1] [b654e8b] [063e024] [4fb3757] [ee2301b] [d87cefe]
  2. Added support for tuple-level eviction and retrieval when using non-volatile memory (NVM). Instead of using tombstones, evicted tuples are moved to a separate pool that is stored on NVM. All of the operator executors can then access these tuples directly without needing abort and restart the txn. [ab56f88] [37b3638] [074da8d]
  3. The default index data structure for H-Store is the stx::btree. This improves throughput for single-partition workloads by about 10% while also reducing memory consumption. [87465c6]
  4. Added support for the new compressed OLTP hybrid indexes. See our SIGMOD’16 paper for more information. [3c10031]
  5. Added new AntiCacheStatsSource to retrieve additional information about the evicted tuple storage. [e1bca3b]
  6. FIX: Removed a race condition involving the EE’s shared buffer and the AntiCacheEvictionManager. This problem occured when the anti-caching subsystem evicts tuples and a transactions accesses an EvictedTuple. The EE would then lose the information about the tuple accessed. [90efa79]
  7. FIX: Long-existing memory leak in the EE’s undo log. This was embarrassing. [f77f8d0]
  8. FIX: The EE’s IndexStats now store memory information correctly for tables with multiple indexes. [78aff6f] [29527be]
  9. FIX: The EE’s AntiCacheManager was using inaccurate stats when deciding how much data to evict, which would then cause it to write out empty blocks of data. [17fe61d]

This release can be downloaded via Github: