Friends don't let friends use MongoDB!

Friends don't let friends use MongoDB!

"Friends don't let friends use Relational Databases" - truly amazing, freedom, free and liberation from SQL, very awesome right?

Wrong. The entire purpose to capture the data is to be able to use it, easily and effectively. What is the easiest, fastest, most accurate, uniform way to use your data - SQL of course.

The entire "coolness" of NoSQL was not so cool after all since most of them, if not all NoSQL offerings started to offer SQL or SQL like, Hbase, Hive, Cassandra CQL, and of course MongoDB SQL support is an "enterprise option". Even mighty Spark offering SparkQL and lets not to forget Kafka is offering KSQL - why if SQL is not cool ?

MongoDB "SQL support enterprise option" just rang an a unpleasant deja vu - suddenly I remembered AS/400 where "SQL" was a premium add on option and that was back in 90's.

Why would I pay for SQL when its already free of charge!

Cool and new is not cool after all, non relational databases predated relational databases, they went extinct after the SQL invention and stayed in obscurity for a while. Along comes "internet of things" and long be hold SQL somehow becomes uncool. Were SQL databases such as MySQL and PostgreSQL non-scalable ? Of course not - MySQL and derivatives are powering most of the gaming, so obviously it can scale. May be schema changes was difficult but this has nothing to do with SQL and a lot do do with Btree and schemas. Also industry responded and live schema changes are here - Percona, GhOST by Shlomy, the list could go on. So why the "uncoolness" - marketing, marketing and marketing.

First rule of marketing - know who is your customer, better yet - know who is not your customer, lets look at MongoDB marketing selecting their customer:

  • DBA's - no of course, this crowd so entrenched in SQL and amassed massive SQL know how, they would not let go of tried and true tools, what even more important DBA's are typically are true data domain experts in the company, dba's are also a very conservative crowd and hardly ever willing to accept something new, not because they are mean, but because they already spending nights on call and adding a unproven solution with no SQL support was not an attractive option.
  • Data Professional/Data Wranglers. These are our beloved Data Analysts, Data Architects, Report writes, financial reports - end users of the data that is gathered by the apps. Can they be MongoDB customers/early adopters. No - of course, lack of SQL negated their primary skill - SQL data reporting.
  • Data Architects. Again no, data architects must think of all aspects of applications development and that includes both data ingestion and data consumption. If I propose MongoDB as a solution I need to assure that data consumers can easily use it, proposing a solution that negates data professionals primary tool SQL will hardly gain any ground.

The above are about 99% of the data users on the receiving end. Data as it happens is ingested by the apps, collected and consumer by Data Professionals - their primary tool is SQL.

Who is it then?

Developers! Genius

Developers very unlike DBA's are experimenters, developers by in large more concerned about apps features then Data Analytics. developers are also less concerned with such petty things as data integrity, financial reporting and are far more willing to adopt emerging solutions. NoSQL in some cases saves a development time at the expense of very complicated reporting and paid SQL ad-ons, mind you that SQL is already free in Relational Databases, but developers are not in charge of budgets.

Awesome marketing, adoption, going public ...whoa! Now what? We gathered all this exciting data in very cool new database - now lets report on it ! Oops - there is no SQL, no easy, handy way to browse the data.

I can teach a basic user to use SQL in one day, this because SQL will abstract database intricacies from the end user - it matters not it is Oracle, DB/2, MySQL, Firebase, TiDB, CockroachDB, Teradata, Snowflake, YellowBrick, Trafodion - they all speak common language SQL. Tables, relations and SQL are far easier to explain then JSON, BSON etc... And the proof is in the pudding - right there. Snowflake supports both Json and structured data, I've been offering reporting users to use Snowflake's VARIANT DATA type for a while now - "Look the data is right there!" but you have to parse it. Needless to say I didn't manage to get any takers, data analysts already overburdened by ever increasing requirements now on top of that learning a new skill to parse the data? No Thank You!

Fine MongoDB with skillful marketing gained a foot hold in adoption - that is very amazing for a database product, truly is. But it will not last as data professional and data architects on the receiving end will start pushing it out, all it did - it simplified data ingestion at the vast expense of data consumption. It just simply has nowhere to go - cloud providers already filled the gaps - CloudSpanner, Aurora, RDS etc.

May be I do not see a "big picture", may be there is "magic" in its use, lets see what the financial experts say:

Here is a quote from MotleyFool:

"Now what

It's difficult to find a fair value for this stock, because MongoDB isn't profitable in any way, shape, or form. The stock trades at 10 times trailing sales and 36 times the company's book value, which qualifies for the nosebleed section of Wall Street. That's after the earnings-based price drop and the updated financial performance in that report. Before the third-quarter report, MongoDB traded at 19 times sales"

MongoDB had great marketing strategy - knowing "who is not your customer" , but on the business and product strategy the picture is quite different - it is all for all, it is targeting relational database users base, NoSQL users base and BigData ! it is for everything but no one in particular and to gain further acceptance it needs to gain in MySQL user space, but MySQL already adapted - Aurora, CloudSQL, RDS, ApsaraDB Alibaba, MariaDB and if this is not enough, you can stick a JSON in MySQL data type, awesome up and coming MariaDB cloud, so good luck with this en-devour. PostgreSQL also rolled out a plethora of new features so the battle for share in relational databases may just heat up again. And if all of this is not enough look at TiDB - MySQL dialect, fully distributed storage separated from compute, designed for K8s, it is not Btree, its lsm, and you could use Spark on storage - it just does not get any better.

MongoDB would have been successful by just becoming a leader in NoSQL realm, the trouble is there are two many of them and they are only getting better - my bet on future "be all NoSQL database" is ScyllaDB, it has all Cassandras benefits and none of its drawbacks. For all practical purposes ScyllaDB just closed the gates.

BigData. BigData was lagging for a while with the cool staff and then rolled out an avalanche - Snowflake, BigQuery, RedShift, Impala, Kudu, Trafodion, SparkQL, AnalyticDB, YellowBrick, Kafka, Pulsar, so that space is very tight.

MongoDB just simply has nowhere to go, and aws just swiped their offering "DocumentDB" (couldn't they find a cooler name at least PineAppleDB or something) - hey if you say "open source" open source it is.

Here is the link https://www.fool.com/investing/2020/01/07/why-mongodb-shares-fell-115-last-month.aspx

This is the perfect time for DBA's to say "I told you so!"

Jeff Beal

Staff Infrastructure Engineer at Ramp

5 年

I think the best point you make in the article is the idea that "NoSQL" works better as a marketing concept than as an apt description of what the key difference is between the traditional relational databases and everything else. I'm not aware of anything that matches the expressive power of SQL for querying and analyzing data, but that's not all you do with your database. In many applications, what is needed is a high throughput, high availability system to record the transactional record of what your application is doing, and a separate database (or data warehouse) for flexible querying and analysis. SQL is great for the latter, but databases like Mongo or Dynamo can be (Probably won't always be) more suited for the former. Good engineers (both of the software variety and the data variety) can understand the tradeoffs and make the right choice for their business. There's no one-size-fits-all approach, and I'm glad that the effective marketing buzzword "NoSQL" has helped more engineers be aware of the alternatives.

David Fetter

PostgreSQL Professional

5 年

Just remember what MongoDB reached for when they needed to get something important done.?https://www.dhirubhai.net/pulse/mongodb-32-now-powered-postgresql-john-de-goes/

回复
Vedran B.

vb-consulting.github.io

5 年

Great article. For me, NoSQL is kind of retarded term and it should be used at all any more. Just think about - I'm a software product/system and I'll emphasize?in my very name that I don't have a certain feature... because I'm proud not having this feature... Oh, what's that, users actually want that feature!? Let's put that feature but the name stays! That's just plain stupid.

Jonathan Levin

Senior MySQL/MariaDB DBA

5 年

If that billboard is real, thats really pathetic

Peter Farkas

Co-Founder, CEO @ FerretDB

5 年

"Friends recommend real friends the best solution for the specific problem they are dealing with " would certainly be worse as a marketing material, but...

要查看或添加评论,请登录

Constantin Alexander的更多文章

社区洞察

其他会员也浏览了