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.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- New Products
- Users, Permissions and Multitenant Sites
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- Non-Linux FOSS: MenuMeters
- Android Candy: Bluetooth Auto Connect