[ddorian43]

Now they only need to set the sharding rethinkdb-style and they win.

[leif]

It's unclear exactly what you mean by "rethinkdb-style" because that could mean a number of things, but stay tuned for our posts on this next week, I think you'll be pleasantly surprised.

[ddorian43]

also what would be really cool for very-big-data + ~bigger latency is ~index compression.

Bascially Hypertable (based on Bigtable) compresses data in blocks, but in the index saves only the ids of the first and last documents in the block. This could be hard for secondary indexes (maybe?)?

[leif]

All TokuMX data and index storage is block compressed. It's not hard, it's on by default.

[ddorian43]

check my reply to zardosht below/above

[zardosht]

ddorian, Can you elaborate what that means?

[ddorian43]

What i mean, every node is the same, no mongos , you just connect to one random mongod and it handles the mongos funcionality.

So if you grow, you add 1 node, not a replica-set(that could be 3 nodes if you have 3x replication)

[leif]

Unfortunately, this would break compatibility with existing MongoDB applications more than we would probably be willing to do. However, there's no reason RethinkDB couldn't use Fractal Tree indexing instead of B-trees, given some engineering effort.

[ddorian43]

but rethinkdb doesn't have range-sharding (they had it but they are/did change it to random(id), also no sharding(custom_field))