When to use Sirius

==== To help evaluate the Sirius library for use in your application, we have compiled a list of considerations that should help in your evaluation. While Sirius could hold all of the application's data, it does not have to. If your data can be separated into multiple segments with varied access methods and patterns, it may be helpful to answer these questions multiple times, once for each segment of your application's data.

==== ####Reference Data Set Sirius is designed to work well with reference data sets.

A reference dataset is a set of data where the collective size of the data is relatively small, has a high read/write ratio, and can be updated asynchronously. While small is a relative term, the reference dataset should be contained in the memory of a reasonably equipped server. Typically this means that the data should take no more than a few tens of GB in memory. The data should be updated far less frequently than they are read. Also latency in the updates to the data should not be visible to the vast majority of the users. The users will get the updates but in general will not be sensitive to the time it takes from the moment the update was made and the moment when the update is available to them.

If you can answer yes to several of the following questions your application may utilize a reference data set, and Sirius would be a good fit for your application: (Answering no to one or more of these questions may indicate that Sirius is not a good fit)

• Will your application use a set of data that is read from very frequently?
• Will your application use a set of data that is written to infrequently?
• Will your application use a set of data that is relatively small (not Big Data)?
• Will your application use a set of data that has elements that remain stable for periods of time?
• Will your application use a set of data that end users interact with as a read-only set of data?

==== ####Operational Model

If you can answer yes to the following questions the Sirius operational model may be a good fit for your application: (Answering no to one or more of these questions may indicate that Sirius is not a good fit)

• Will your application utilize a distributed data store?
• Will your application require key-value storage?
• Will your application run inside a JVM?
• Will your application need a simple interface to the datastore?
• Will your application tolerate eventual consistency of the datastore?
• Will your application require data structures outside of hash tables, sets and lists?

==== ####Additional Considerations If you can answer yes to the following questions Sirius may be a better fit for your application vs. similar libraries: (Each yes answer indicates and even better fit, while a no answer may not indicate anything in particular)

• Will your application have multiple types of data that need to be stored?
• Will your application have nodes that may be unavailable for short periods of time?
• Will your application benefit from having all the data replicated to all the nodes of the cluster?

====

We are not aware of a good test that will tell you which library is the best for your application in a quick, easy and infallible way. The questions above are meant to be just guidelines. Especially the third set of questions, as they may not be relevant to your application. For example, you are evaluating Sirius for an application that deals with large amounts of homogeneous data (i.e. all the data is the same type of data). Because Sirius can support different types of data, as long as it can be represented as an array of bytes, answering no to that question should not be considered a negative for evaluating Sirius. Sirius just provides flexibility and functionality you will not be using in your application. Some of the considerations, on the other hand, are definite indicators that Sirius is not a good fit for the application. For example, the inability for your application to tolerate any stale reads, would be a large contra-indication that Sirius is the right tool for your application.