Maybe you’re a technical professional who’s done work with only relational databases… Oracle, SQL Server, MySQL, etc. Maybe you’ve just heard of NoSQL databases but haven’t had the chance to dive in and understand what, exactly these modern data storage mechanisms are all about.
The purpose of this article is to provide a high level understanding of exactly what MongoDB is, and why solutions like MongoDB exist.
To understand why MongoDB exists, we need to go back in time to the 1970’s and 1980’s when Relational Technology was developed.
SQL was initially developed at IBM by Donald D. Chamberlin and Raymond F. Boyce in the early 1970s. This version, initially called SEQUEL (Structured English Query Language), was designed to manipulate and retrieve data stored in IBM’s original quasi-relational database management system, System R, which a group at IBM San Jose Research Laboratory had developed during the 1970s. The acronym SEQUEL was later changed to SQL because “SEQUEL” was a trademark of the UK-based Hawker Siddeley aircraft company.
In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the potential of the concepts described by Codd, Chamberlin, and Boyce, and developed their own SQL-based RDBMS with aspirations of selling it to the U.S. Navy, Central Intelligence Agency, and other U.S. government agencies. In June 1979, Relational Software, Inc. introduced the first commercially available implementation of SQL, Oracle V2 (Version2) for VAX computers.
After testing SQL at customer test sites to determine the usefulness and practicality of the system, IBM began developing commercial products based on their System R prototype including System/38, SQL/DS, and DB2, which were commercially available in 1979, 1981, and 1983, respectively.
If you think about the 1970’s from a financial perspective – how much did the elements of an application cost? Well, there’s the computer – disk, cpu, and memory. Each of these elements were much more expensive back then.
In fact, let’s look at the cost of hard disk specifically.
|Price of a Gigabyte by Year|
And then there’s the developer or database administrator – the amount of money paid to these individuals to design, develop or maintain the database. This variable of the equation was much cheaper than today. Let’s dig into this a bit. To understand how differently we (computer programmers, developers, and DBA’s) are compensated between the 80’s and today, let’s look at two key factors – the rate of pay (then, and now) as well as the the U.S. Rate of Inflation. First – finding the rate of pay for a computer programmer from the 1980’s proved difficult – but I did find one source which listed the average weekly earnings for a computer programmer at $472 per week. Which works out to roughly $24k per year.
Now, if we calculate the impact of inflation on this number, we get to roughly $71k per year.
This may not be the most scientific method – but let’s assume I’m within a few thousand dollars.
Even if we’re at the 25th Percentile ($60k) today, we’re still earning more than 27% more for doing the same work. That’s a sizable increase. At the high end, we’re earning more than 82% more for the same jobs.
So, why go into this detail?
We, as DBA’s and developers are earning more than ever before and the costs that are incurred as part of having us working on applications represent a larger slice of the overall cost pie. Therefore, it only makes sense that we should be leveraging systems that maximize the efficiency to our resource… to us, rather than to the infrastructure.
It just doesn’t make sense to use a system that’s focused on reducing the number of bits and bytes stored at the cost of developer and DBA time.