3 ms·

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

• leif 13y ago
  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 13y ago
    check my reply to zardosht below/above
  • ddorian43 13y ago
    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 13y ago
      All TokuMX data and index storage is block compressed. It's not hard, it's on by default.
• zardosht 13y ago
  ddorian, Can you elaborate what that means?
  • ddorian43 13y ago
    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 13y ago
      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 13y ago
        but rethinkdb doesn't have range-sharding (they had it but they are/did change it to random(id), also no sharding(custom_field))