Articles tagged voltdb

The views expressed in this blog are strictly personal, and do not necessarily represent the views of Evident Software.

By Scott Barnett

Last month, we launched Evident ClearStone 4.5, which includes NoSQL logging and NoSQL reporting features. This software release marks an important milestone in the evolution of Evident Software. Over the summer, we made a decision to aggressively go after the NoSQL DB market, expanding our previous support for compute-grid technologies such as DataSynapse and application-grid technologies such as Oracle Coherence by offering NoSQL reporting, NoSQL logging, management and performance monitoring.

Why make this change of course? There were several reasons:

  1. NoSQL might not still be called “NoSQL” in a few years, but it absolutely will be an important technology for enterprise applications. Think back to how the Java Application Server came of age in the mid/late 1990′s. That technology required several iterations to become the Java Application Server. The market took a few years to coalesce and turn into something that the broad industry could understand, market, and build around. Today NoSQL is going through a similar evolution. We’re just starting to see forecasts of the size of the NoSQL market. We suspect it won’t be called NoSQL a year from now (some other people seem to agree) – as technologies such as Hadoop, Data Caching Platforms such as Coherence, GemFire, Terracotta and hybrid in-memory databases such as VoltDB all vie for developer mind-share. Whatever it’s called, this is the “new” tier in the application stack, and it’s going to need focused and dedicated capabilities from a management/monitoring perspective, including NoSQL logging and NoSQL reporting. Here’s a great database (no pun intended) of systems that fall into the NoSQL realm.
  2. Correlating metrics and events between the NoSQL tier and the other existing tiers in the application (and system) stack will be key capabilities for monitoring and managing NoSQL applications. Each tier cannot continue to have its own NoSQL logging and monitoring capabilities – monitoring needs to be integrated, so enterprises can get a holistic view of their applications. This is a hard problem to solve.It’s also a valuable problem to solve. We are solving this problem already now for the caching technologies I listed above. Now we want continue extending this capability across the different tiers of the application stack.
  3. Visualization is the key to success in APM. When you are gathering so many metrics/events in real time, it’s a challenge to determine what is really important to DevOps.. We’ve been told we’ve done a great job of figuring this one out – our user interface is intuitive, attractive, and meaningful. Making sense of all that data is hard to do. Without it, you have lots of great data with no insight. You need insight to make good decisions.
  4. Our goal is to support every NoSQL system out there. To meet this goal requires a change of strategy – so you will see us open up our platform so that people can build and deploy their own “Management Packs.” We currently have Management Packs for DataSynapse GridServer, Oracle Coherence, Apache Cassandra, Memcached (with Membase coming very soon), WebLogic Server, and jBoss. We are working on many more, but we want to move even faster. So you will see a Management Pack framework that allows developers to build their own Management Packs (we can help you too!). It is not hard to do this, and we will roll out a developer site shortly for people to share/collaborate/contribute. We will start by contributing our own management packs to the site.

So, 4.5 is the next step in our evolution and a hearty step forward in our embrace of all things NoSQL as the latest, greatest participant in the application stack. From our conversations with customers and prospects over the past few months, we know many of you agree our vision of NoSQL reporting, monitoring and management. We look forward to working with you on this initiative in the months and years ahead. We are very interested in your thoughts, ideas, and suggestions on how to continue this process, so please share your ideas with us!

By Scott Barnett

I attended the Boston Big Data Summit last week, which was extremely well attended and an excellent session. Moderated by Fred Holahan (who announced his new position as VP, Marketing at VoltDB, congrats!), the panel discussion included folks from 10gen (the “MongoDB guys”), Cloudera (the “Hadoop guys”), Infobright and VoltDB. (As an aside, it seems that Cloudera has done a great job branding their company around Hadoop, but 10gen seems to want to sit behind the Mongo brand?)

Anyway, the topic was real world problems that each of the vendors solutions can address. Each vendor got 10 minutes to talk about a use case that was relevant to their solution. Without going into the details of each use case, what struck me was how similar the excitement of this space is to what happened in the mid-90′s with Java Application Servers.

Questions from the audience focused on scalability and “hardening” of each solution – as well as limitations of each solution as it pertained to certain use cases. Each of the vendors tried to defer to the others with regard to specific use cases for specific products – I’m not sure how long that will last, as there is significant overlap of the solutions – while each one does focus on a specific area, it will be impossible for them not to explore expansion into other capabilities.

There was also a discussion regarding management/monitoring of applications written with these tools. Both Cloudera and VoltDB mentioned that they are releasing management functionality in the next releases of their respective products – this is a good sign, as no serious development shop is going to put applications in production without basic management, so it indicates that these vendors are getting these types of questions from their community. There was also an excellent comment from the audience regarding DevOps – that their operations team has a detailed checklist that development is required to fill out before their applications can be put in production – and part of the checklist is to identify what tools are needed to manage and monitor the application, and how those tools can interoperate with the “standards” already in place. This had personal resonance to what we are seeing at Evident – where it is the developers and architects who are the initial users of ClearStone, and they then recommend production use of our tool to Operations once the applications are ready to go live. It also confirmed our belief that we need to continue to make ClearStone easier and useful for developers during their build/deploy process.

Overall the session was excellent – given that it was my first Big Data summit so I didn’t know the “rules”, I will recommend they publish the following guidelines (assuming they are all standard):

  • Dinner is served and it’s really good, so don’t snack before hand :-)
  • Networking is primarily done before the event, and it ends later than stated, so if you have someplace else to be, get there a little early