Skip to main content

Implementing @ApacheIgnite's cache store (part II)

Apache Ignite’s CacheStore interface is an API for cache persistence storage for read-through and write-through behavior.  When implementing this interface, you choose the type of key and value object alike -- similar to a map.  This follows the pattern established by the CacheLoader and CacheWriter interfaces CacheStore extends of the JSR107 specification.  In many cases, having a specific implementation for each method when implementing this interface may not be necessary, so Apache Ignite has a CacheStoreAdapter for this purpose.

Since Caches so closely resemble Maps, perhaps we should begin our discussion with a cache implementation that is essentially a HashMap store:

public class HashMapStore extends CloudStoreAdapter {

private final Map<Object, Object> map = new HashMap<>();

@Override public void loadCache(IgniteBiInClosure c, Object … args) {

for(Map.Entry e : map.entrySet()) {
c.apply(e.getKey(), e.getValues());
}

@Override public Object load(Object key) {
Return map.get(key);
}

@Override public void write(Cache.Entry e) {
map.put(e.getKey(), e.getValue());
}

@Override public void delete(Object key) {
map.remove(key);
}

To use an Ignite cache, a configuration must be provided.  This can be done several ways -- including declaratively using a Spring XML configuration or programmatically using Ignite’s native CacheConfiguration object.

    Ignite’s CacheConfiguration class extends the MutableConfiguration class of the JSR107 specification.  When configuring an Ignite cache, out of the dozens of settings to choose from there are some settings that are at least as important as setting the name of the cache.  One of these settings is the write synchronization mode.  Each mode setting indicates how ignite should wait for write replies from other nodes.  The three possible settings as provided by the CacheWriteSynchronizationMode enum are FULL_SYNC, FULL_ASYNC, and PRIMARY_SYNC.  The standard setting is FULL_SYNC.  This setting guarantees that whenever any of the atomic or transactional writes complete, all other participating nodes which cache the written data has been updated.

References:
https://ignite.apache.org/

Popular posts from this blog

#processing @Microsoft #office #Excel files with @TheASF POI (part II)

...
     Apache POI's OPCPackage abstract class represents a container that can store multiple data objects.  It is central to the processing of Excel(*.xlsx) files.  We only need to use its static open method to process an InputStream instance.  Further, we can "read" these Excel files via the XSSFWorkbook class.  This class is a high level representation of a SpreadsheetML workbook.  From an XSSFWorkbook, we can get any existing XSSFSheets within the workbook.  Then, we can further subdivide any XSSFSheet into rows and analyze the cell data within the rows.  In general, given certain assumptions in the format of the Excel document, we can extract data as text  from a cell and perform any number of business processes.

     In the Java function code excerpt below, we assume we have an Excel(*.xlsx) file represented as an InputStream.

        @Override
    public Iterator<Row> apply(InputStream inputStream) {

        try(OPCPackage pkg = OPCPackage.open(…

@Airbnb's Aerosolve API is a gift to the #ML community! (part II)

...   Airbnb’s Aerosolve #machinelearning API contains a number of Java classes representing standard mathematical models. These classes implement the API’s Model interface -- requiring them to implement the interface’s scoreItem and debugScoreItem methods.
  The purpose of the debugScoreItem method is to provide an explanation as to how the item was scored along with the score.
In order to score an item, a Thrift struct appropriately named FeatureVector is required as input.
If you’re curious, a Thrift struct is similar to a class in OOP minus inheritance.
As a Thrift struct, the FeatureVector has a very simplistic structure as is shown below:
struct FeatureVector {
  1: optional map<string, set<string>> stringFeatures;    2: optional map<string, map<string, double>> floatFeatures;   3: optional map<string, list<double>> denseFeatures; }
What this essentially says is a FeatureVector will have as its core one of these three structures. The key of e…