It's sad that author did not mentioned that disk engine basically stores copy of data in memory. And it seems from benchmark code that reading doesn't hit disk at all.
Show HN: Mongita is to MongoDB as SQLite is to SQL
51–60 of 95 posts
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#52"Mongita is to MongoDB as SQLite is to SQL"
SQLite is a embeddable SQL implementation which has been ported to dozens of platforms with no requirements.
Mongita is a Python library.
I like Python as much as the next guy, but the comparison is pretty far off whack. SQLite is popular because it embeds everywhere easily. This doesn't. I can't use this on my iPhone app. It's likely way too fat for Android and awkward at best on Android.
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#53Anyway to integrate it with a NodeJs project? Seems like a good fit for Electron apps!
Seems unlikely, it's written in Python. Might be possible to bodge something together, but interop would be crap.
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#54> Mongita is to MongoDB as SQLite is to SQL it really isn't if it's written in python
Author here. My goal with that one-liner was to convey immediately what it is - an embedded database that implements the PyMongo/MongoDB API. Is it semantically perfect? Probably not. Will Mongita be useful to Python developers who are accustomed to saving their data in idiosyncratic JSON files because they don't want the overhead of a MongoDB server? Maybe! I hope so.
To me it was a good analogy. But I think the key for me thinking it's reasonable is that I go into Show HN posts with milder expectations than other submissions.
I would never pick MongoDB over a traditional relational database, so I can't judge this well, but I can still see how people would find it useful. Nice work!
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#55Earlier quoted context omitted.
Thanks for sharing your project. It’s probably not a good comparison. SQLite is in such high esteem and such a well developed high quality mature product. So the comparison is sort of inviting criticism that gets in the way of people appreciating what is good about your project.
This is good and helpful feedback. Thank you. I'm humbled by how well this has done so far but definitely feeling the criticism. A title like, "Mongita is embedded MongoDB for Python", while being a statement without ambiguity, doesn't immediately convey the vision for why this might be useful to people. SQLite by contrast is a nice rhetorical anchor that people understand. I'll have to think through whether there is…
Right, a little controversy never hurts to attract attention. You will have to balance between the positive attention through comparison to an known good vs. potentially unmet expectations that known good brings.
If your goal is to reach pythonistas with this, then suffering the “this isn’t really like SQLite” critique will be worth it. On the contrary, if the vision is really to be like SQLite, i.e. broadly portable to many languages and platforms and very robust high quality code then the disappointment in its current implementation may outweigh the near term attention.
In either case this is probably a good measure of demand for such a thing.
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#56what i always think about stuff like this:
if stuff like mongita and sqlite would exist for all kinds of databases (graph,kv,xml; as for document and sql it already exists), couldn't we "just make distributed versions" if we put stuff ontop of it? like with dqlite/rqlite with sqlite?
or does there have to be some inherent mechanisms withIN the database to support distributed versions?
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#57It's sad that author did not mentioned that disk engine basically stores copy of data in memory. And it seems from benchmark code that reading doesn't hit disk at all.
Hey, your first statement is true but your second is not.
The disk engine does store data in memory which is part of the design. You wouldn't want to use a database that doesn't utilize caching.
The last benchmark panel, https://raw.githubusercontent.com/scottrogowski/mongita/mast..., shows cold starts where I test it without cache. So in that, it does hit the disk.
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#58what i always think about stuff like this: if stuff like mongita and sqlite would exist for all kinds of databases (graph,kv,xml; as for document and sql it already exists), couldn't we "just make distributed versions" if we put stuff ontop of it? like with dqlite/rqlite with sqlite? or does there have to be some inherent mechanisms withIN the database to support distributed versions?
I think as I understand it, your question is whether we can't just put a distributed layer on top of basic embedded databases.
This is really interesting and is something I came across while writing this. It turns out that concurrency is actually quite difficult because either you have global locks, which means only one process can write to the database/indicies at once and slows things down considerably, or you have to do a lot of clever things to avoid those locks.
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#59I mostly use SQLite for persistence - put anything in and it's resistant against crashes and corruption. What is the persistence story with Mongita?
Re: Show HN: Mongita is to MongoDB as SQLite is to SQL
#60what i always think about stuff like this: if stuff like mongita and sqlite would exist for all kinds of databases (graph,kv,xml; as for document and sql it already exists), couldn't we "just make distributed versions" if we put stuff ontop of it? like with dqlite/rqlite with sqlite? or does there have to be some inherent mechanisms withIN the database to support distributed versions?
There are generic distributed consensus algorithms out there. The most famous are Paxos and Raft. In theory, you can jam those on top of any system you like, as long as it has well-defined state transitions.
Making it fast - or usable at all in the presence of heavy contention - is another story. Distributing a write-heavy workload over a cluster is useless if the cluster ends up rejecting most updates because they get preempted by some other write. Solving that problem usually means analyzing the underlying system to figure out which parts need to be truly atomic and which you can get away with doing in parallel. That job is a) really complex and b) filled with opportunities to make significant performance gains in exchange for weaker safety guarantees, like losing committed writes in a crash, or allowing individual nodes to reorder independent writes.
You should check out http://jepsen.io/analyses if this stuff interests you.