Care to define the goals? Apparently it's not about scaling. It's not about SQL, because there's no reason you can't support a SQL-style query language.
So I do seriously want to know what's left... We're always on the lookout for the next feature to add ;-)
To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema. Some data work better in a relational model and others work better in a document model. The idea of one ending the other seems preposterous to me.
> To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema.
The whole point of that "impedance" in the relational model is to for people to think about their data and describe it in a program-independent way: years of experience in the field is what led to its development and what contributes to its continued relevance. Saying that's a problem with the relational model is like saying that design patterns are flawed because they describe commonly used OO designs.
> To me, it's about reducing the impedance mismatch between your data model and the implementation of that model in the database schema.
I'm not sure what sort of impedance mismatch could exist between a program and a relational model but not between a program and a document model. The latter is trivially implementable in terms of the former.
Take a look at my comment again, I think you think I'm saying something I didn't.
The whole point of that "impedance" in the relational model is to for people to think about their data and describe it in a program-independent way ....
The relational model is hardly the only way to reason about data in a program-independent way.
... years of experience in the field is what led to its development and what contributes to its continued relevance.
I agree, never said otherwise.
Saying that's a problem with the relational model is like saying that design patterns are flawed because they describe commonly used OO designs.
I didn't say there's a problem with the relational model.
I'm not sure what sort of impedance mismatch could exist between a program and a relational model ...
I never said the word "program," you did. I said "data model." You're conflating the data model with the program code (or maybe you think I am, can't really tell). They are not the same thing.
All I said is that there are some domains for which relational models make sense and there are others for which document-oriented (or other "NoSQL") models make sense.
Cool answer - thanks. I guess some of this is about better ORMs, some of this is the schemaless idea, and probably the real answer is a combination of both.
I worry that object databases were the last attempt to solve the impedance mismatch...
Of course, this is a very old idea (predating the invention of relational databases, even) -- it just gets reinvented every decade or so, with a fresh helping of media hype.
I've seen so many market changes in my career and, yet, I still write code in a text editor with a terminal window on its side. All of them under a nice windowing environment.
In my opinion, one of the goals of the AltDB movement is building software that fits in different parts of the CAP Theorem triangle. While relational databases are REALLY good (usually) at providing consistent data, things start to fall apart when you setup geographical replication. In the past, consistency seemed to be the most important thing for all applications. While it still is desirable and important, some users are beginning to prefer availability and partition tolerance over consistency.
I am reminded of the Judean People's Front from Life of Brian. Henceforth we shall call you AltDB, and we shall add geographical replication to your list of demands :-)
More seriously, we'll see what we can do meet that list with our tech!
I don't know if this is a goal of the NoSQL movement in general, but I use Redis rather than something like MySQL because I need speed. We're using Redis to route web requests, and we can't add 50+ ms onto every request on top of the >300 ms request time we have already from the application itself.
If any DB is taking 50ms to reply (SQL, NoSQL, even MS Access!), something is seriously wrong. If you're using Rails, I'd fire up NewRelic or something like that and check out what on earth is going on.
Of course, 300ms is also way too long. Do you mean under stress-testing, with request queuing? 300ms is a mind-boggling quantity of CPU cycles...
If we were to use MySQL, we'd be using multiple complex queries to get the job done. From what I've seen in New Relic on Heroku, queries have generally taken about 40-50 total for one request on PostgreSQL.
We're building a general purpose method of running Ruby applications, so 300 ms is certainly a possible request time (including database, processing things, and rendering a view) for some applications that we may be running.
I think your performance here stems more from configuration than from MySQL vs Redis. If you're using Redis in-memory, if you dedicate the same amount of memory to your database, you should get roughly comparable performance between MySQL/PostreSQL and Redis. The under-the-hood differences if you're in memory just aren't that great, particularly because modern machines have such ridiculously powerful CPUs. Yes, it sounds like you'll have to do table join(s); yes, the joined tables need indexes; yes, you have the SQL parsing overhead; yes, it's a B-tree rather than hash-based indexing. But I'd be very surprised if you ended up with the order-of-magnitude differences you're suggesting.
One of the things we're working on with FathomDB is ways to identify slow queries and help figure out what to do about them. If you're game, you can contact me with the queries and the table structure you were using in SQL and I'll try to figure out what's going on!
BTW AltDB is my term for the NoSQL movement. It implies much less.