Who Cares About NoSQL?
Who Cares About NoSQL?
Have NoSQL databases gone away or are they still a big ticket item with devs? One engineer shares his insights as to why they're still relevant and why you should care.
Join the DZone community and get the full member experience.Join For Free
Running out of memory? Learn how Redis Enterprise enables large dataset analysis with the highest throughput and lowest latency while reducing costs over 75%!
With all the hullabaloo with NoSQL companies going public and then losing a third of their valuation, being bought out, and some even going into administration and then being resurrected by customers — you could be forgiven for thinking the NoSQL bubble has spectacularly burst.
It’s crunch time for NoSQL companies, that’s for sure. They need to grow up. Rapidly. They need to become easier to deploy, use, and manage. But they’re working on that.
The effort to deploy NoSQL databases, though, is worth it for so many customers. I wanted to bang the drum a little for NoSQL in these troubled times, so here’s my list of how you can really benefit from using them.
Oh, and it’s a stream of thought kinda thing — these are in no particular order of preference.
1. You Could Save Millions on Oracle Coherence or Software AG Terracotta Licenses
These middleware layers are used to cache often-used data in the Java tier. They are extensively used in financial services to reduce the load on underlying databases or act as in-process caches and distributed memory shared across many machines.
They’re bloody expensive, though! Like… eye-wateringly expensive. Even for very rich banking types.
You can use a NoSQL key-value store to do a similar job — and for much less cash. An in-memory key-value store for transient data can easily be powered by the extremely lightweight Redis NoSQL database.
If you’re in the cloud, take a look at AWS DynamoDB.
These also have useful functionality for complex and custom data types so they may even be easier to code against for some use cases.
2. Save Millions on Not Coding Around Relational Database Structural Issues
Relational databases are great… for relational data.
For structures that change rapidly or that are deeply nested, they introduce a bunch of overhead.
Imagine an XML or JSON document structure — say, a complex trade FPML document. Let’s say you want to update it whole but also want to be able to retrieve it by key fields on an ad hoc basis.
To do this in relational databases, you have to either code a special function to handle introspecting the XML data — not the fastest — or duplicate some of the fields as relational columns — not easy on storage space.
And then you’ve got to code around the issue and spend a lot of time thinking of the best way to do things. It’s just not fun or productive.
Using a document NoSQL database which can natively handle either XML (MarkLogic) or JSON (pretty much all of them — MongoDB, ArangoDB, CosmosDB, MarkLogic, etc.) data will greatly simplify storage and query of complex document structures.
And they’ll save you a boatload of development and testing time, too.
Oh, and their licenses are cheaper, and they run on commodity hardware. That’s easy math.
3. Save Pulling Out Your Hair Doing Complex Queries Over Thousands of Pieces of Related Data
If you’ve got ridiculously complex relationships (in data… not in your personal life…) between entities in a complex graph of information and need to traverse those relationships, you need an effective way to index that data in order to make those queries fly.
This is where SPOGI-style indexes come in for graph NoSQL databases! Good choices here are AllegroGraph (very standards-compliant), GraphDB, and Neo4j (not W3C standards compliant, but has a very nice query language of its own).
Shortest path queries are really, really computationally complex. Especially if they’re calculating the cost of the paths as they traverse them from data in the graph.
If you’re doing a lot of these queries (i.e. sat nav-style application), you need a dedicated data store.
Only graph NoSQL databases provide that.
4. If You Have a Whole Bucket Load of Data About Each Record... Sometimes
Sometimes, it’s possible for a single record to have only a few properties out of thousands of possible ones.
You may not want the overhead of defining them all up front — or you may simply not know them all up front!
You may also only want to pull some groups of properties back in one go (i.e. a summary, or one aspect of the entity), and want it to be fast.
The way that wide column stores (AKA columnar NoSQL databases, AKA BigTable clones) work makes this very efficient.
Be it Hypertable (a good commercial offering), Cassandra (AKA DataStax Enterprise), or Accumulo (good for securing individual data fields), these NoSQL databases can simplify your application and drive more performance.
They’re also easier to understand if your mind is totally stuck in the world of tables and columns!
5. You May Be Indecisive or Have Every Type of Data Imaginable but Don’t Want 10 Database Products
In this instance, a hybrid NoSQL database may be for you. Ones that can handle a variety of query types — be they simple key-value/name-fetch applications, document structures, and graph queries — can all be handled by a single, true-hybrid, database using one API.
These databases include MarkLogic Server or ArangoDB. Definitely try those out.
There are a few difficulties in using NoSQL databases — but the benefits far, far outweigh them. The great thing is that you can download the above databases and try them out in minutes.
No great time overhead, and not sales droids to talk to until you think you may find them valuable. Just have a go today.
I cannot recommend enough that you open your mind and try them out. The possibilities are truly endless — not to mention, profitable for you and your employer!
Published at DZone with permission of Adam Fowler , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.