Hacker News Reader

> But the query takes almost a second

I don't think the existence of a join is sufficient to slowness like this

> and when the DB is always worried about consistency and stuff so writes are kind of slow too.

Has nothing to do with relational data per se. Unless you're using foreign keys and calling that a join (which is actually fair). NoSQL stores typically do lots of work to ensure consistency and many support multi-statement transactions on top of this. Unless we're talking about only keeping data in memory but you can make a relational db do that.

> If you need some related data, you make another query based on the key stored in the first piece of data. Each query takes a fraction of a second, together they don't take as long as the full join query

That is exactly how a join is executed under the hood. Loop over rows in one table, look up a value in another table. However, the db won't force you to join based on a key. If all you're doing is looking up unique keys there's no way multiple calls will be faster unless all the data won't fit on one machine.

Down for me too, so I'm only responding to your comment.

>[using a DB join means that] the query takes almost a second

This is, at best, an overgeneralization and at worst outright FUD. I don't know what sort of data or database engine you're working with that might make this true, but it's definitely not a requirement that it be this way. The RDBMS backing my site is trivially able to return all needed data in fractions of a second for most cases regardless of the presence of joins. If it can't, that generally just means that I forgot to index something properly.

Moving past this, going with a simple key/value store instead of an RDBMS means giving up at least three of the ACID properties in favor of nothing more than a speed gain.

- Atomic: No transactions. If the system dies between two related commits...oops, your dataset is inconsistent.

- Isolated: No transactions, again. You cannot make guarantees about what information an object will have -- e.g., you cannot say "Every user will always have at least one entry in Pages, because we automatically create a non-deletable Home page for every user at signup." If you rely on that, you will eventually hit a user who is halfway through the signup process and has a user entry but no Page entry.

- Durable. If your backing store has not actually flushed your write to disk and the system crashes...oops, you're hosed. I hope you weren't storing your Accounts Receivable data in that NoDB.

>Moving past this, going with a simple key/value store instead of an RDBMS means giving up at least three of the ACID properties in favor of nothing more than a speed gain.

This is, at best, an overgeneralization and at worst outright FUD.

>The CouchDB file layout and commitment system features all Atomic Consistent Isolated Durable (ACID) properties.

http://couchdb.apache.org/docs/overview.html (to pick a single counterexample)

I have no idea what anti-NoSQL things you've been reading, but they've been wildly incorrect. And as to guarantees of what info an object has, schema-based NoSQL databases exist, just as schema-free RDBMS databases exist. Triggers frequently exist - you can automatically create a non-deletable (permissions exist too) home page for every user at signup.

You're entirely correct that DB joins taking a long time is similarly wildly incorrect, though I'm not certain that's what they're claiming. It sounds to me more like they're saying pulling all related info on primary object X in your system takes a long time in a highly-normalized RDBMS compared to a document-based DB where it's all in the same location. Which is frequently correct.

I agree that for most requirements I have, an SQL database can deliver the data I need, quickly, unless I am missing an index or using an ORM tool.

For Atomic, put all the related stuff in a document and commit it.

Your issue with home pages has a couple of obvious solutions:

1. Deal with the fact that some users don't have a home page and consider them not yet signed up.

2. Create the home page first, before you create the user

3. Put the home page in the user document, or put the user document in the home page document.

Going with a NonSQL store gives you more than speed, it gives you simplicity and flexibility along some dimensions.

We run our SQL database with replication and the replication is not synchronous. If we really loose our primary (bomb blast), the replica can be out of date and we can loose data. We are a very large company, and all the databases are configured like this. Many NoSQL solutions (Google) are configured more conservatively.

> The site is down for me.

http://pastebin.com/Dmpyyv8Q

The problem is that updates becomes a monster problem if you have lots of connected records, since the same information is duplicated in many places over your data store. Failed updates can easily lead to inconsistencies.

It depends on the data of course, but sometimes it might be easier to just create a new entry rather than update an old one :)