4 ms·

You have a smallish number of documents where some particular field of fixed size gets overwritten a lot, the old values are uninteresting, and it wouldn't real

You have a smallish number of documents where some particular field of fixed size gets overwritten a lot, the old values are uninteresting, and it wouldn't really be a tragedy if your data got trashed. For example, it's the player's score. You want a fixed-size, rolling backlog of time series data such as logs.

twic 13y ago
Is it better than a relational database for that?
- yummyfajitas 13y ago
  Postgres update performance is pretty bad. When running a big data migration, it's generally faster to copy the old table to a new temporary table and rename the temp table to the old table than it is to run an update.
  - ams6110 13y ago
    This is the case with all RDMBS I've used.
    - pkolaczk 13y ago
      RDBMSes need to check for primary key violations, hence read before write. Random access is slow. The fastest you could do is "no read-before-write, append-only writes, compact later" (Cassandra way).
- JulianMorrison 13y ago
  Most RDBMSs will, if you rewrite a field, write a fresh row and tombstone the old one, and clear it down in the next compaction. This is what MVCC means in practise: that the old version doesn't disappear while the new is being written. MongoDB by contrast will simply mmap that block of file, overwrite the contents, and fsync. Yes, this has obvious downsides.
  - twic 13y ago
    I won't dispute the empirical finding that MongoDB and friends are faster at this than RDBMSs. However, i'm not sure why this should be the case. You mention the complexity of updating a row in MVCC; sure, but all the database has to do before reporting success to the user is to write its intent to make this change to the transaction log (WAL in PostgreSQL, redo log in Oracle). The actual changes to the data files can be written back later on. The transaction log is a single stream being continuously written to disk, so that should be very fast. MongoDB, on the other hand, is making scattered writes across its mmapped data files, which should be much slower. Except that of course it's probably doing this on a journalled filesystem, which is using exactly the same mechanism as the RDBMSs to provide fast, safe updates. I'd be really interested to see how a simple update to a single field translates into actual writes to disk for PostgreSQL and MongoDB. If only i knew how to use strace!
brandonbloom 13y ago
Isn't a file system a better solution for both of those use cases?
- JulianMorrison 13y ago
  It might well be. MongoDB is basically ORM for "mmap a file".
chris_wot 13y ago
So it's useful for a very limited set of use cases, and you must never be concerned that your data will be lost. I can't believe I'm reading this!

twic 13y ago

Is it better than a relational database for that?

yummyfajitas 13y ago
Postgres update performance is pretty bad. When running a big data migration, it's generally faster to copy the old table to a new temporary table and rename the temp table to the old table than it is to run an update.
- ams6110 13y ago
  This is the case with all RDMBS I've used.
  - pkolaczk 13y ago
    RDBMSes need to check for primary key violations, hence read before write. Random access is slow. The fastest you could do is "no read-before-write, append-only writes, compact later" (Cassandra way).
JulianMorrison 13y ago
Most RDBMSs will, if you rewrite a field, write a fresh row and tombstone the old one, and clear it down in the next compaction. This is what MVCC means in practise: that the old version doesn't disappear while the new is being written. MongoDB by contrast will simply mmap that block of file, overwrite the contents, and fsync. Yes, this has obvious downsides.
- twic 13y ago
  I won't dispute the empirical finding that MongoDB and friends are faster at this than RDBMSs. However, i'm not sure why this should be the case. You mention the complexity of updating a row in MVCC; sure, but all the database has to do before reporting success to the user is to write its intent to make this change to the transaction log (WAL in PostgreSQL, redo log in Oracle). The actual changes to the data files can be written back later on. The transaction log is a single stream being continuously written to disk, so that should be very fast. MongoDB, on the other hand, is making scattered writes across its mmapped data files, which should be much slower. Except that of course it's probably doing this on a journalled filesystem, which is using exactly the same mechanism as the RDBMSs to provide fast, safe updates. I'd be really interested to see how a simple update to a single field translates into actual writes to disk for PostgreSQL and MongoDB. If only i knew how to use strace!

brandonbloom 13y ago

Isn't a file system a better solution for both of those use cases?

JulianMorrison 13y ago
It might well be. MongoDB is basically ORM for "mmap a file".

chris_wot 13y ago

So it's useful for a very limited set of use cases, and you must never be concerned that your data will be lost. I can't believe I'm reading this!