Live data from Hacker News

MongoDB shares jump more than 30% in $192M IPO

cnbc.com

121–130 of 425 posts

Re: MongoDB shares jump more than 30% in $192M IPO

#121
post #96

Earlier quoted context omitted.

These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.h...

Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D

This meme isn't even funny anymore.

It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.

Re: MongoDB shares jump more than 30% in $192M IPO

#123
post #56

I don't understand why everyone is so happy when IPOs go up and make it sound like a good event. I see it as the founders needlessly missing out on 30% of money (in this case), which ends up going in the pockets of the Wall Street middle men that get first access to the stock offering.

Pricing is hard, but yes, I think they did price this one a little too low. That said, the goal is for shares to have a nice upward pop when they hit the open market. This helps encourage a broader based of shareholders, protecting against the case where a big shareholder decides to dump all of their shares. This also helps in the case where the company comes out with bad news in the near future. Shareholders who mak…

> Pricing is hard, but yes, I think they did price this one a little too low.

Auctions can work pretty well for pricing things.

Re: MongoDB shares jump more than 30% in $192M IPO

#124
post #26
post #6

Earlier quoted context omitted.

To be fair, Mongo is better than it's ever been. They even got through Jepsen just fine after wiredtiger. That said, it's pretty hard to make sense of when you would want non-relational dbms these days, especially in an era where you can get 100core systems in AWS/GCP. Write-scaling is still a pretty obvious reason, though things like Citus might help here.

They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The…

Not sure if you know much about databases but those are standard defaults.

Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle.

http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...

Re: MongoDB shares jump more than 30% in $192M IPO

#125
post #31
post #28

Earlier quoted context omitted.

> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.

Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you kno…

PostgreSQL JSONB doesn't have a dedicated driver though i.e. you can't do partial updates via the JDBC/ODBC drivers.

Which means you can't use it for any big data/analytics use cases. MongoDB has fantastic client libraries e.g. Spark, Java.

Re: MongoDB shares jump more than 30% in $192M IPO

#126

Earlier quoted context omitted.

I used the word quit in my very first post on this thread in a way that should’ve been obvious I meant quit my job .

It wasn't the word "quit" that was being objected to though; it was your equating quitting to being homeless (in the very same first post in this thread) and then further saying you think many others would also rather quit and be homeless than work with MongoDB. That's a bit too dramatic. Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem.

> Next time, just say "I'd rather quit than work with MongoDB again", and you won't have this problem.

Fair point... “I would quit rather than work with MongoDB again” is more accurate, but still encapsulates your point.

The point I was trying to make earlier and did in a way overly dramatic for you is that I’d never take a tech job again if it meant I had to use Mongo.

Re: MongoDB shares jump more than 30% in $192M IPO

#127
post #79

Earlier quoted context omitted.

Sparse heterogeneous data is often the type of data stored in NoSQL dbs. Modelled in a relational way, this produces many tables with many NULL fields, while keeping it in a key value format is neat and tidy. I'd recommend the paper What Goes Around Comes Around[1], the first paper in Readings in Database Systems[2] [1] https://scholar.google.com/scholar?cluster=73661829057771494... [2]redbook.io

You've got options there though https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...

No.

EAVT is great as an intermediate format but it is absolutely useless to query for since most of the time you are trying to find a set of attributes for a given entity i.e. full table scan.

What you want is a "wide table". One entity column and all the attribute columns to the right. Often with most of the values set to null.

This is the dream use case for MongoDB since it you can ignore sparse values yet when you query it via their drivers it will appear as a wide table. You can't do this at all in PostgreSQL since you will hit a column limit.

Re: MongoDB shares jump more than 30% in $192M IPO

#128
> "Most applications today run on a database technology that was introduced in the 1970s," Ittycheria said. "In the '70s, I was using a rotary phone to have a phone conversation. So people are looking for a modern, scalable and flexible platform."

It's like a weird version of the Turing test where you have to decide whether someone's speaking seriously or in jest when they talk about NoSQL.

https://www.youtube.com/watch?v=b2F-DItXtZs

Re: MongoDB shares jump more than 30% in $192M IPO

#129
post #65

Earlier quoted context omitted.

If they had done so by presenting a product that was picked up due to it's merit and continued to gain traction based on that then I'd be rather impressed. Instead the story of MongoDB seems to be how extremely well targeted marketing and sales can build a so-so product into a huge IPO, there have been performance comparisons showing it isn't even the best at what it does so this IPO is riding on the network effect o…

Ah, right, like RethinkDB? As much as I'd love this to be true, the #1 measure of success is if people even know you exist and #2 is if you solve enough of a customer's problems that it's worth using your product. MongoDB hit these two points hard right out of the gate and are now very successful because of it.

I think it all comes down to what definition is of solving a problem.

What Mongo did is implementing these features just well enough so they can put checkpoint in their marketing brochures.

When you actually start using it you learn that most of it is either performing slow, does not work correctly or once in a while corrupts your data.

Yes they hit these points hard, but only from marketing point of view. They are now universally hated by ops and developers because these people now have to deal with fallout.

RethinkDB actually is an example that database is something that's not good as a base for a startup[1], and the Open Source approach (like PostgrSQL) is more suitable.

MongoDB is example that you can base a startup on a database technology and succeed, if you can sleep well at night that your product can cause people to lose data.

[1] The reason RethinkDB failed was because they refused to provide half solutions like MongoDB, everyone expects startup to start making money, but building a reliable databases is not something that's easy and can't be done quickly.

Re: MongoDB shares jump more than 30% in $192M IPO

#130

Earlier quoted context omitted.

Sparse heterogeneous data is often the type of data stored in NoSQL dbs. Modelled in a relational way, this produces many tables with many NULL fields, while keeping it in a key value format is neat and tidy. I'd recommend the paper What Goes Around Comes Around[1], the first paper in Readings in Database Systems[2] [1] https://scholar.google.com/scholar?cluster=73661829057771494... [2]redbook.io

> Sparse heterogeneous data is often the type of data stored in NoSQL dbs. I still can't imagine what sparse heterogeneous data exists in the world that makes sense to store. Any type of querying or processing requires some kind of structure (even if implicit in the code) which you can just put in different table structures. You have to make sense of data to process it and that kind of implies a structure, doesn't it…

Customer Analytical Record / Feature Engineering Store

One customer column, tens of thousands of attribute columns.

If you need everything about a customer it is a single, O(1) fetch operation which makes it perfect for driving chat bots, call centres, websites, operational decisioning engines, dashboards etc. Almost every large company will have one of these.

You can't really do it in relational systems properly because (a) you hit the column limit, (b) often it is sparse i.e. lots of NULLs everywhere, (c) you need this system to be distributed since it often gets a lot of load.

Post reply on HN