Some NoSQL vendors claim to be enterprise-ready, when the reality is that essential enterprise properties have been relaxed – and in some cases removed altogether – in favour of performance.
This may be acceptable in a prototype or in non-production environments but it is hard to imagine why most organisations would want to work with their vital data assets in this way. Why take such unnecessary risks with your data?
This holds true for enterprises of many different sizes, not just large corporations. In fact, the business impact might even be more severe for a smaller company. And while there is certainly a role for NoSQL databases in non-mission critical applications, organisations of vastly differing sizes are choosing to deploy fully enterprise-grade NoSQL databases.
NoSQL databases are traditionally characterised as being flexible (schema-agnostic), agile, fast, scalable, and with built-in disaster recovery and high availability. What is distinctive about an enterprise-class NoSQL database is its support for additional enterprise-scale application requirements, namely: ACID (atomic, consistent, isolated, and durable) transactions, government-grade security and elasticity, as well as automatic failover.
>See also: To NoSQL or not to NoSQL?
Now that NoSQL is going mainstream into the data centre, the data-centre custodians are scrutinising these new technologies to make sure that they have all of these essential enterprise capabilities, not just a random subset.
Only in this way can organisations leverage and manage all data within the enterprise to drive revenue, streamline operations and manage risk.
The ACID test
Support for ACID transactions is essential to ensure that all transactions are processed reliably in a production environment. With ACID, insert/update/delete operations are performed atomically and subsequent queries see those changes with zero latency. Once a transaction is complete, it stays that way, even if disaster strikes.
Some NoSQL vendors who claim to be ACID compliant in reality rely on ‘locking’ to make this guarantee. Locking is the process of not allowing data that is being used in one transaction to be changed, or even read, by another transaction until the first one has finished.
If a user wants to check whether an item has been shipped, an account is in debit or an engineer is on their way, the user wants the true picture. This can cause serious performance issues for some users if others are running complex, lengthy queries.
It’s hard to add transactional consistency to a database that wasn’t designed to be consistent, which is why the term ‘eventual consistency’ was coined. Eventual consistency is not consistency. If a business is not using a consistent database, then it can run the same search twice, five minutes apart, and get different results from the exact same search. It’s a risky proposition.
The same issue applies to backups. Having ACID capability is the only way to be sure of a consistent backup every time.
NoSQL databases built from the ground up to support ACID don’t have these problems because they use techniques such as multi-version concurrency control (time-stamping control over the cluster) to manage even the biggest data sets and maintain full consistency and sustained performance levels for all users at all times.
Security
Allowing any individuals – including developers – to have carte blanche access to all of an organisation’s sensitive data stored in a database is not ideal.
As with the consistency issue, many open source NoSQL vendors do not have enterprise-grade security capabilities baked into their software.
It’s incredibly hard to add this to a NoSQL database that wasn’t designed from the outset to be secure. And even where security can be added to applications, this puts a huge burden on the application developers, not to mention the additional cost and time implications.
There is nonetheless a huge raft of mission-critical applications out there where delegating security to the application layer would result in too great a compromise. For these applications, constraining the capabilities for each login, whether human or computer, to appropriate content and execution rights must be implemented within the database engine.
Without the proper access controls and certifications, privacy and security controls alone can significantly impact or even derail efforts where the data has privacy or retention regulations.
Fully enterprise-grade NoSQL databases include fine-grained privileges, role-based security, document-level permissions and HTTPS access. Some also support government-grade security validation in accordance with the provisions of specific government programmes.
Elasticity
As more organisations turn to virtualisation, public or private cloud – even for mission-critical applications – inherent elasticity in a NoSQL database is vital.
Elasticity ensures that the infrastructure is sized correctly and can dynamically and automatically rebalance, scaling up or down as needed, without downtime.
It’s very hard to do this without having full ACID compliance. For example, how do I know when my workload has left one machine and moved to another?
But ACID-based elasticity doesn’t only increase service levels and guarantee transactional consistency, it can also significantly decrease costs by automatically optimising the use of shared resources 24/7.
Now that more and more organisations are turning to NoSQL for their operational databases, enterprise-grade NoSQL, with full ACID compliance, is rapidly becoming a checklist item.
A NoSQL database that has been designed from the get-go to support ACID transactions and provide incontestable data consistency is a safe bet, whether you’re a global bank or a local e-tailer.
Trying to bolt on these capabilities after the fact leaves the door open to problems. Why take that risk?
Sourced form Adrian Carr, VP, EMEA, MarkLogic
