{"id":2094,"date":"2013-04-08T09:29:12","date_gmt":"2013-04-08T13:29:12","guid":{"rendered":"http:\/\/hstore.cs.brown.edu\/?p=2094"},"modified":"2013-04-08T10:18:49","modified_gmt":"2013-04-08T14:18:49","slug":"new-release-april-2013","status":"publish","type":"post","link":"https:\/\/hstore.cs.brown.edu\/2013\/04\/new-release-april-2013\/","title":{"rendered":"New Release (April 2013)"},"content":{"rendered":"

\"H-Store<\/a><\/p>\n

Like sands through the hourglass, so are the days of our lives. And with that, the H-Store project is pleased to announce the release of the latest version of its high-performance, distributed transaction processing database management system. This version contains a significant new advancement in main memory NewSQL<\/a> systems called anti-caching<\/strong>. H-Store now includes a disk-resident, block storage anti-cache to store “cold” data that has been removed from the memory-resident storage in order to free up space for new data. Preliminary experiments show that H-Store with anti-caching outperforms traditional DBMSs even for databases that are larger than the amount of memory available on a single node.<\/p>\n

If the amount of memory used in the partitions for an HStoreSite<\/a> goes above an administrator-defined threshold<\/a>, then H-Store will evict the least recently used tuples and write them out to the anti-cache storage disk. H-Store still maintains index information in memory for any evicted tuples stored on disk. If a transaction attempts to access one of these evicted tuples, then it is switched into a “pre-pass” mode where the engine records all tuples that it tried to access. Once that transaction attempts to do something with those tuples (e.g., modify them, return them to the stored procedure), then it is aborted and put in a queue while the AntiCacheManager<\/a> thread asynchronously retrieves those records and merge them back into memory.<\/p>\n

Additional information about the new anti-caching architecture in H-Store is available on-line:<\/p>\n