I would be interested in the differences between this and protomaps
Basically Protomaps / PMTiles allows you to do this serverless, but it has it's downsides.
There are two ways to use PMTiles with Cloudflare:
- Putting the file in a public bucket and use HTTP range requests.
- Deploy a worker to access it.
For the range request version, you can test PMTiles here: https://pmtiles.io/?url=https%3A%2F%2Fdata.source.coop%2Fpro....
It loads in 8-10 sec for me on a cold start. Of course it gets faster if many of us try to request it at the same time, but if you check it once per day for example, it'll be really slow, up to 10 sec.
Compare that with OpenFreeMap here: https://openfreemap.org/quick_start
It's near instant for me. (I know it's not full screen but you can make the app and then see how it's in full screen).
For the Cloudflare Workers version, I didn't find any publicly available full planet test, so I don't know the performance, but Workers are not free. It might not matter for a small project, but the $0.30/million requests per month can easily add up if your project gets popular.
In terms of OpenFreeMap, hosting it on a Cloudflare Worker would be prohibitively expensive.
The latency you see on https://pmtiles.io/?url=https%3A%2F%2Fdata.source.coop%2Fpro... is representative of how PMTiles works on AWS S3, coming from the us-west-2 region. It will be reasonable to load for those in the western US and likely quite slow from Europe or Oceania.
If you want to make a direct comparison of Protomaps to OpenFreeMap, you need to compare serving OpenFreemap with NGINX from btrfs on disk, to running `pmtiles serve` on a `.pmtiles` file on disk, as described here: https://docs.protomaps.com/deploy/server
The OpenFreeMap page for me (in Taiwan) takes 1-2 seconds per tile, which is more than double the load tile for the PMTiles in us-west-2 example linked above.
The best solution to get latency competitive with commercial providers, for a global audience, is to cache tiles at CDN edge locations. I describe automated ways to do that with Cloudflare Workers and AWS Lambda + Cloudfront here:
https://docs.protomaps.com/deploy/cloudflare https://docs.protomaps.com/deploy/aws
I'm also experimenting with http://tigrisdata.com which lets you geo-distribute a static storage bucket like in this example: https://pmtiles.io/?url=https%3A%2F%2Fdemo-bucket.protomaps....
I can imagine workers to be fast, it's the range requests which are super slow. It's also outside of your control, it depends on how Cloudflare and S3 handles range requests to 90 GB files.
I think if you could make PMTiles split into files <10 MB, it'd be perfect with range requests.
I would be interested to see a comparison of Btrfs + nginx serving latency, vs `pmtiles serve` from https://github.com/protomaps/go-pmtiles on a PMTiles archive on disk. That would be a more direct comparison.
I think there's potentially some interesting use case for tiles in Btrfs volumes and incremental updates, which I haven't tackled in PMTiles yet!
The fact that there is no service running was the more important for me. Mostly for security and bugs. I had so many problems with various tile servers in production, they needed daily restarting, they had memory leaks, etc.
Basically I wanted to go nginx-only for security and to avoid tile server bugs.
For PMTiles the module is loadable directly as a Caddy plugin (https://docs.protomaps.com/deploy/server#caddyfile) which I prefer to nginx for security and bugs (and automatic SSL), and also enables serving PMTiles from disk or a remote storage bucket without a separate service running.
At that point, the difference between the two projects is mostly which schema is being used.
The nearest thing (and it's not really really similar, just related) that ZFS has is special VDEVs.
When you have an array of disks (usually "slow", like regular HDDs) you can attach to it another array of disks (usually very fast, like NVMe) where you can store metadata (file information) and optionally small files up to a size that you can define.
So for example you have a 50TB (or 500, who knows) array of SATA disks, and a small but superfast array of NVMe drives. Lets say 128GB. Or 512, or 1TB depending on you want to do.
File metadata is saved there, so doing a find, ls, tree... operation is now very fast. And if you save, for example, all files smaller than 32KB there (it will depend on your needs, also) all the small file operations will be way faster.