<a href="http://www.hazelcast.com">[[https://db56fe3126-custmedia.vresp.com/36365bb450/hazelcast%20logo.jpg|width=300px|align=left|float]]</a>

"Hazelcast":http://www.hazelcast.com is a distributed in-memory data-grid that provides fast access to large amounts of data distributed across a cluster of machines. The Hazelcast storage backend for Titan is a low latency optimized alternative that excels at read-mostly workloads that uniformly access a graph. Note, that Hazelcast does not provide durable persistence. For production deployments, Hazelcast is operated as a data-grid where data is replicated to multiple machine for safety. Hazelcast runs in the same JVM as Titan.

Note, that the Hazelcast storage backend was first included in Titan 0.4.0 and is considered experimental for now.

bq. Hazelcast is the leading open source in-memory data grid it provides java developers an easy-to-use and powerful solution for data distribution that can be used as a clustering solution, a distributed cache and a NoSQL key-value store. -- "Hazelcast Homepage":http://www.hazelcast.com

h2. Hazelcast Setup

Since Hazelcast runs in the same JVM as Titan, connecting the two only requires a simple configuration and no additional setup:

```java
Configuration conf = new BaseConfiguration();
conf.setProperty("storage.directory", "/tmp/graph");
conf.setProperty("storage.backend", "hazelcastcache");
TitanGraph graph = TitanFactory.open(conf);
```

Currently, the Hazelcast storage backend adapter stores some properties in local files (i.e. not in the data-grid) and hence the necessity to provide a local directory. This will likely change in future releases.

h2. Hazelcast Specific Configuration

In addition to the general "Titan Graph Configuration":Graph-Configuration, there are the following Hazelcast specific Titan configuration options:

|_. Option |_. Description |_. Value |_. Default |_. Modifiable |
| storage.transactions | Enables transactions and detects conflicting database operations. *CAUTION:* While disabling transactions can lead to better performance it can cause to inconsistencies and even corrupt the database if multiple Titan instances interact with the same Hazelcast grid. | _true_ or _false_ | _true_ | yes |

Further configuration options can be set in the Hazelcast configuration XML file. Please see the Hazelcast documentation for more information.

h2. Ideal Use Case

The Hazelcast storage backend is best suited for read-mostly graph workloads on medium size graphs that can fit entirely into memory on one or multiple machines. _Read-mostly_ means that most of the transactions read data from the graph and very few updates occur. For write-heavy applications, other storage backends will yield much better performance.

Also, for this storage backend to be cost effective, most of the graph should be accessed regularly. If large parts of the graph go stale (e.g. old elements are rarely accessed) it might be more cost effective to use a disk-backed storage backend where stale data can reside on disk where it is rarely accessed.

For uniformly read graphs with few updates, the Hazelcast storage backend provides low latency query times that are hard to match by disk-backed storage backends.