undefined | Better HN

0 pointssaurik5y ago0 comments

I am not even sure what is going on now, as I thought the only reason people had ever cared about MongoDB in the first place was in an attempt to get performance they thought was impossible using a relational database (notably without realizing all of the tradeoffs... some inexcusable, such as simply coming with defaults that didn't call fsync, leading to a ton of memes about "database administrators running with scissors" and years of having to convince people that MongoDB was only a project you use if you don't care about data).

The irony, of course, was that it turned out that if you used PostgreSQL and simply stored json in it, you could get better performance without giving up on a relational database... and even more damning was that the translation from MongoDB's query syntax to PostgreSQL's query syntax was trivial, leading to people building adapter layers that were drop-in compatible (and yet still faster and safer than MongoDB). So I guess there was something fitting about seeing someone post a project that is trying to the SQLite of MongoDB, but with benchmarks right off the bar showing it slower than SQLite ;P.

I thereby continue to feel that if you want to use MongoDB, but want a library version of it, it would seem--based on this project's own benchmarks, unless you are doing a read-heavy workload of random documents by index--that what you probably want is a query translator to go from MongoDB's syntax to SQL (working with the SQLite json API), and then store your workload in SQLite... which is (critically) a battle-tested production-grade database engine used as a foundational storage layer for lots of projects.

That said, it isn't like SQLite was a drop-in replacement for other database engines: when I think of "X is to SQLite as MongoDB is to PostgreSQL" I picture something that is attempting to being benefits over SQLite -- in way of performance or scalability -- at the cost of losing the power of being a full relational database (and, because of Mongo's legacy, probably a lot of safety and stability guarantees ;P). (FWIW, I remembered there's being a project like this: UnQLite-- https://news.ycombinator.com/item?id=18101689 --where people ironically seem to have wanted to get it benchmarked against SQLite with its json API ;P.)

It sounds like maybe this project is just trying to provide MongoDB's query layer? You simply don't use SQLite until you "migrate to the full PostgreSQL"... they are designed for different scenarios, and while SQLite is good enough you might be able to use it in a place where PostgreSQL "was called for", a migration might be brutal (as the syntax and type system are different). The project tagline is thereby leading to the wrong mental space--as seemingly multiple other people have since now mentioned on this thread--particularly given that it is written in Python.

0 comments

6 comments · 2 top-level

kabes5y ago· 2 in thread

Having the best performance isn't necessary for a lot of use cases. Sometimes you just want to store and search a bunch of json objects and for that the mongo api is way more convenient then the postgres/sqlite json options

necovek5y ago

I am not too familiar with MongoDB, but how does the API compare to an ancient key-value store library of Berkeley DB (db.get/put/delete/...)?

(Asking in the context of Mongita, or rather, a file-based key-value store)

jd_mongodb5y ago

There isn't a relationship between the two in terms of API. However the team that designed the Berkeley DB storage engine went on to commercialise it via a company called SleepyCat. That company was acquired by Oracle. The team subsequently left Oracle to found WiredTiger (SleepyCat, WiredTiger, geddit? :-)). WiredTiger was focussed on building a modern database storage engine focussed on high CPU count, high memory footprint servers. In 2014 MongoDB acquired WiredTiger and that is now the main storage engine for MongoDB. Interesting Footnote, Michael Cahill is the primary author of "Serializable Isolation for Snapshot Databases" [0] the paper that introduced Serializable Snapshot Isolation (SSI). SSI is the concurrency control mechanism used in Postgres [1][2]. [0] - https://courses.cs.washington.edu/courses/cse444/08au/544M/R...

[1] - https://wiki.postgresql.org/wiki/SSI

[2] - http://drkp.net/papers/ssi-vldb12.pdf

pbreit5y ago· 2 in thread

The correct comparison is "Mongita is to MongoDB as SQLite is to Postgres/Mysql".

"performance or scalability" are not benefits of SQLite.

The benefit of SQLite is that it is a "small, fast, self-contained, high-reliability, full-featured, SQL database engine".

krageon5y ago

SQLite performs very well and it scales vertically to millions of ops pretty easily. Then you can say "well, we'll worry about more performance later". In this case, perhaps not so much.

chx5y ago

> "performance or scalability" are not benefits of SQLite.

Where scalability is indeed nonsensical for an embedded database, performance very much is a feature of it.

j / k navigate · click thread line to collapse