4 ms·
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
by dstorrs 16y ago
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.
- Groxx 16y ago>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 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.
- artsrc 16y agoI 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.