"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.
Goodbye, CouchDB
61–70 of 150 posts
Re: Goodbye, CouchDB
#62Earlier quoted context omitted.
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.
I don't like MySQL either, but they're basically using it as a networked hash table. It's not so bad that it can't do that.
Re: Goodbye, CouchDB
#63> What are schemas even for? They just make things hard to change for no reason. This attitude right here is why the RDBMS old guard despises NoSQL. Willful ignorance should not be celebrated.
I was floored by this quote. As technical founder, one of my chief priorities operationally is ensuring that a) our systems are up and b) our data is consistent. I've dabbled in NoSQL (a la friendfeed) a bit and my head exploded when I wanted to migrate meta-schemas on multiple machines (potentially writing to the same data) with minimal concurrent alternate code paths. I need to be able to speak with 100% confidence that every object in our database is consistent and valid and without a schema on a database level this is really hard to enforce because anyone (including a bug) could accidentally throw a borked bag of properties into a key value store.
A lot of the excitement over schema-less data stores (I think) really comes down to instant DDL changes, which is why you should really just use Postgres instead of MySQL.
Re: Goodbye, CouchDB
#64Earlier quoted context omitted.
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 w…
You're welcome to peruse the mailing list thread. http://lists.basho.com/pipermail/riak-users_lists.basho.com/...
That thread shows that all of the particulars of your claims about Riak are actually false. Further it seems you didn't bother to understand how Riak can solve your problem and thus decided that it cannot.
Re: Goodbye, CouchDB
#65Earlier quoted context omitted.
You're welcome to peruse the mailing list thread. http://lists.basho.com/pipermail/riak-users_lists.basho.com/...
That thread shows that all of the particulars of your claims about Riak are actually false. Further it seems you didn't bother to understand how Riak can solve your problem and thus decided that it cannot.
Verbatim, from the mailing list:
"If large-scale mapreduce (more than a few hundred thousand keys) is important, or listing keys is critical, you might consider HBase."
"Riak can also collapse in horrible ways when asked to list huge numbers of keys. Some people say it just gets slow on their large installations. We've actually seen it hang the cluster altogether. Try it and find out!"
Re: Goodbye, CouchDB
#66Earlier quoted context omitted.
A "fantastic" company and a crappy database. Sounds like a questionable set of priorities.
I don't like MySQL either, but they're basically using it as a networked hash table. It's not so bad that it can't do that .
This is InnoDB's sweet spot really -- a mostly read-only in memory data set where the lookups are done primarily by PK. MySQL 5.5 can scale this kind of workload to 32 cores.
I'm pretty sure given this kind of workload MySQL will outperform PostgreSQL handily.
Re: Goodbye, CouchDB
#67"No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason."
While they do mention the need to enforce constraints on your data, it's comments like these that make me wish all application developers were required to work as a DBA for a few months.
A properly normalized and "constrained" database prevents data loss from stupid mistakes.
Re: Goodbye, CouchDB
#68This article explains why I am using MySQL as the DB backend for a site I am currently building. It also explains why I am not using Node.js. New technologies are fun to play with, but they get decidedly less fun when your site starts getting traffic and you realize that your new toy isn't ready for prime time.
It does nothing of the sort, node.js is ready for the prime time, just have a look at transloadit, voxer, yammer etc etc. Don't confuse the tool not being ready, with you not being ready to use the tool. Equally, there are plenty of people are making couchdb work for them.
Re: Goodbye, CouchDB
#69If you want to run a NoSQL layer over a relational DB, check out something like Goatfish:
https://github.com/stochastic-technologies/goatfish
Not production code by any stretch, but an interesting concept, and I'd be more inclined to work on it if more people were using it.
Re: Goodbye, CouchDB
#70> What are schemas even for? They just make things hard to change for no reason. This attitude right here is why the RDBMS old guard despises NoSQL. Willful ignorance should not be celebrated.
"If you don't like it, it must be because you haven't taken the time to understand it" is cognitive poison. What evidence will convince you that someone has understood well enough to judge that something doesn't make sense?
I've spent many years using schemas, and I know well how they work and what they achieve. I'm saying they're a lousy tradeoff.