Skip to main content

Oracle NoSQL Database meets Elasticsearch (part 1.1)

The Oracle NoSQL Database is a scalable, distributed low latency NoSQL database built on Oracle Berkeley DB Java Edition.  Its Docker image can be pulled and run with no changes needed to the Dockerfile. With that being said, we can have an Oracle NoSql Docker container up and running with the following command:
     docker run --restart=always -dit --name=nosqlce \
-p 5000-5020:5000-5020 oracle/nosql
  To verify the container, you can use a 'docker logs' command.  if you're still not convinced, you can use a 'docker exec' command, utilizing kvstore.jar, similar to the following:
     docker exec -it nosqlce java -Xmx256m -Xmx256m \
-jar /kv-4.3.11/lib/kvstore.jar status -root /kvroot
  Here, the root parameter is required.
  Hopefully, this command returns a status of 'RUNNING.'  The reason for the '-Xmx256m -Xms256m' settings it's generally a best practice to keep heap usage low for administrative tasks.  if you get curious about the other utility commands available, use the 'help' command. Because of its length, you may want to create an appropriately named file in your '/usr/local/bin' directory for convenience.  You may have to use 'chmod +x' to make the file executable.
Now, what if you had Java and kvstore,jar installed locally and wanted to interact with your Oracle NoSQL Database using these?  After verifying your Java installation, or installing Java, you can download Oracle NoSQL to the directory of your choosing (i.e. /opt) with the following 'curl' command (as root if necessary):

curl -OL \
  After unzipping and removing the zip file, we can use the following command to verify connectivity to our Oracle NoSQL Docker instance:
     java -Xmx256m -Xms256m -jar /opt/kv-4.3.11/lib/kvstore.jar version
  Be sure to adjust this for the location of your NoSQL database install.


Popular posts from this blog

More Guice Please!!!: Re-Learning Google's Agile Lightweight Dependency Injection Library (Part 1.1)

Google Guice is used as a lightweight dependency injection framework that further assists developers in modularizing their applications.  Google shared this very useful library with the development community in 2010 in between the Java SE 6 and Java SE 7 releases.  This library is used in some of Java’s (and now Scala’s) most prominent libraries and platforms such as the Simian Army platform shared by Netflix.
We will begin our discussion of Google Guice with its Module interface.  In the Guice developers’ own words, ‘A Guice-based application is ultimately composed of little more than a set of modules and some bootstrapping code.’  We will not be using this interface directly, but it gives us a very good context from which to start.  Instead, we will be extending the abstract class that implements it -- intuitively named AbstractModule.  
If you ever get a chance to look at the Module interface JavaDoc or source code, you’ll see a configure method taking a parameter of type Binder.  

#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.

    public Iterator<Row> apply(InputStream inputStream) {

        try(OPCPackage pkg =…

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(k…