3 ms·
RethinkDB won't be in this position for long (and in fact, most lessons in the article came directly from the mistakes made in the process of building RethinkDB
by coffeemug 12y ago
RethinkDB won't be in this position for long (and in fact, most lessons in the article came directly from the mistakes made in the process of building RethinkDB).
We found a big point of a differentiation (http://rethinkdb.com/blog/realtime-web/ http://rethinkdb.com/blog/realtime-web/), which, depending on one's definition, can be considered discovering a new market, and we'll be the first open-source scalable database in that market. The upcoming 2.0 release will reposition the company around realtime web/push database. A huge part of the reason why we chose this path is the lessons in the article.
- dkarapetyan 12y agoI agree with you. RehinkDB does make a very compelling product for the stream based future. Looking forward to more stuff from you guys. This is the best written article I've read in a long time on startup stuff.
- MichaelGG 12y agoIsn't that something like SQL Server Query Notifications, where you can submit a query and the DB lets you know when the results have changed? Albeit your API looks much smoother. Speaking of which, I really hope at one point you reconsider the driver model. Having official drivers for only a few not-so-awesomely-typed languages is a big turnoff.
- coffeemug 12y ago> Isn't that something like SQL Server Query Notifications Yes, very similar, but there are a few major differences -- open-source product, horizontally scalable, json data model, packaging/api designed for web developers from the ground up. When you add all of these up, the differences are quite dramatic. > I really hope at one point you reconsider the driver model. Yes -- after 2.0 is out, we'll start bringing the community drivers under the official umbrella.
- ntoshev 12y agoI am yet to read that blog post, but it seems to me that this problem should be solved at a different level. The issue is that modern application need to work on mobiles and browsers, and be responsive. To be responsive you need to bring the part of the state that can be reached via the UI to the device. This suddenly makes your database distributed among your servers and your client devices. The device may be a mobile phone or a laptop in an airplane, and it needs to work offline and on networks with high latency. This means you need to have an eventually consistent AP database across servers, browsers and mobiles. Currently databases assume they live on servers and we hack our way with distributed state on the clients, but I hope this won't last.
- coffeemug 12y agoWe're operating off of two hypotheses: - Eventually consistent systems are fundamentally more difficult to program for average developers than immediately consistent ones (and when a more convenient system is an option, it wins) - Connectivity is improving and will continue to improve, so immediately consistent systems will always be a strong option It remains to be seen whether these hypotheses prove to be correct in practice. We'll find out soon.
- MichaelGG 12y agoThat's excellent. I was recently looking for a simple storage system and went with Elasticsearch despite it not fitting perfectly, because the interface worked well from Rust and F#. I was mainly interested in auto replication/HA. Rethink would have been a better choice, but the driver situation made me decide I didn't want to take on the risk. Looking forward to 2.0.
- ntoshev 12y agoThe shift from spinning hard drives to SSDs is an environmental change like the ones you describe in the article. What made it hard to exploit? Not enough improvement, compared to legacy databases on SSD?
- coffeemug 12y agoYes. There were many, many companies that attempted to exploit this trend in databases and caching, and all of them are now dead, zombies, or pivots. The reason is that there is no valuable product there one could ship. Putting an existing database on an SSD gives you all of the benefits and none of the drawbacks.