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.
[deleted]
Goodbye, CouchDB
11–20 of 150 posts
Re: Goodbye, CouchDB
#12I see this a lot. Devs decide to stop using something because they don't like the interface it presents to developers, but fail to seriously (seriously, seriously) consider how its replacement will run in reality. That is, they like the idea of using something new, but are not prepared for the reality of actually using it. (In fairness to these guys, it seems more like the reality of their situation changed rather than just being short-sighted.)
So, I get the squicks now whenever I see someone talking about how lame and broken an old, mature technology is. The way this article shits on schemas, for example -- if a coworker said that to me in real life I'd get a sinking feeling in the pit of my stomach. It's a short hop from that type of thing into the land of the straight-up cowboy coder.
Re: Goodbye, CouchDB
#13They'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…
Does riak support range queries?
Re: Goodbye, CouchDB
#14Why 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…
Research?
Re: Goodbye, CouchDB
#15They'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…
Does riak support range queries?
It does on secondary indexes http://wiki.basho.com/Secondary-Indexes.html
Re: Goodbye, CouchDB
#16"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".
How is that different from
for foo in bar
Re: Goodbye, CouchDB
#17They'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…
CouchDB has some features that other databases don't have: a continuous changes feed, REST interface, master-to-master replication, a web interface to the data and management (Futon). We need those features (Yes including Futon. It is a feature because it lets us quickly prototype and debug. It makes a black box that you drop your data in transparent).
But we not using to for large datasets. We are using it mostly for configuration, and setup. There is a custom clustering setup built in its m-m replication and changes feeds.
But I agree that for IO scaling and large data sets Riak would be a top choice. But there are other contenders to look at as well: Cassandra, BigCouch and the upcoming Couchbase Server 2.0
Re: Goodbye, CouchDB
#18What 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?
Re: Goodbye, CouchDB
#19How do you go about searching the DB if everything is stored as a JSON object? Are you using an index like solr/sphinx instead of doing any searches directly in mysql?
Re: Goodbye, CouchDB
#20What 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.
probably because as they stated they are familar with MySQL. After getting hurt trying out a new technology to them it makes sense they go back to something they know. Will probably lead to more uptime which is what they want.