Show HN: Mongita is to MongoDB as SQLite is to SQL • Hacker News Board

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#91

Post by hardwaresofton » Sat, Apr 24, 2021, 12:14 AM UTC

thomas4019 wrote: post #89

hardwaresofton wrote: post #21

Cool project but I have to admit I sure wish this was written on top of SQLite, rather than just mentioned it, implementing a query language shim for MongoDB on SQLite would be an amazing project. In the absence of such a project though, this is a pretty great alternative to have.

I created something like this for PostgreSQL. It's a Node.js service that implements the MongoDB wire protocol and converts the query to use jsonb. It works pretty well, but it also got increasingly hard to make it compatible because MongoDB has a lot of quirks.

As a F/OSS freeloader, I would very much like you a link to this project... Feels like something I'd contribute to or do something crazy like try to start a business (2ndquadrant/edb style) on.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#92

Post by wokwokwok » Sat, Apr 24, 2021, 12:34 AM UTC

pbreit wrote: post #90

wokwokwok wrote: post #71

Earlier quoted context omitted.

It’s not even remotely self contained though, so how is the comparison relevant?

Looked self-contained to me.

It literally runs on an interpreter; that’s the opposite of self contained.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#93

Post by scottrogowski » Sat, Apr 24, 2021, 2:33 AM UTC

bvrmn wrote: post #87

scottrogowski wrote: post #57

Earlier quoted context omitted.

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.

O(n) cache size is a very novel approach in computer science. This "cache" is crucial part of implementation and limits project applicability.

O(n) cache size is fine (and IMHO, preferable) for small datasets. For large datasets, you're correct. Cache eviction is important when memory usage gets too high. I didn't have it explicitly on the README as something that needs to get done but now it is. So thank you for pointing it out.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#94

Post by scottrogowski » Sat, Apr 24, 2021, 2:36 AM UTC

kevincox wrote: post #78

scottrogowski wrote: post #19

Earlier quoted context omitted.

Author here. That's exactly it. I think it would be very difficult to completely beat SQLite with a Python library. My goal wasn't to beat it but to have performance that's within an order of magnitude which I think I've achieved. In my opinion, the MongoDB interface has a lot of advantages over SQL that make sense in a lot of use cases. Certainly, there are times when a traditional relational database is the right c…

Have you considered using SQLite (and probably JSON1) as the backend and just making an API that amps from the Mongo API to SQLite? It seems like this would probably have better read performance and the battle-tested reliability that we love from SQLite.

Yup. Considered it. I initially settled on no because it might compromise the design goal of 1:1 MongoDB/PyMongo compatibility. Now the idea is being revived as an option alongside the two existing backends. I am concerned there might be an issue with some square-peg high level MongoDB operations simply not fitting into the SQLite round-hole but it's certainly something that's being investigated.

Re: Show HN: Mongita is to MongoDB as SQLite is to SQL

#95

Post by thomas4019 » Mon, Apr 26, 2021, 9:29 PM UTC

hardwaresofton wrote: post #91

thomas4019 wrote: post #89

Earlier quoted context omitted.

I created something like this for PostgreSQL. It's a Node.js service that implements the MongoDB wire protocol and converts the query to use jsonb. It works pretty well, but it also got increasingly hard to make it compatible because MongoDB has a lot of quirks.

As a F/OSS freeloader, I would very much like you a link to this project... Feels like something I'd contribute to or do something crazy like try to start a business (2ndquadrant/edb style) on.

Thanks! I didn't realize I put the link. Here it is, http://github.com/thomas4019/pgmongo. I'd love to hear your thoughts on it and am happy to answer any questions.