SQL vs. NoSQL
My advice? Don't think of SQL vs. NoSQL as an either/or question. Options are a good thing. Many alternatives exist, so if you are having issues with your chosen database, experiment with different products on both sides and run your own benchmarks.
Also look into how you are using your database. If the database was “bootstrapped” while you were creating your killer application or service, and it is starting to give you problems, you might have an easily solvable design issue at the root of your troubles. If databases are not your thing, consult with an expert. RDBMSes have been around a long time, and there are plenty of experts.
Whatever you decide to do, don't think of NoSQL as your escape from the SQL RDBMS world. NoSQL databases are not a panacea. I asked my boss, Monty Widenius, the creator of MySQL, what his opinion on the whole NoSQL vs. SQL thing was. His answer: “Non-SQL gives you a very sharp knife to solve a selected set of issues. If you find SQL too hard to use, you should not try Non-SQL.”
His basic point is that if you don't understand SQL RDBMSes, you'll probably end up hurting yourself by jumping into NoSQL. Key-value stores like those found in NoSQL databases do work for certain kinds of data, but they don't work well at all for other kinds. It is instructive to point out that the companies that use and have championed NoSQL databases have not given up on SQL RDBMSes. They continue to use them in vital roles.
Finally, many of the NoSQL ideas are based on old technology. Key-value stores have been around for more than 20 years, for example. New this time around are things like map-reduce (some claim that even this is an old idea), which spread the workload over many computers. In that sense, NoSQL databases really should be called distributed-DBMSes (DDBMSes?). Basically, distributed RDBMSes, without the R.
Whatever you call them, NoSQL databases are solving problems that were considered “solved” by many in the RDBMS world a long time ago. They're just solving the problems in a different way, and they have a different set of requirements. If this new-old way solves an issue you're having, great! On the flip side, if your current RDBMS is meeting your needs, don't feel like you need to jump on the bandwagon.
What Is CAP?
The CAP Theorem, also called Brewer's Theorem, first was proposed by Eric Brewer in a July 2000 keynote at the ACM Symposium on the Principles of Distributed Computing. It was formally proved in 2002 by Seth Gilbert and Nancy Lynch of MIT. The CAP Theorem states that it is impossible for any shared-data system to guarantee simultaneously all of the following three properties: consistency, availability and partition tolerance.
Consistency in CAP is not the same as consistency in ACID (that would be too easy). According to CAP, consistency in a database means that whenever data is written, everyone who reads from the database will always see the latest version of the data. A database without strong consistency means that when the data is written, not everyone who reads from the database will see the new data right away; this is usually called eventual-consistency or weak consistency.
Availability in a database according to CAP means you always can expect the database to be there and respond whenever you query it for information. High availability usually is accomplished through large numbers of physical servers acting as a single database through sharing (splitting the data between various database nodes) and replication (storing multiple copies of each piece of data on different nodes).
Partition tolerance in a database means that the database still can be read from and written to when parts of it are completely inaccessible. Situations that would cause this include things like when the network link between a significant number of database nodes is interrupted. Partition tolerance can be achieved through some sort of mechanism whereby writes destined for unreachable nodes are sent to nodes that are still accessible. Then, when the failed nodes come back, they receive the writes they missed. In Cassandra, this is called hinted handoff. A database with good partition tolerance can span multiple data centers, whereas one with weak partition tolerance basically is bound to a single data center.
What Is ACID?
ACID is the classic measure of determining whether your database is good. A transaction in a database is a single logical operation. An example would be inserting an address or updating a phone number in an employee database. Every database provides methods to do operations like those, but ACID formalizes the process.
Atomicity means that the transaction either succeeds or fails. If the transaction fails, it should fail completely, and the database should be left in the state it was in before the transaction started.
Consistency means that the database is in a known good state both before and after the transaction.
Isolation means that transactions are independent of one another, and if two transactions are trying to modify the same data, one of them must wait for the other to finish before it can begin.
Durability means that once the transaction has completed, the changes made by the transaction will persist, even if there is a system failure. A transaction log of some sort usually is used for this purpose. In MariaDB and MySQL, this is called the binary log.
So, what is the opposite of ACID? BASE (Basically Available, Soft-state, Eventual consistency), of course. BASE is a retronymn coined by Dan Pritchett in an article in the ACM Queue magazine for describing a database that does not implement the full ACID model, with the main difference being that it is eventually consistent. The idea is that if you give up some consistency, you can gain more availability and greatly improve the scalability of your database.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Devuan Beta Release
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The US Government and Open-Source Software
- The Humble Hacker?
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- Open-Source Project Secretly Funded by CIA
- New Container Image Standard Promises More Portable Apps
- AdaCore's SPARK Pro
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide