Live data from Hacker News

Hosting SQLite databases on GitHub Pages or any static file hoster

phiresky.github.io

91–100 of 252 posts

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#91
post #74

The question I had is answered by this line of code: xhr.setRequestHeader("Range", "bytes=" + from + "-" + to); I am a little surprised you can just do that. In https://github.com/phiresky/sql.js-httpvfs/blob/master/src/l...

I've learnt about this by using https://www.biodalliance.org

It's an embedded genome viewer, you can just point it at a multigigabyte reference files and .seg files and it loads super quick

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#92

This is hilariously clever. Using the "Range" HTTP header to read chunks of the database file absolutely works! But to be clear, there's no write equivalent, is there? You can't use "Range" with a PUT request.

TA was clear - there's no way to write, since static file hosting doesn't support dynamic write to begin with.

However, I imagine a service to support your scenario could be written in a standard back-end server language like Go or JS. The challenges involved would be much greater, however -- how to handle concurrency in particular. I suspect one would do better to just run PostgreSQL behind a web API.

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#93

This is fantastically creative. And the author does a great job of starting out by describing why this is useful. And then using SQLite to insert and update DOM elements? Holy cow, icing on the cake. Unlike the first part, there’s no explanation of why you’d want to do that. But by that point I was so drawn in that I didn’t care and was just enjoying the ride.

Yeaah I felt like at that point the article was already long enough so I didn't bother describing the DOM part too much - even though I spent more time implementing that than I did implementing the rest ;) Basically SQLite has a virtual table mechanism [1] where you have to define a few functions that figure out how to scan your "fake" table / which indices to use and then how to read / write the actual data. I hook…

[deleted]

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#94
post #91
post #74

The question I had is answered by this line of code: xhr.setRequestHeader("Range", "bytes=" + from + "-" + to); I am a little surprised you can just do that. In https://github.com/phiresky/sql.js-httpvfs/blob/master/src/l...

I've learnt about this by using https://www.biodalliance.org It's an embedded genome viewer, you can just point it at a multigigabyte reference files and .seg files and it loads super quick

Here is direct link to GitHub with the usage: https://github.com/dasmoth/dalliance/search?q=bytes%3D%27&ty...

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#95
post #74

The question I had is answered by this line of code: xhr.setRequestHeader("Range", "bytes=" + from + "-" + to); I am a little surprised you can just do that. In https://github.com/phiresky/sql.js-httpvfs/blob/master/src/l...

Range headers are a pretty standard tools to e.g. continue interrupted downloads and similar.

Any well designed system, especially if it has static sources and is server cached should support it.

Surprisingly many web-frameworks don't support it out of the box, or don't support it well.

Either way gh-pages are static content and probably with some server side regional caches, so I'm not surprised it works.

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#96
post #41

Pop open the network pane in the browser tools and try running this SQL query for a demo of how clever this is: select country_code, long_name from wdi_country order by rowid desc limit 100 It fetches just 54.2KB of new data (across 49 small HTTP requests) to return 100 results - from a statically hosted database file that's 668.8MB! I have an animated GIF demo of this here: https://twitter.com/simonw/status/13889338…

Huh, that's actually kind of a worst case I didn't think about: Since you're doing a reverse table scan my "sequential access" detection doesn't kick in. If you do the same query but with a forward scan it should fetch roughly the same amount of data but only do like 5 HTTP requests since the request size doubles for every sequential access. e.g.: select country_code, long_name from wdi_country where rowid >= 164 ord…

I solved a similar problem recently: given a stream of data, how should you choose packet size in an online way to minimize regret (a linear combination of spare capacity of last packet and total packets used).

Turns out doubling isn’t the best strategy. The optimal solution is actually to add a constant increment to packet size. How much depends on relative cost of the terms in the regret function.

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#97

This is hilariously clever. Using the "Range" HTTP header to read chunks of the database file absolutely works! But to be clear, there's no write equivalent, is there? You can't use "Range" with a PUT request.

TA was clear - there's no way to write, since static file hosting doesn't support dynamic write to begin with. However, I imagine a service to support your scenario could be written in a standard back-end server language like Go or JS. The challenges involved would be much greater, however -- how to handle concurrency in particular. I suspect one would do better to just run PostgreSQL behind a web API.

That's basically re-inventing the Database but on the client side. We have gone a long way but we are closer to having the server side just as a data store.

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#98
post #6

Earlier quoted context omitted.

The main restriction is that the DB really needs well fitting indexes, otherwise querying is really slow and fetches a lot of data. Regarding writing: You could of course implement a writing API with POST requests for changing pages of the database - but then you would lose most of the benefits of this (not requiring any special kind of server). I also thought about implementing a kind of overlay filesystem, where ch…

Since you can do static hosting from a git repo, I wonder if you could directly push your changes to your git repo and have your CI/CD solution just deploy it instead? There has to be a git.js implementation out there and you could move the DB to it's own repo and create an https access token (for Github)... the issue there is that someone could use that token to commit whatever to your database repo.

Maybe forcing the user to login with GitHub would be an option? And the changes to the database could be modelled as pull requests?

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#99
In a similar vein, I've mentioned this before, but if you're doing Python stuff, you can use the apsw package (not the one in PyPi, though) to write a VFS layer that SQLite will use to read the database.

I've used this for the same basic idea as this article, only letting me store SQLite databases in AWS's S3 that I can access with AWS APIs so they don't need to be public. It works well, though it's absolutely not for every use case, the overhead is considerable.

I even used it once to read SQLite database files in a zip file stored in S3 without having any local storage to use. Not one of my prouder moments, but hey, I coded my way out of the corner someone else designed for me.

Re: Hosting SQLite databases on GitHub Pages or any static file hoster

#100
post #43

Earlier quoted context omitted.

So assuming no country has a name longer than 98 characters and that all country codes are 2 characters, that is over 500% overhead? Are you missing a /s in your post?

Have you actually read the article? SQLite is unmodified, and thinks it runs on a virtual file system, which fetches file chunks via HTTP range headers. It's REALLY impressive that you only need to read 54 KB out of 700 MB, to fetch the records.

It's impressive on one hand.

On the other it's still a lot of overhead.

Post reply on HN