> MongoDBs awful memory mapped simple b-tree data storage method
You realise that they are using default kernel implementation? Awful indeed. :)
If you are so anti-MongoDB, would you care to offer an alternative? It must support:
- document-like storage (I already have schema on application layer),
- simple use / administration,
- hot backup,
- single node operation.
While this list is mostly outlining why MongoDB is a great DB for my current use case, I am also genuinly interested in better solutions (for that case). So, fire away... :)
Let's see if I can make your day with a shameless plug.
First of all, using the kernel's paging algorithm for a database is awful. It has way less information about your access patterns than the database, so it's going to make a lot of bad decisions, and a bunch of MongoDB's problems with fragmentation and performance cliffs come from using mmap. It's quick and dirty.
Here's the alternative, and it supports the exact same document storage as MongoDB, the same administration interface, actually the same protocol everywhere, hot backup, and however many nodes you want: TokuMX[1]. It does all those things because it's actually mostly MongoDB, just with the storage engine replaced with an engine that works faster, compresses your data, and has more mature things like document-level locking for writers and better multi-document isolation semantics on a single node. Give it a whirl and let us know if you like it.
That thread is talking about the possible inclusion of our indexing library inside Postgres, and was from before we had open sourced the code. IANAL but I think it would be possible to include the fractal tree library in Postgres now if someone wanted to do it, but none of it has ever been implemented by Postgres.
Everything you've mentioned is standard to SQL databases. If you have a schema you don't need NoSQL. Use an ORM for SQL for the language of your choice. Pretty much any db will run as a single node but you should never do that in practice, redundancy is security is stability
Sure, but by that argument I don't need SQL either. I am not sure what your point is?
Anyway, the selling point (for me) is that I don't need to find some fancy ways to translate my schema to relational schema. For instance, let's say I have some text content in two languages; in relational DB the texts should probably go to a separate table and I should reference the main record by some foreign key. In document-oriented DBs I can just put both of the texts inside the record... To me that makes much more sense.
But yeah, if you are a hardcore SQL user who is used to normalizing the data until it hurts (as someone else commented) it is difficult to break out of the habit.
And after you eliminate SQL as an alternative (in my case) there are not many options left. At least I couldn't find (m)any.
If you know you are only storing two languages, they can go directly on the parent table, named english_text and spanish_text. If you are talking about the easyness of storing a hashmap in NoSQL, ie:
{
english :'text',
spanish : 'text',
french: 'text'
}
You can achieve this in the same table with the JSON storage type:
Really though, a decent ORM will take care of all the foreign key implementation, and a hashmap is well served by a 2nd table called 'texts' with 3 columns. I can see why you would be opposed to this, because of the extra join but given the right indexes it won't be slow at all.
You realise that they are using default kernel implementation? Awful indeed. :)
If you are so anti-MongoDB, would you care to offer an alternative? It must support: - document-like storage (I already have schema on application layer), - simple use / administration, - hot backup, - single node operation.
While this list is mostly outlining why MongoDB is a great DB for my current use case, I am also genuinly interested in better solutions (for that case). So, fire away... :)