41–50 of 85 posts
Mongo has been around for years, and it still has problems.
Rethinkdb is just launching a new product that essentially does the same thing as Mongo, but is maybe just a little easier to use.
I think the Yet Another Database (YAD) question still hasn't been answered by this post.
How's the general performance and memory consumption on smaller machines, e.g. entry-level VPS's or the lower spectrum of AWS VMs? Don't have any big projects in the pipeline that immediately required sharding etc, but would like to play with it on a few weekend-scale items.
Earlier quoted context omitted.
http://www.rethinkdb.com/docs/faq/#when-is-rethinkdb-not-a-g... http://www.rethinkdb.com/docs/advanced-faq/#is-rethinkdb-imm...
You mention comparing against Hadoop for computationally-intensive data analysis. Would Rethink be suitable for a several-terabyte dataset with non-computationally-intensive analytics? Currently we're using Hive and Python over streaming Hadoop. There's no significant ongoing data accumulation; we're just analyzing the data we have.
Earlier quoted context omitted.
Rethink has durability, MVCC, joins, logical sharding, excellent admin tools, etc. All things that serious databases tend to have and Mongo doesn't.
MongoDB IS durable now by default, has a third party MVCC implementation (MongoMVCC) and has pretty decent admin tools. And this idea that joins is a requirement for a "serious" database makes absolutely no sense. Database level joins are toxic for scalability and IMHO should always be done in the application layer.
If you want a durable write; you should not disable journalling and use safe mode / getlasterror with the desired writeconcern setting - http://docs.mongodb.org/manual/reference/command/getLastErro...
How's the general performance and memory consumption on smaller machines, e.g. entry-level VPS's or the lower spectrum of AWS VMs? Don't have any big projects in the pipeline that immediately required sharding etc, but would like to play with it on a few weekend-scale items.
We did some testing and it should be great, especially once https://github.com/rethinkdb/rethinkdb/issues/97 makes it in.
I'm going to benchmark it when I get some time!
My company uses MongoDB. Our biggest pain points are: 1. MongoDB has massive storage overhead per field due to the BSON format. Even if you use single character field names, you're still looking at space wasted on null terminators. 32bit fixed length int32s also bloat your storage use. We solve this by serializing our objects as binary blobs into the DB, and only using extra fields when we need an index. 2. In Mongo,…
http://docs.mongodb.org/manual/reference/command/collMod/#us...
10gen have been thinking about compression but nothing specific has happened yet (https://jira.mongodb.org/browse/SERVER-164). ZFS + compression is interesting, but not 'production' quality if you're using linux, and last time I tried to get MongoDB running on Solaris I gave up...
«An asynchronous, event-driven architecture based on
highly optimized coroutine code scales across multiple
cores and processors, network cards, and storage systems.»
How does such a design imply multicore scalability? Obviously, coroutines and event loops don't prevent you from running in multiple cores. I just fail to see the correlation.
How can I understand the performance of slow queries? Understanding query performance currently requires a pretty deep understanding of the system. For the moment, the easiest way to get an idea of why your query isn't performing well is to ask us.
Wish RethinkDB was a little further along because it seems like it might be a good fit for a new service I'm building.
Earlier quoted context omitted.
MongoDB IS durable now by default, has a third party MVCC implementation (MongoMVCC) and has pretty decent admin tools. And this idea that joins is a requirement for a "serious" database makes absolutely no sense. Database level joins are toxic for scalability and IMHO should always be done in the application layer.
MongoDB has been durable for a while with journalling. They're only just enabled safe mode (i.e. synchronous) for the clients by default, but this is something different to being durable. If you want a durable write; you should not disable journalling and use safe mode / getlasterror with the desired writeconcern setting - http://docs.mongodb.org/manual/reference/command/getLastErro...
Sure. Which is the default approach of almost all of the drivers.
Looks very interesting, but this statement in their FAQ is a red flag for me: How can I understand the performance of slow queries? Understanding query performance currently requires a pretty deep understanding of the system. For the moment, the easiest way to get an idea of why your query isn't performing well is to ask us. Wish RethinkDB was a little further along because it seems like it might be a good fit for a…
We are building a tool to explain in a nice way how the query is executed, what are the bottlenecks etc. It should make it for 1.5.
You can track progress here https://github.com/rethinkdb/rethinkdb/issues/175 (it's kind of empty for now)