12

Disclaimer: This is a broad question, so it could be moved to a different source (if the admins find it appropriate).

All the cool kids seem to be dropping relational databases in favor of their NoSQL counterparts. Everyone will have their reasons, from scaling issues to simply being on the bleeding edge of tech. And, I am not here to question their motives.

However, what I am interested in is whether any NoSQL transitions ever validated the performance (maintenance) gains over a traditional RDBMS when relationships were dropped. Why would we want to use a RDBMS when the core reason it exists is dropped? A few reasons come to mind

  1. 30+ years of academic and work research in developing these systems
  2. A well-known language in Structured Query Language (SQL).
  3. Stable and mature ORM support across technologies (Hibernate, ActiveRecord)

Clearly, in the modern world where horizontal scaling is important, there is a need to make sure that shards are fault tolerant, updated within the time intervals required by the app, etc. However, those needs shouldn't necessarily be the responsibility of a system that stores data (case in point: ZooKeeper).

Also, I acknowledge that research should be dedicated to NoSQL and that time spent in this arena will clearly lead to better more internet worthy technologies. However, a comparison of sorts between NoSQL and traditional RDBMS offerings (minus relationships) would be useful in making business decisions.

UPDATE 1: When I refer to NoSQL databases, I am talking about data stores that may not require fixed table schemas and usually avoid join operations. Hence, the emphasis in the question on dropping the relationships in a traditional SQL RDBMS

Salman Paracha
  • 1,697
  • 2
  • 16
  • 27
  • 8
    The main reason I still use an RDBMS is quite simple, really: backups and restorations! No NoSQL database comes even close to PostgreSQL or Oracle for solidity. And also, most people are very bad at understanding the relational model (it defines a _relation between columns in a row_, not relations between tables) and the normal model, which means RDBMSes have a poor press on the performance front -- but it's the developers' fault, not the RDBMSes. Today, I see no reason for using NoSQL, except for text/tree-based searches which _are_ more efficient with those. – fge Jan 01 '12 at 19:44

5 Answers5

15

I don't find that inter-table relationships are the main limiter for scalability. I use queries with joins regularly and get good scalability if indexes are defined well.

The greater limiter for scalability is the cost of synchronous I/O. The requirements of consistency and durability -- that the DBMS actually and reliably saves data when it tells you it saved data -- is expensive.

Several NoSQL products that are currently in vogue achieve great performance by weakening their consistency and durability guarantees in their default configuration. There are many reports of CouchDB or MongoDB losing data.

There are ways you can configure those NoSQL products to be more strict about durability, but then you sacrifice their impressive performance numbers.

Likewise, you can make an SQL database achieve high performance like the NoSQL products, by disabling the default features that ensure data safety. See RunningWithScissorsDB.

PS: If you think document-oriented databases are "cutting edge", I invite you to read about MUMPS. Everything old is new again. :-)

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • 1
    "and get good scalability if indexes are defined well" you are not talking about scalability. you are talking about performance. scalability is adding 10x the servers and getting near 10x out of it in terms of performance. – usr Jan 02 '12 at 20:45
  • 2
    @usr: Scalability can also be when performance does not degrade as your load increases. Using indexes effectively can help this. – Bill Karwin Jan 02 '12 at 20:54
  • @Bill Karwin: do you have any links/sources about the "NoSQL losing data" thing? Weak consistency is one thing and not a problem if you know what you are doing.... but losing data definitely is a problem. Why should a NoSQL-db lose data? – alapeno Sep 21 '12 at 23:37
4

There seem to be at least two misconceptions that might be implied by this question. Firstly "NoSQL" does not mean "non-relational", it just means something other than SQL. So a RDBMS could be a NoSQL DBMS too.

Secondly, an RDBMS has nothing much to do with relationships* per se. Relationships are not part of the relational model and they can exist in non-relational databases as well (including No-SQL ones). The "relational" part of RDBMS refers specifically to relations - i.e. the data structure more commonly called a "table" (and never called a "relationship"). The question seems to be mixing up those two important and very different things: relation and relationship.

Since the existence of or absence of relationships has nothing to do with whether a database is relational or not, I'm not sure what the question is really asking. If I've misunderstood something then maybe you could clarify the question a bit.

*A relationship is an "association among things" - or sometimes a database constraint that enforces a rule about such associations.

nvogel
  • 24,981
  • 1
  • 44
  • 82
  • You are correct, I used those two terms interchangeably, while I shouldn't have. I was referring to the relationships (as in foreign keys) which is the normal cause of a slow down, especially when considering updates, deletions and insertions. Being relational as you described, is a DBMS feature, which inherently doesn't pose a scaling issue. I will re-think the wording of the question and the passage accordingly. Clear now? – Salman Paracha Jan 02 '12 at 00:08
  • 2
    @Salman, Re foreign keys (i.e. RI constraints): 1. A relational database without a RI constraint is still a relational database. 2. A No SQL database with a RI constraint is still a No SQL database. So RI is entirely orthogonal to the question of RBDMS / NoSQL. The answer to your question is therefore no. RI is irrelevant. – nvogel Jan 02 '12 at 00:14
  • I didn't mean to imply that a relational db without RI constraints isn't relational. What I want to know is that the slowdowns experienced with a RDBMS are attributed to the "relationships" that are externalized/demanded as a result of normalization. Therefore, if we were to drop the "relationships" (hence dropping normalization) from an RDBMS would it scale as well (or better) than its NoSQL counterparts. And, if relationships can exist in NoSQL databases, then how do they afford us better performance? – Salman Paracha Jan 02 '12 at 01:31
  • 3
    NoSQL is a marketing term, not a technical term. So it has no meaning anyway. :-) – Bill Karwin Jan 02 '12 at 20:01
3

SQL generally has scaling issues because the guarantees it gives are not only for one "row" at a time. They are spanning across rows. This makes the load hard to distribute. Here are examples of RDBMS's giving guarantees spanning more than one record:

  1. Indexes: Atomic update of two underlying tables at once (the index internally is a table)
  2. Foreign keys
  3. Materialized views

The problem with those features is that they don't lend themselves well to partitioning. In all 3 cases, a particular write might span multiple partitions causing scaling issues.

NoSQL generally "solves" this by just disallowing those features ;-)

The next issue holding back SQL is that it provides ACID semantics by default. This is not inherent in the relational model - it is an implementation detail.

So if you turn off those features that are hard to distribute/partition and disable ACID you get NoSQL performance. In fact look at how HandlerSocket does this with MySQL. It has NoSQL speeds although it runs on InnoDB and provides a standard full-featured SQL-Interface (it really is just a featureless bypass on a standard MySQL server).

No magic in NoSQL, just less features. Which is ok. It is a different trade-off.

usr
  • 168,620
  • 35
  • 240
  • 369
  • Actually, none of those features are exclusive to relational DBs. In fact, they all existed before relational DBs were invented. – Hot Licks Jan 01 '12 at 21:57
  • Just trying to show typical features relevant to the discussion. They might not be unique to Relational but nevertheless they tend to be typical for it. – usr Jan 01 '12 at 22:37
  • The only thing that's really tied to "relational" is limitations -- things you can't do (such as ask for "next") without breaking the relational paradigm. SQL is, after all, the COBOL of database -- designed so that managers can write their own queries. (And, of course, it works as well for SQL as it did for COBOL.) – Hot Licks Jan 01 '12 at 23:32
  • 4
    @HotLicks: The main thing about the relational model is data integrity (and consistency and durability). The "ask for next" is yes, a break from the relational model (despite that SQL and most DBMS break too from the relational model and are pretty capable of showing next and previous). The relational model does not need the concept of "next row" to provide what it advertises. The next number after 3 is 4 but "the next colour after yellow" has no meaning. – ypercubeᵀᴹ Jan 02 '12 at 20:36
  • But what is the next after 4789328612903? And data integrity existed before SQL. – Hot Licks Jan 02 '12 at 21:14
0

Relationships is not a good criteria to compare performance between RDBMS and NoSQL.

NoSQL has become very popular due to many factors

  1. Horizontal scalability.
  2. Support for unstructured & semi-structured data
  3. Read/Write throughput
  4. Cheap hardware cost etc.

Have a look at RDBMS Overheads

RDBMS have challenges due to consistency requirements.

To support transactions, RDBMS has to support ACID properties : Atomicity, Consistency, Isolation, Durability). This can be achieved with

Logging: Assembling log records and tracking down all changes in database structures slows performance. Logging may not be necessary if recoverability is not a requirement or if recoverability is provided through other means (e.g., other sites on the network).

Locking: Traditional two-phase locking poses a sizeable overhead since all accesses to database structures are governed by a separate entity, the Lock Manager.

Latching: In a multi-threaded database, many data structures have to be latched before they can be accessed. Removing this feature and going to a single-threaded approach has a noticeable performance impact.

Buffer management: A main memory database system does not need to access pages through a buffer pool, eliminating a level of indirection on every record access.

In Summary, RDBMS is not scaling due to above overheads, which are necessary to support ACID transactions.Lack of relationships does not improve performance of RDBMS system.

Ravindra babu
  • 37,698
  • 11
  • 250
  • 211
0

I think the pros/cons of using RDBMS or NoSQL really depends on the data and how you plan to use it. It is my understanding that transactions are actually represented quite well with a relational DB. My experience with NoSql is with Infinite Graph & Neo4J. Forensics is a good use case for NoSQL, each person is an node/vertex and an edge can represent different types of communication (email, phone, face to face meeting, carrier pigeon, etc...). You can then take a suspect/vertex and traverse the graph with specific criteria to find how two seemingly unconnected individuals are actually connected (probably with more efficiency than a traditional relational DB). Social graph data is another good example, every user is a node/vertex and the relationship(friend) is an edge connecting two nodes. In short, is your data best represented & retrieved with tables or nodes/edges.

Corey DonCorsean Ricketts
  • 209
  • 3
  • 5
  • I think that's a fair answer, but the question didn't really want to pit NoSQL against a traditional RDBMS. The goal is to simply understand, whether the social graph as you mentioned could be maintained in a RDBMS (without sacrificing scale), when you keep the structure fairly flat, like that of a NoSQL database (as defined in the question above). – Salman Paracha Jan 04 '12 at 19:38