{"id":2576,"date":"2013-08-19T07:48:00","date_gmt":"2013-08-19T07:48:00","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=2576"},"modified":"2013-08-19T07:48:00","modified_gmt":"2013-08-19T07:48:00","slug":"on-nosql-interview-with-rick-cattell","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2013\/08\/on-nosql-interview-with-rick-cattell\/","title":{"rendered":"On NoSQL. Interview with Rick Cattell."},"content":{"rendered":"

\n” There aren’t enough open source contributors to keep projects competitive in features and performance, and the companies supporting the open source offerings will have trouble making enough money to keep the products competitive themselves. Likewise, companies with closed source will have trouble finding customers willing to risk a closed source (or limited open source) solution. It will be interesting to see what happens. But I don’t see NoSQL going away, there is a well-established following.”<\/em> –Rick Cattell.<\/strong>\n<\/p><\/blockquote>\n

I have asked Rick Cattell<\/strong>, one of the leading independent consultants in database systems, a few questions on NoSQL<\/strong>.<\/p>\n

RVZ<\/p>\n

Q1. For years, you have been studying the NoSQL area and writing articles about scalable databases. What is new in the last year, in your view? What is changing?<\/strong><\/p>\n

Rick Cattell: <\/strong> It seems like there’s a new NoSQL player every month or two, now!
\nIt’s hard to keep track of them all. However, a few players have become much more popular than the others.<\/p>\n

Q2. Which players are those?<\/strong><\/p>\n

Rick Cattell: <\/strong> Among the open source players, I hear the most about MongoDB<\/a>, Cassandra<\/a>, and Riak<\/a> now, and often HBase<\/a> and Redis<\/a>. However, don’t forget that the proprietary players like Amazon<\/a>, Oracle<\/a>, and Google<\/a> have NoSQL systems as well. <\/p>\n

Q3. How do you define “NoSQL”?<\/strong><\/p>\n

Rick Cattell: <\/strong> I use the term to mean systems that provide a simple operations like key\/value storage or simple records and indexes, and that focus on horizontal scalability for those simple operations. Some people categorize horizontally scaled graph databases<\/a> and object databases<\/a> to be “NoSQL” as well. However, those systems have very different characteristics. Graph databases and object databases have to efficiently break connections up over distributed servers, and have to provide operations that somehow span servers as you traverse the graph. Distributed graph\/object databases have been around for a while, but efficient distribution is a hard problem. The NoSQL databases simply distribute (or shard) each data type based on a primary key; that’s easier to do efficiently.<\/p>\n

Q4. What other categories of systems do you see?<\/strong><\/p>\n

Rick Cattell: <\/strong> Well, there are systems that focus on horizontal scaling for full SQL with joins, which are generally called “NewSQL<\/a>“, and systems optimized for “Big Data<\/a>” analytics, typically based on Hadoop<\/a> map\/reduce<\/a>. And of course, you can also sub-categorize the NoSQL systems based on their data model and distribution model.<\/p>\n

Q5. What subcategories would those be?<\/strong><\/p>\n

Rick Cattell: <\/strong> On data model, I separate them into document databases<\/a> like MongoDB and CouchBase<\/a>, simple key\/value stores<\/a> like Riak and Redis, and grouped-column stores<\/a> like HBase and Cassandra. However, a categorization by data model is deceptive, because they also differ quite a bit in their performance and concurrency guarantees. <\/p>\n

Q6: Which systems perform best?<\/strong><\/p>\n

Rick Cattell: <\/strong> That’s hard to answer. Performance is not a scale from “good” to “bad”… the different systems have better performance for different kinds of applications. MongoDB performs incredibly well if all your data fits in distributed memory, for example, and Cassandra does a pretty good job of using disk, because of its scheme of writing new data to the end of disk files and consolidating later. <\/p>\n

Q7: What about their concurrency guarantees?<\/strong><\/p>\n

Rick Cattell: <\/strong> They are all over the place on concurrency. The simplest provide no guarantees, only “eventual consistency<\/a>“. You don’t know which version of data you’ll get with Cassandra. MongoDB can keep a “primary” replica<\/a> consistent if you can live with their rudimentary locking mechanism.
\nSome of the new systems try to provide full ACID transactions. FoundationDB<\/a> and Oracle NoSQL<\/a> claim to do that, but I haven’t yet verified that. I have studied Google’s Spanner paper<\/a>, and they do provide true ACID consistency in a distributed world, for most practical purposes. Many people think the CAP theorem<\/a> makes that impossible, but I believe their interpretation of the theorem is too narrow: most real applications can have their cake and eat it too, given the right distribution model. By the way, graph\/object databases also provide ACID consistency, as does VoltDB<\/a>, but as I mentioned I consider them a different category. <\/p>\n

Q8: I notice you have an unpublished paper on your website, called 2x2x2 Requirements for Scalability<\/a>. Can you explain what the 2x2x2 means?<\/strong><\/p>\n

Rick Cattell: <\/strong> Well, the first 2x means that there are two different kinds of scalability: horizontal scaling over multiple servers, and vertical scaling for performance on a single server. The remaining 2×2 means that there are two key features needed to achieve the horizontal and vertical scaling, and for each of those, there are two additional things you have to do to make the features practical. <\/p>\n

Q9: What are those key features?<\/strong><\/p>\n

Rick Cattell: <\/strong> For horizontal scaling<\/a>, you need to partition and replicate your data. But you also need automatic failure recovery and database evolution with no downtime, because when your database runs on 200 nodes, you can’t afford to take the database offline and you can’t afford operator intervention on every failure.
\nTo achieve vertical scaling<\/a>, you need to take advantage of RAM and you need to avoid random disk I\/O. You also need to minimize the overhead for locking and latching, and you need to minimize network calls between servers. There are various ways to do that. The best systems have all eight of these key features. These eight features represent my summary of scalable databases in a nutshell.<\/p>\n

Q10: What do you see happening with NoSQL, going forward?<\/strong><\/p>\n

Rick Cattell: <\/strong> Good question. I see a lot of consolidation happening… there are too many players! There aren’t enough open source contributors to keep projects competitive in features and performance, and the companies supporting the open source offerings will have trouble making enough money to keep the products competitive themselves. Likewise, companies with closed source will have trouble finding customers willing to risk a closed source (or limited open source) solution.
\nIt will be interesting to see what happens. But I don’t see NoSQL going away, there is a well-established following.<\/p>\n

————–
\nR. G. G. “Rick” Cattell <\/strong> is an independent consultant in database systems.
\nHe previously worked as a Distinguished Engineer at Sun Microsystems, most recently on open source database systems and distributed database scaling. Dr. Cattell served for 20+ years at Sun Microsystems in management and senior technical roles, and for 10 years in research at Xerox PARC and at Carnegie-Mellon University. Dr. Cattell is best known for his contributions in database systems and middleware, including database scalability, enterprise Java, object\/relational mapping, object-oriented databases, and database interfaces. He is the author of several dozen papers and five books, and a co-inventor of six U.S. patents.
\nAt Sun he instigated the Enterprise Java, Java DB, and Java Blend projects, and was a contributor to a number of Java APIs and products. He previously developed the Cedar DBMS at Xerox PARC, the Sun Simplify database GUI, and SunSoft’s CORBA-database integration.
\nHe is a co-founder of SQL Access (a predecessor to ODBC), the founder and chair of the Object Data Management Group<\/a> (ODMG), the co-creator of JDBC, the author of the world’s first monograph on object\/relational and object databases, a recipient of the ACM Outstanding PhD Dissertation Award, and an ACM Fellow.<\/em><\/p>\n

Related Posts<\/strong><\/p>\n

–On Oracle NoSQL Database \u2013Interview with Dave Segleau. July 2, 2013<\/a><\/strong><\/p>\n

–On Real Time NoSQL. Interview with Brian Bulkowski. May 21, 2013<\/a><\/strong><\/p>\n

Resources<\/strong><\/p>\n

– Rick Cattell home page.<\/a><\/strong><\/p>\n

– ODBMS.org Free Downloads and Links<\/a><\/strong>
\nIn this section you can download free resources covering the following topics:<\/em>
\nBig Data and Analytical Data Platforms<\/a>
\nCloud Data Stores<\/a>
\nObject Databases<\/a>
\nNoSQL Data Stores<\/a>
\nGraphs and Data Stores<\/a>
\nObject-Oriented Programming<\/a>
\nEntity Framework (EF) Resources<\/a>
\nORM Technology<\/a>
\nObject-Relational Impedance Mismatch<\/a>
\nNewSQL, XML, RDF Data Stores, RDBMS<\/a><\/p>\n

Follow ODBMS.org on Twitter<\/em>: @odbmsorg<\/a><\/strong><\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

” There aren’t enough open source contributors to keep projects competitive in features and performance, and the companies supporting the open source offerings will have trouble making enough money to keep the products competitive themselves. Likewise, companies with closed source will have trouble finding customers willing to risk a closed source (or limited open source) […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[27,35,66,92,115,224,239,246,391,412,413,416,428,446,449,450,495,502,504,507,616],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/2576"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=2576"}],"version-history":[{"count":0,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/2576\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=2576"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=2576"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=2576"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}