4 ms·
1) Not trivial at all. As documented in a rather broad range of papers and whatnot. You're almost certainly oversimplifying the problem. 2) For gigantic DBs th
by remon 13y ago
1) Not trivial at all. As documented in a rather broad range of papers and whatnot. You're almost certainly oversimplifying the problem.
2) For gigantic DBs the preallocation overhead is almost non-existent.
3) Fair enough.
Your last point is, again, is not fact. It's not slower but on average measurably faster than most commonly used RDBMs with equal "tuning" efforts if utilized for the same task. I can't help but feel you're not entirely objective here ;)
- lucian1900 13y ago1) I don't think I am. The problem of (structural) subtyping is well known and researched and applying it to a database would not break new ground either. 2) The preallocation overhead is not what is the problem. The files are simply extremely large for the amount of data in them. There has been plenty of measurement and I have done some of my own. With unacknowledged writes it's quite fast, but no other database client I know of does that because it's stupid. With the highest durability and safety mode it's slower than at least Postgres and Mongo still doesn't have transactions or generic indexes.
- jeltz 13y agoPostgreSQL and MySQL both support compression of data, so even if you do not solve the duplicated key problem you still can reduce disk usage. The only benchmarks where I have seen MongoDB winning have been those where MongoDB was configured with different consistency requirements than MySQL and PostgreSQL. My suspicion is the MongoDB is slowest but I have never seen any high quality benchmarks.