At the Forge - NoSQL? I'd Prefer SomeSQL
The rise of increasingly variable document types, combined with the scalability issues associated with Web applications, has led many in the Web developer community to push for NoSQL, a variety of solutions that are united only in their rejection of the relational database model. The term itself was coined in 2009 by Eric Evans, who wanted to describe the collection of non-relational tools that were rising in popularity. As I write this in early 2010, we are seeing a veritable NoSQL revolution, with a number of prominent Web developers and sites switching away from relational database servers to other systems.
The reasons for the switch to these various NoSQL systems vary with the site and developer, but they echo the reasons that I outlined above: a good match with the objects used to program the application, the flexibility that a document-oriented database provides and the easier replication that a NoSQL system offers. These systems are far from identical in approach, communication or performance, but they each have their own backers and are released under an open-source license. Besides, many of these systems are currently in use on high-performance Web sites, such as Facebook and LinkedIn, so if your site is smaller than those, the odds are good that these solutions will work for you too. Another advantage is that the most popular of these systems offer a number of language bindings, such that it doesn't matter whether you're using Ruby, Python, Java or PHP.
There is no doubt in my mind that these sorts of NoSQL solutions might be very useful and do indeed solve many problems. But, a large part of me wonders if we really should be throwing away 30 years of accumulated knowledge about relational databases. Moreover, relational databases were designed to ensure data integrity, not just the fast storage and retrieval of data. And, although these modern NoSQL solutions might indeed be fast and flexible, their lack of integrity checking does worry me somewhat. Maybe I'm old-fashioned, but I like the fact that I can define a relational database table to be NOT NULL or UNIQUE and, thus, know that the data contained within exists, is unique or both. I like knowing that each record in my database has a unique identifier. I like being able to traverse foreign keys, such that when one record points to another, I know there will be something on the other end, rather than the database equivalent of a null pointer. I'm also curious to see how such databases avoid duplication of data, or what the NoSQL equivalent of “normalization” might be.
So, I believe the people who think that NoSQL is a complete solution for all application storage needs are exaggerating quite a bit and are ignoring a great deal of wisdom associated with relational databases. Databases work so well, and are so easy to work with nowadays, that it seems a shame to put them out to pasture because they are having trouble handling loads of the top tier of Web applications.
Indeed, there are a variety of problems for which NoSQL offerings seem to have no solution, at least for now. They don't pay any attention to data integrity, be it a lack of null data or ensuring that only certain values will be allowed to be stored. They don't offer any way of associating objects to one another on multiple dimensions, which I find to be one of the most attractive elements of the relational model. And the query languages are far from standardized, meaning that moving from one NoSQL solution to another requires translating the query from one language to another.
That said, there is a growing class of Web applications for which relational databases are a poor fit and for which a document-oriented approach might indeed be superior. My dissertation software, which works with a large number of text documents, might well be a good example of a program that would benefit from a document-oriented approach, and I already have begun to explore such alternatives. However, even if I switch part of my software to use a NoSQL solution, it will be for a portion of the data storage, not for the entirety. In this way, I hope to benefit from the best of both worlds, using a relational database where it makes sense and a document database where it provides the superior solution.
My feeling is that the NoSQL movement, at least in the image its name projects, is a bit extreme and fails to appreciate the advantages and sophistication of many relational solutions. I would prefer a more nuanced approach, which might be called SomeSQL, in which non-relational databases are seen as additional tools, which can (hopefully) be integrated into a larger data-storage solution. After all, memcached and relational databases have managed to live in harmony for a number of years already. With a bit of planning, and with the right tools in place, I would argue that a combination of SQL and NoSQL could be extraordinarily powerful.
There is, of course, the chance that the NoSQL people are completely right, and that we are seeing the decline of one technology in favor of another. Perhaps we're at the leading edge of a new revolution, the database equivalent of the growth of high-level “scripting” languages in the 1990s. But, I'd prefer to see this as a new technology that Web developers will have to fit into their toolboxes, and which they will need to understand when designing and writing new Web applications.
Over the coming months, I plan to explore some of the better-known NoSQL solutions. I will look at them from the perspective of a developer—what do they offer, and why would I want to use this over a relational database or its NoSQL rivals? I cannot yet say which of these technologies will be my favorite or which would be appropriate for your applications. But, I do believe that the SomeSQL approach is one that has the potential to improve our applications' flexibility and performance dramatically, at the expense of the data-storage simplicity to which we have grown accustomed during the past few decades.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide