Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, CouchDB

saucelabs.com

Post reply on HN
Print view View original

31–40 of 150 posts

Re: Goodbye, CouchDB

#31

Post by astrodust »

mpd wrote: post #27
nirvana wrote: post #4

They'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.

That doesn't seem like a very large number. Are you sure?

Re: Goodbye, CouchDB

#32

Post by Myrth »

asnyder wrote: post #14
sah wrote: post #7

Earlier quoted context omitted.

A number of us know MySQL fairly well, and in particular I've seen how it's used by some of the biggest internet companies. We have some postgres experience on our team as well, but it's a little more of an unknown. So experience trumped feature set in this case. One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsi…

Research?

Limitations of our universe, such as time, brain capacity and sanity?

Re: Goodbye, CouchDB

#33

Post by sah »

DennisP wrote: post #9

"constructing strings of code...which after being constructed have to be parsed for every single query?" I don't know about MySQL, but my database caches compiled queries. "Things like SQL injection attacks simply should not exist." They don't exist, if you don't construct SQL queries by concatenating strings and variables. Meanwhile, all the cool kids are talking about getting rid of procedural code in favor of decl…

"They don't exist, if you don't construct SQL queries by concatenating strings and variables."

My point is, people still do this. You never hear about REST-injection or memcached-injection attacks, even though those are possible in principle, because those protocols don't encourage this mistake the way using SQL as a database API does.

Re: Goodbye, CouchDB

#34

Post by Roboprog »

To summarize some of the other (upvoted) comments on this cringe-worthy article:

Output to any external system must be encoded to prevent fill-in-the-blank injection, if it uses a language vs a string API-only approach. Used prepared statements.

SQL is not COBOL. Sets != ISAM.

You can store arbitrary data (XML, JSON) in BLOBS/CLOBS in an RDBMS. Denormalization is frowned upon, but not forbidden.

PostgreSQL is arguably a better free / open DBMS than MySQL.

DBMS data constraints are a good thing; use them when they make sense.

Re: Goodbye, CouchDB

#35

Post by moe »

trimbo wrote: post #24
yxhuvud wrote: post #2

What really don't understand is why they chose mysql over postgresql - postgres already have hstore as a column type to store schemaless data. This includes support for indexes on the field.

Except they didn't choose mysql -- they chose Percona . Bonus of going with Percona is that in the process you get a fantastic company to back you up.

A "fantastic" company and a crappy database. Sounds like a questionable set of priorities.

Re: Goodbye, CouchDB

#36

Post by radicalbyte »

sah wrote: post #8
JohnBooty wrote: post #6

"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".

So SQL is bad because it expresses intent in a language which contains domain concepts?

What would you prefer? Fortran? Assembly?

Re: Goodbye, CouchDB

#37

Post by shadowmatter »

I wish this article had some hard numbers for availability, performance, and the size of their data as opposed to hand-waving.

Shameless plug: If you're looking to benchmark or load test CouchDB a bit, I wrote one at https://github.com/mgp/iron-cushion. Hopefully someone out there will use this to decide if CouchDB's performance meets their needs, because migrating away from any database is painful...

Re: Goodbye, CouchDB

#38

Post by sah »

scott_s wrote: post #29
AlisdairO wrote: post #21

Earlier quoted context omitted.

Very true. I'm tempted to argue that SQL's English-like syntax was a mistake, but only because I think it makes people think you don't really need to learn it. It's frustrating to see people trash something when they don't even properly understand it - a lot of the database-related blog posts I've seen make the front page of HN would be shot down if they were similarly misinformed about a language like Javascript. I'…

That was an issue I had with the post: how can "non-relational" be a good thing about CouchDB? If you have relational data, then there's an entire theory (relational algebra) behind ways to interact with it that have clearly defined semantics. I can see that one may decide they don't need that, but I don't see how it's absence can be a good thing. Being non-relational frees CouchDB to provide different kinds of capab…

You're right that I was lumping transactions and data integrity guarantees in with "relational". I was thinking about normalization, and protecting data integrity in ways that lead to joins and transactions.

Re: Goodbye, CouchDB

#39

Post by jeffdavis »

sah wrote: post #7
kanja wrote: post #3

Why did you use mysql rather than postgres? It seems like most of your complaints about mysql are solved in postgres (the query planner is much stronger) and there's some features that seems would fit your team much better

A number of us know MySQL fairly well, and in particular I've seen how it's used by some of the biggest internet companies. We have some postgres experience on our team as well, but it's a little more of an unknown. So experience trumped feature set in this case. One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsi…

"One thing I would say about postgres is that it has a lot of features. As a new user, it's hard to know which ones to use in which ways, and what the downsides might be."

Do you have some suggestions how that can be improved? Are there features that you would classify as "bloat" or that seem confusing or poorly documented?

Postgres is a very general system and has a large variety of users as a result. That means that the features tend to be very well-thought out and don't carry a lot of surprises, but it also means that it's hard to guide users toward specific usage patterns. Even among web users, a feature like LISTEN/NOTIFY might be an instrumental part of the caching infrastructure for some users, but seem like bloat to others.

Re: Goodbye, CouchDB

#40

Post by MattRogish »

rdtsc wrote: post #22
josephkern wrote: post #5

As a systems guy, I appreciate stories about developers learning that systems are complicated, and the latest and greatest technology is often not as stable or optimized as hoped. Although, I do have high hopes for Key:Value store data repositories. TANSTAAFL.

However as a developer guy I am glad they picked a technology that let them make quick prototyping progress and started shipping a product. Remember only successful companies have to worry about scaling. Un(/not yet)-successful company have to worry about shipping first, then scaling. So perhaps Saucelabs reached that milestone, and they simply have outgrown the original technology that helped them ship. Who knows, m…

+1 for op and gp. At a previous gig, we had the opportunity of using SQLite or a raw JSON store for a mobile application we were building. Although SQL would've been the "right" way to do it, JSON implementation was basically a no-op given our JS-based framework.

It did make a few things harder later on but we were better equipped to make a change around the time we actually needed to. If we had spent a lot of time up front developing for SQLite, we'd have paid an overhead tax for years for no good reason. And possibly wouldn't have made it to the point in which we needed to make a change.

That said - our use case was incredibly narrow (read only data store, server outputs JSON anyway, etc.) and so we made a reasoned choice.

If we needed complex queries/joins, updates/deletes, incremental loading, etc. - then a JSON store would've been terrible.

Post reply on HN