Earlier quoted context omitted.
Interesting perspective, but it turns out that the opposite is true. Using better indexing is a general improvement to database performance and manageability.
His argument was that the indexing they do only improves a specific type of query. Personally I think he's wrong but that was his view a year or so ago.
TokuMX 1.4: Major improvements to MongoDB sharding and replication
11–20 of 20 posts
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#12Now they only need to set the sharding rethinkdb-style and they win.
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.
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#13Now they only need to set the sharding rethinkdb-style and they win.
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.
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?)?
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#14Earlier quoted context omitted.
ddorian, Can you elaborate what that means?
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)
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#15Earlier quoted context omitted.
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.
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?)?
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#16Earlier quoted context omitted.
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)
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.
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#17Why doesn't 10gen buy them?
They have some unfortunate behaviors that are all attributable to their storage implementation, most prominently locking, fragmentation, and slow performance out of memory. While they could "just buy TokuMX" and solve these problems with money, it would then put their engineering team in a position where they would need to relearn a big portion of their codebase, and spend time backporting features they've prototyped to TokuMX. It would basically halt new development for a few months while they learn the new code, too.
The way I see it, MongoDB will continue prototyping interesting features and polishing some of their existing ones, and TokuMX will incorporate the ones with the most promise. But to integrate the codebases would slow down MongoDB considerably, and I don't think they can afford that right now. I'm perfectly happy to sit back and merge the best features from MongoDB as they mature.
Put another way, if you were working on a product and someone came to you and said "here let me fix a bunch of things by replacing some of the fundamental subsystems with code you don't know," would you do it? Maybe if you were in more of a maintenance mode, you'd evaluate it for a while and take the time to learn the code and eventually incorporate it, but not if it was going to distract you from adding features.
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#18Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#19Any way to have wget-able download links for the .deb? Using a browser to go the dl page isn't that easy when on a server...
For now the best I can do for you is tell you that if you email me I can hook you up. Short of that, if you search twitter for "severalnines wget" you can find a wget hack that achieves the result you want.
Re: TokuMX 1.4: Major improvements to MongoDB sharding and replication
#20Any way to have wget-able download links for the .deb? Using a browser to go the dl page isn't that easy when on a server...
This isn't a great answer, but I think I owe you an honest one. Our marketing department wants to be able to throw the "please put your email here if you want" form up before a download. We are trying to find a way to reconcile our sales/marketing goals with what we know are our fellow engineers' needs and we hope to make downloads easier in the future. Providing packages at all, over just a single binary tarball, is…