sqltorrent
fac-rs
Our great sponsors
sqltorrent | fac-rs | |
---|---|---|
5 | 1 | |
269 | 8 | |
1.1% | - | |
0.0 | 5.6 | |
about 8 years ago | 9 months ago | |
C | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sqltorrent
-
BTFS (BitTorrent Filesystem)
Or even better store data as an sqlite file that is full-text-search indexed. Then you can full-text search the torrent on demand: https://github.com/bittorrent/sqltorrent
- SQLite BitTorrent Vfs
-
How to circumvent Sci-Hub ISP block
"There was that project some guy posted a while back that used a combination of sqlite and partial downloads to enable searches on a database before it was downloaded all the way."
- Hosting SQLite databases on GitHub Pages (or any static file hoster)
-
Distributed search engines using BitTorrent and SQLite
Interesting question. I looked at the source code to understand that.
SQLite knows where to look for when you open a SQLite database and you run a query, right? It just asks the underlying filesystem to provide N bytes starting from an offset using a C function, then it repeats the same operation on different portions of the file, it does its computation and everybody is happy.
The software relies on sqltorrent, which is a custom VFS for SQLite. That means that SQLite function to read data from a file stored in the filesystem is replaced by a custom function. Such custom code computes which Torrent block(s) should have the highest priority, by dividing the offset and the number of bytes that SQLite wants to read by the size of the torrent blocks. It is just a division.
See: https://github.com/bittorrent/sqltorrent/blob/master/sqltorr...
fac-rs
-
Hosting SQLite databases on GitHub Pages (or any static file hoster)
I wrote a similar thing in Rust for a Factorio mod manager - mods are hosted on the remote HTTP server as ZIP files and the mod manager needs a single info.json file from the ZIP for the mod metadata, so it avoids downloading the whole mod and then unpacking it by building a file abstraction that uses HTTP range queries to download chunks. For ZIP files the directory is stored at the end at an unknown offset, so the read pattern is to gradually seek backwards from the end until you find the start of the directory, then find the file entry, then read the file.
I didn't fiddle with the window sizes like the TFA, but I did optimize it so that reading chunk N+1 of the file reused the response readed of chunk N rather than making a new request. Furthermore I keep an LRU cache of the last three chunks rather than keep all of them in memory, because the ZIP files are each only read once.
[1]: https://github.com/Arnavion/fac-rs/blob/master/src/solve/web...
[2]: https://github.com/Arnavion/fac-rs/blob/master/src/solve/zip...
What are some alternatives?
sql.js-httpvfs - Hosting read-only SQLite databases on static file hosters like Github Pages
LevelDB - LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.
torrent-net - Distributed search engines using BitTorrent and SQLite
alasql - AlaSQL.js - JavaScript SQL database for browser and Node.js. Handles both traditional relational tables and nested JSON data (NoSQL). Export, store, and import data from localStorage, IndexedDB, or Excel.
ipfs - Peer-to-peer hypermedia protocol
dalliance - Interactive web-based genome browser.
datasette - An open source multi-tool for exploring and publishing data
IPSQL - InterPlanetary SQL
duckdb - DuckDB is an in-process SQL OLAP Database Management System
apsw - Another Python SQLite wrapper