101–110 of 123 posts
Earlier quoted context omitted.
>I think Node is the hot shit right now, and Rails is starting to get into the hate-period. I think you're about two years behind. Node is starting its hate-period. Rails got it a year or two ago.
What's the hot shit right now then, if not Node?
Hell yeah. From what I've seen of MongoDB I'm not impressed at all. In some carefully controlled cases, performance would be acceptable, but change anything at all (even the order that data is inserted) and it just sucks. For one particular application, the performance difference between MySQL and Mongo was like the difference between the Space Shuttle and a Chevy Sonic.
Earlier quoted context omitted.
Give PostgreSQL a shot if you're still considering databases.
I love Postgres, but I'm building something for OSS use and most unzip-and-deploy devs don't know how to set up Postgres. Any additional information that you might be able to give me that might convince me?
The perceived "ease" at which MySQL is available, thus a lack of actual understanding about how to work with an RDBMS, is why MySQL is so widespread yet such a maligned platform.
While some of the author's criticisms are valid, some of them are completely wrong: > Having no option to perform an operation comparable to UPDATE table SET foo=bar WHERE.... What? db.collection.update does exactly this. See: http://www.mongodb.org/display/DOCS/Updating#Updating-update... MongoDB fit a nice niche for a read heavy mid-scalability db solution. Every DB has it's niche. Trying to use it outside of what…
Hell yeah. From what I've seen of MongoDB I'm not impressed at all. In some carefully controlled cases, performance would be acceptable, but change anything at all (even the order that data is inserted) and it just sucks. For one particular application, the performance difference between MySQL and Mongo was like the difference between the Space Shuttle and a Chevy Sonic.
But performance is just one of many aspects of a database. Relational databases are a nightmare to develop for when you have a fluid object model.
create table whatever_attribute ( whatever_id integer primary key, name varchar(255), value text )
if you never need a special index you can just stick new attributes onto "whatever" and never recompile
Earlier quoted context omitted.
But performance is just one of many aspects of a database. Relational databases are a nightmare to develop for when you have a fluid object model.
It's never been a problem for me create table whatever_attribute ( whatever_id integer primary key, name varchar(255), value text ) if you never need a special index you can just stick new attributes onto "whatever" and never recompile
You need to use indexing unless your app is a toy.
Earlier quoted context omitted.
IIRC We've had several "Goodbye CouchDB" articles in the past few weeks too. What's the under/over on the inevitable "Goodbye Riak" wave?
Perhaps soon, but one thing that has always struck me about Basho (and maybe why Riak isn't as well-known as the other NoSQL DBs) is that they don't have a huge hype machine. They've always been more interested in fixing the problems with their DB and cultivating a community that understands the benefits/detriments of their database than blasting out "HEY EVERY1 SHOULD USE RIAK!!!" everywhere. Their site is very spec…
Hell yeah. From what I've seen of MongoDB I'm not impressed at all. In some carefully controlled cases, performance would be acceptable, but change anything at all (even the order that data is inserted) and it just sucks. For one particular application, the performance difference between MySQL and Mongo was like the difference between the Space Shuttle and a Chevy Sonic.
The simplest way to get really good performance for multi-row queries (even if you fall out of cache) is to physically order your data in query-order. (that is, if you are going to ask for the most recent 100 blog comments, order the comments by (blog-post-id, reverse comment-date).
MySQL -Innodb makes this really easy (your data is physically ordered by primary key). In MongoDB it's not possible.
Here is a more elaborate explanation...
MySQL-Innodb stores record data in primary-key order (it puts the data right into the b-tree). This means that if you want to access 100+ records in primary-key order, it's pretty darn efficient. Even if it's out of cache, it could be just one or two disk seeks (depending on how many records fit in a block)
MongoDB stores record data in a heap-table in a semi-random order based on insertion and freespace, with each document receiving a "doc id". You can make an index on whatever you want, but when Mongo fetches multiple records, it cross-references every index entry with the doc_id. If your data is out of cache, this means a seek for _every single document_. AFAIK, as of 2012, there is no way around this, because there is no way to get mongodb to store the document data directly in the b-tree. This is a big part of why Mongo is super-slow if you fall out of cache.
HOWEVER, there are some other systems that also have this problem, including some ORMs that sit ontop of MySQL. Ruby-on-Rails forces you to use an auto_increment primary key for every record -- which means even if you use MySQL, you are forcing your data to be in a semi-random insertion order. Django does this as well. If you want to efficiently fetch a bunch of records (like 100 comments on a blog post), then you want them to be in primary key order.
In the SQL world, Oracle, MS-SQL, and Postgres also normally use a form of heap-table for records... This allows records to have a physical "ROWID" which can be used to directly look them up (it's a physical block address with an O(1) lookup). However, it also means they are in semi-random order. The ROWID was an important join and foreign-key optimization back in the days of nightly SQL jobs on machines with very little RAM. Today, it's not a good optimization. B-tree indirect blocks are always in RAM, so direct ROWID lookups have little benefit over b-trees, and the huge drawback of no natural primary key ordering. One can workaround this problem with fully-covered-indicies, table-in-index, and key-clustering -- all of which have their own frustrating tradeoffs.
Does primary-key ordering have downsides? References to records are bigger (They have to contain the full primary key), there is no guaranteed stable way to reference a record (for foreign key constraints), and if you change fields in the primary key, the entire record must be moved. In the "old days" there was another big drawback, b-tree O(log-n) lookups are much slower than ROWID O(1) lookups.. Today this is not an issue because all b-tree indirect nodes fit in RAM always.
Bottom line, if you want the easiest way to order data properly, use MySQL-Innodb, and choose your primary key wisely. If you are using another storage system, study up on how you can control physical ordering becuase every system is different.
We dumped Mongo for a lot of the same reasons listed in the article. Their python driver isn't great either.
Earlier quoted context omitted.
I fully agree here. A couple of years ago, when I went on interviews at startups, they were all using nosql db's and were proud of it. More recently, I've been interviewing at startups that are now bigger, need to mine the data that they've collected over the last few years, and now are migrating off of nosql db's to rdbms' (or creating strange amalgams of the 2). I did see this coming, but it was very hard to make t…
The reality is that developers are maturing in their understanding of different technologies and they are learning how to apply them in correct use cases. There continues to remain a "golden hammer" syndrome where white horses and unicorns run free, but it doesn't exist. Instead, the vision of "NoSQL" was to tell developers that they did not have to use relational data for everything, but could, instead, use the righ…
Are you saying that one of the way he is using MongoDB is incorrect? If yes, what point did he say reflects that?
His rants seems quite specific.