未加星标

RethinkDB Failure: Product, not Marketing

字体大小 | |
[数据库(综合) 所属分类 数据库(综合) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

Both RehinkDB and MongoDB started in the same year, and raised similar amount of seed funding. However, RethinkDB is dead. Many attribute this to better marketing on Mongo's part. Looking deeper though, it seems its the core RethinkDB product to blame for its failure.

1. No official Java driver till Dec, 2015

RethinkDB didn't have an official Java driver till Dec, 2015 (and even that only supports Java 8). A 7 year old database, that doesn't have a Java driver till its 7th year! While Java may not be considered 'cool' in the Bay Area, in the rest of the entire world of enterprises, Java is the number 1 language.

By not having an official Java driver for the majority of its life (and only ever releasing one for latest Java version), RethinkDB made clear that it was a database for startups only. Period.

Heck, it never got around to having a C# driver...

2. No Java POJO conversion library

Even after the Java driver was released, it was too low level to actually use in a real world Java application. Quote from the DripStat blog, where it details evaluating RethinkDB to replace Mongo :

With Mongo, we use the Spring Data MongoDB library. It takes care of converting plain Java objects to/from the json format that Mongo drivers need. It results in typesafe, high level code and we never have to interact with the low level Mongo driver.

With RethinkDB, we found no such thing. The only way to interact with it was through its Java driver, which forced us to manually convert our objects to/from Maps. This essentially wiped out all the ease of using a document database in the first place. It meant everything that takes a single line with Spring and Mongo would take many, many lines with RethinkDB.

3. No Automatic Failover till Aug 2015

How many production Mongo clusters you know that run with only 1 node? None. Since the begining, MongoDB claimed High Availibility by allowing you to run with a replica set of 3 nodes, and if one failed, the other took over automatically.

Implementation issues of Mongo aside, by not having this feature till its very last year, RethinkDB was 'automatically' not the choice for anyone comparing it to Mongo.

4. No equivalent to Mongo Cloud Manager

This is described in detail in the DripStat blog post . Basically Mongo's cloud service takes care of installation, upgrade, backup and restore of Mongo clusters, on your private servers. Thereby managing to automate the entire administration of Mongo.

RethinkDB did do a partnership with Compose which it (wrongly) thought resulting in solving the above problems. However, Compose cannot be used in real production apps. It deploys the database outside your virtual network which results in high latency, unreliable network and data transfer costs. Its recent 'Enterprise' plan is order of magnitude more expensive than Mongo Cloud and doesn't work everywhere.

Not having a managed administrative service resulted in signigicanatly increased administrative cost for users, again pushing people towards Mongo.

5. Trying to be Firebase

RethinkDB sacrificed all of the above for 'changefeeds', its 'realtime' push based feature.

It is indeed cool to show in a demo that changing data on one end, automatically 'pushes' the change to another client. However, the majority of the world doesn't care about that. They just want to save their signup data, and user setting data and all kinds of other data that doesnt need to be 'pushed' over websocket for that 'its sooo cool' effect.

Firebase was a tiny company that sold for an insignificant amount to Google. It is used by either startups or by large corps for a very small subset of data. The majority of data in the world is accessed over REST APIs and stored in 'non-realtime' databases. The success of every other database in the world, that is not Firebase, should have proven to RethinkDB, that their efforts were being put in the wrong direction.

Even here though, RethinkDB was far more complicated to setup and use than Firebase. It literally tried to clone Firebase by offering Horizon, but that too had a long way to go.

Conclusion

Marketing was not the root cause of RethinkDB's failure. It was the product. DripStat did a thorough evaluation of RethinkDB to replace Mongo and found out it couldn't.

RethinkDB is classic a story of good engineers doing only 'cool' things, not understanding their business, and ignoring all the 'boring' things that actually make a business tick.

本文数据库(综合)相关术语:系统安全软件

主题: JavaMongoDBSpringRESTC#
分页:12
转载请注明
本文标题:RethinkDB Failure: Product, not Marketing
本站链接:http://www.codesec.net/view/480739.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(综合) | 评论(0) | 阅读(36)