SQLite uses a memory page mechanism. You can define the page size. With a static page size you can divide the chunks and with that you have an offset for each page chunk, or if you have the start and the end offset of the bytes, you can also solve the page offset with that info.
If you only implement the filesystem shims, you will receive everything already figure it out, and the btree engine(storage) will ask you for the given chunk of data where you can resolve to the right torrent chunk, download it and just care about delivering the bytes that were asked.
I deliver sqlite dbs over torrent and the torrent chunks are optimized for the sqlite page sizes which are 64K.
In my case i dont stream the database, but through filesystem VFS it can be done if i had a need for it.
The beauty here lies in the SQLite architecture and the abstraction over pages.
If you only implement the filesystem shims, you will receive everything already figure it out, and the btree engine(storage) will ask you for the given chunk of data where you can resolve to the right torrent chunk, download it and just care about delivering the bytes that were asked.
I deliver sqlite dbs over torrent and the torrent chunks are optimized for the sqlite page sizes which are 64K.
In my case i dont stream the database, but through filesystem VFS it can be done if i had a need for it.
The beauty here lies in the SQLite architecture and the abstraction over pages.