3 ms·

I'd love to hear any opinions the RethinkDB guys have about this.

by kbd 13y ago

coffeemug 13y ago
slava @ rethink here. I have a few thoughts on this: a) There is an astronomical difference between a neat technology and a complete, usable, supported product (especially with really complex software like databases). I can't tell yet how committed Toku folks are to this project. Is this a research project that may or may not go somewhere, or are they all in on the product? I think it's very important (for the customers and the industry) to get a clarification on this point. b) I love seeing engineering projects like these. Experimentation like this (using a superb storage engine to power a popular db) is really exciting. I'd love to see where this goes. c) RethinkDB has its own state of the art storage engine (with a very different architecture from Toku) that's tightly integrated into the full system. That lets us do very interesting things (fast path code paths, btree-aware caching system, etc.) The advantages and disadvantages of pluggable storage engines are really interesting. d) If TokuMX does turn into a complete product, it's really exciting. It's nice to see the industry maturing.
- zardosht 13y ago
  I work for Tokutek. Slava, thanks for the kind words. Just to clear up any possible confusion, this is the product. We release and support TokuMX. The research started roughly a year ago (the blog posts we've done are out there), and it has led to this. We consider this to be full featured in the sense that we have a feature set that we feel users can deploy in production. As with any product, as users give feedback on what more they would like to see, be it existing MongoDB features or something else, we will use that feedback to enhance the product.
- esmet 13y ago
  TokuMX is indeed a complete product, not an experiment. We're proud of it and ready to support it yesterday :) I completely agree that pluggable storage engines are an interesting topic. But we went the integrated route (ie: no storage API) probably for the same reason: things get simpler and easier to implement when the stack is shorter.

I'd love to hear any opinions the RethinkDB guys have about this.

by kbd 13y ago

I'd love to hear any opinions the RethinkDB guys have about this.

slava @ rethink here. I have a few thoughts on this: a) There is an astronomical difference between a neat technology and a complete, usable, supported product (especially with really complex software like databases). I can't tell yet how committed Toku folks are to this project. Is this a research project that may or may not go somewhere, or are they all in on the product? I think it's very important (for the customers and the industry) to get a clarification on this point. b) I love seeing engineering projects like these. Experimentation like this (using a superb storage engine to power a popular db) is really exciting. I'd love to see where this goes. c) RethinkDB has its own state of the art storage engine (with a very different architecture from Toku) that's tightly integrated into the full system. That lets us do very interesting things (fast path code paths, btree-aware caching system, etc.) The advantages and disadvantages of pluggable storage engines are really interesting. d) If TokuMX does turn into a complete product, it's really exciting. It's nice to see the industry maturing.

zardosht 13y ago
I work for Tokutek. Slava, thanks for the kind words. Just to clear up any possible confusion, this is the product. We release and support TokuMX. The research started roughly a year ago (the blog posts we've done are out there), and it has led to this. We consider this to be full featured in the sense that we have a feature set that we feel users can deploy in production. As with any product, as users give feedback on what more they would like to see, be it existing MongoDB features or something else, we will use that feedback to enhance the product.
esmet 13y ago
TokuMX is indeed a complete product, not an experiment. We're proud of it and ready to support it yesterday :) I completely agree that pluggable storage engines are an interesting topic. But we went the integrated route (ie: no storage API) probably for the same reason: things get simpler and easier to implement when the stack is shorter.