SQLite is great. For an unusual application see actordb.com - a server side database that uses a large number of independent SQLite databases.
Work on SQLite4 has concluded
81–90 of 161 posts
Re: Work on SQLite4 has concluded
#82SQLite is great. For an unusual application see actordb.com - a server side database that uses a large number of independent SQLite databases.
Woah, that's awesome! Any performance information anywhere?
Re: Work on SQLite4 has concluded
#83SQLite is one of those awesome things that's the exact opposite of magic. It's beautiful, jaw dropping, engineering that exercises so many technical muscles. The number of oddball, often critical, places where I've found SQLite being used would defy belief. As far as I can tell, the "expected" place for SQLite to work seems to be almost anything that's not your normal dB driving some web-based CRUD app...all kinds of…
> your normal dB driving some web-based CRUD app
That can totally be handled with SQLite.
Re: Work on SQLite4 has concluded
#84Earlier quoted context omitted.
I've had the chance to hear Richard Hipp talk about SQLite yesterday! He mentioned that the LSM tree storage engine is available as an extension to sqlite3. More specifically, he mentioned that he didn't really get the performance improvements he had hoped for, for insertion-heavy use cases. I think part of this is because of a fundamental limitation of sqlite that it's an embedded database that has to persist data o…
Perhaps I'm misunderstanding you, but sqlite supports ramdisks/"In-memory databases" https://www.sqlite.org/inmemorydb.html Perhaps the key (ha!, pun) is that you're talking about using RAM _and_ disk with the RAM being for caching/fast access that eventually hits the disk. Whereas, I think, in this case sqlite is either on the disk, or in RAM. There is no multiple tiers. Correct me if I'm off here. Thanks.
> Perhaps the key (ha!, pun) is that you're talking about using RAM _and_ disk with the RAM being for caching/fast access that eventually hits the disk.
This is closer to what I mean but not quite. Specifically, in-memory (or main-memory) is a technical term that talks about a specific type of database that focuses on doing operations /mostly/ in memory, with some spillover to disk as necessary, but only as an edge case. You usually then handle persistence with a sequential transaction log, perhaps in NVDIMM storage if you have some. This is in contrast to other systems where the memory is a buffer, but the "actual stuff" happens on disk. There is of course many hybrid schemes - it's really more of a spectrum. Some examples: SAP HANA, ArangoDB, MapD, MemSQL, MS SQL Server Hekaton.
There's also a lot of techniques that come with this style of thinking - often these are column stores, and often since these databases don't really hit disk, the bottleneck is moving data in and out of memory to the CPU caches, and sometimes just CPU speed. Often these use lightweight compression and SIMD instructions to tackle those problems.
So SQLite's "in-memory" database scheme doesn't quite count as something like this, it's more of a disposable database. But that's ok - it's not bad, it's just a different thing.
> Whereas, I think, in this case sqlite is either on the disk, or in RAM. There is no multiple tiers.
See the thread above - I kind of assumed this was the case, but like you mentioned, it looks like with the LSM implementation it does kind of sort of have a memory component - it lasts until you close the database "connection", and gets flushed often.
Re: Work on SQLite4 has concluded
#85Earlier quoted context omitted.
It's basically the Perl 5 of the DB world.
Perl 6 you mean?
I read that as: it gives the impression it's been here forever, it's still being actively maintained, and will be for the foreseeable future. Benefiting from the “future” (sqlite4/perl6) at a slow but steady peace. So, really like Perl 5.
Re: Work on SQLite4 has concluded
#86Earlier quoted context omitted.
>SQLite License. Warranty of title and perpetual right-to-use for the SQLite source code. Obtaining A License To Use SQLite Even though SQLite is in the public domain and does not require a license, some users want to obtain a license anyway. Some reasons for obtaining a license include: Your company desires warranty of title and/or indemnity against claims of copyright infringement. You are using SQLite in a jurisdi…
Hwaci is a U.S. company, and the U.S. recognizes public domain. Therefore, no contributor can sue Hwaci in the U.S. for selling SQLite licenses.
I guess the question is what prevents those contributors from suing the licensee (or even Hwaci) in the country that doesn't recognize public domain?
I assume we'll never find out because contributors obviously don't intend to sue anyone if they release their code to the public domain, but it's strange that a company would be comfortable buying a possibly illegitimate license when they're uncomfortable with a public domain declaration.
Re: Work on SQLite4 has concluded
#87Earlier quoted context omitted.
Everything I hear about SQLite3 always suggests that, essentially, it is considered "done". It does what it is supposed to do with great performance. There is nothing major left to do. If it doesn't meet your needs, pick a different SQL database. Which, while a totally alien concept in the modern software world, is actually a pretty cool thought. (I'm sure under the hood bugs are getting fixed and all)
Well, obviously they should rewrite it in Rust.
Although i get the joke, it would be a fun and interesting experiment wouldn't it ? Espacially since the sqlite test suite is so exhaustive.
Re: Work on SQLite4 has concluded
#88SQLite is one of those awesome things that's the exact opposite of magic. It's beautiful, jaw dropping, engineering that exercises so many technical muscles. The number of oddball, often critical, places where I've found SQLite being used would defy belief. As far as I can tell, the "expected" place for SQLite to work seems to be almost anything that's not your normal dB driving some web-based CRUD app...all kinds of…
> your normal dB driving some web-based CRUD app That can totally be handled with SQLite.
I have several crud apps running sql. With moderate write load and a good concurrency write error handling code it works very well. Good when the product size is not worth a postgres full blown setup.
Re: Work on SQLite4 has concluded
#89Every time I see something about sqlite, I become sad. It reminds me of the failure of the w3 standards comittee to accept it as web standard. They rejected sqlite because no competing implementation existed. Furthermore, "public domain" license of the software was also a hurdle, iirc.
We literally lost several years for web app advancement because of that. Reading the decision making, it seemed like overly-legalistic engineers, but I'm open to conspiracy theories that this decision enhanced mobile app store adoption.
No, it was Mozilla who killed it[1] over Apple and Google's strong objections.
[1] For pretty much complete nonsense NIH and standards-lawyering reasons.