So, the TL;DR version of this is: we stopped using CouchDB because it sucked, but we took all the things that made it great, and shoe-horned them in to MySQL, while negating using anything that an RDBMS is designed for, like joins...
Goodbye, CouchDB
41–50 of 150 posts
Re: Goodbye, CouchDB
#42Earlier quoted context omitted.
The connection I see is the attempt to make the syntax English-like. Expressions like "SELECT * FROM users" remind me of COBOL's "ADD X TO Y".
So SQL is bad because it expresses intent in a language which contains domain concepts? What would you prefer? Fortran? Assembly?
I didn't say anything about domain-specificity.
My primary point was just that SQL is old, and I think the reason it is the way it is has more to do with history and compatibility than what we'd want it to look like if we started from scratch today.
SQL is still around because it was successful. And there are reasons to value compatibility, and to avoid changing things for no reason. But my personal experience using a database without using SQL was pleasant, and I'm anxious to see the world move on to something new and improved.
Re: Goodbye, CouchDB
#43Earlier quoted context omitted.
I investigated using Riak for dealing with our metrics a few months ago, but with the data sizes we are dealing with, even the Riak people told us that Hadoop was likely a better solution. Once you are dealing with more than 500k keys or so, Riak starts to fall over. EDIT: The 500k key limit pertains to mapreduce jobs, not the overall data size.
That doesn't seem like a very large number. Are you sure?
Yes. I should clarify that I meant 500k keys used in a single m/r job. We needed to be able to run m/r over roughly 200 million keys at the time.
Re: Goodbye, CouchDB
#44"No SQL. It’s 2012, and most queries are run from code rather than by a human sitting at a console. Why are we still querying our databases by constructing strings of code in a language most closely related to freaking COBOL, which after being constructed have to be parsed for every single query? SQL in its natural habitat" COBOL? Really? I don't see the COBOL connection at all. SQL is more closely related to relatio…
The connection I see is the attempt to make the syntax English-like. Expressions like "SELECT * FROM users" remind me of COBOL's "ADD X TO Y".
I still don't see the similarity. Just about any modern language is full of English keywords - for, while, unless, function, etc.
Unlike COBOL (which I admit to not being very familiar with) SQL uses standard mathematical symbols as operators whenever possible... + instead of "ADD" etc.
Re: Goodbye, CouchDB
#45What I really don't get is not using mongo. Would be a natural fit, and besides isn't that link to a "Don't use mongo" you posted a known hoax?
Meh. Single threaded map reduce and very hungry disk usage. Mongo isn't the silver bullet a lot of supporters sometimes project it as (not saying you are).
Also, he actually linked 2 articles, I'd never seen the first one so it may very well be a hoax or whatever. But the 2nd one has made it's rounds a few times and has stood up (IMO) to scrutiny.
Re: Goodbye, CouchDB
#46More a lesson about the pitfalls of building systems using technologies that you don't understand very well than it is anything specific to either CouchDB or MySQL.
Re: Goodbye, CouchDB
#47Earlier quoted context omitted.
So SQL is bad because it expresses intent in a language which contains domain concepts? What would you prefer? Fortran? Assembly?
I didn't say anything about domain-specificity. My primary point was just that SQL is old, and I think the reason it is the way it is has more to do with history and compatibility than what we'd want it to look like if we started from scratch today. SQL is still around because it was successful. And there are reasons to value compatibility, and to avoid changing things for no reason. But my personal experience using…
There are a lot of things I like about the query interfaces of PetaPoco, ActiveRecord, etc. For simple CRUD operations, they're much prettier and more concise than than embedded SQL - Person.find(123) is a lot nicer than "person = db('select * from person where id=123')"
But beyond very simple cases I feel like non-SQL query interfaces very quickly become terrible, clumsy, leaky abstractions.
I usually try to have the best of both worlds - I create a SQL view/function/sproc containing my big gross gnarly joins, and then query it in a pretty way via the ORM.
Re: Goodbye, CouchDB
#48They're doing what works for them and good for them for that. But...I think a LOT of people are really missing out by passing over Riak. Many of the issues they found with CouchDB have been resolved with Riak. I think the sync API for CouchDB is really cool, but Riak has the auto-sharding thing down cold. Riak runs map reduce queries across multiple nodes, so performance and capability can grow as you add nodes. Couc…
I investigated using Riak for dealing with our metrics a few months ago, but with the data sizes we are dealing with, even the Riak people told us that Hadoop was likely a better solution. Once you are dealing with more than 500k keys or so, Riak starts to fall over. EDIT: The 500k key limit pertains to mapreduce jobs, not the overall data size.
I think your statement is both out of date and quite broad. Plus you imply that a database would be limited to 500k keys which is silly, when you really mean a map-reduce job. And further, are you really doing MR over your entire dataset, all the time, or would key filtering, ranges or secondary indexes be a better fit? Its easy to do M/R in Riak over only the correct amount of data.
Hadoop may have been better for what you are doing, and logging metrics is a particular use case where a specialized database is most appropriate.
But it is incorrect to imply that Riak falls over at any specific key limit. This is simply untrue. With Riak you can always add more nodes if you need more capacity, and Map Reduce is done in a distributed fashion so adding more nodes adds map reduce capacity. Its not perfect but it is not brittle.
Re: Goodbye, CouchDB
#49Shrug, I never bothered to say hello.
Re: Goodbye, CouchDB
#50More a lesson about the pitfalls of building systems using technologies that you don't understand very well than it is anything specific to either CouchDB or MySQL.
More a lesson that requirements change overtime.