go-sqlite3-stdlib
noria
go-sqlite3-stdlib | noria | |
---|---|---|
6 | 27 | |
123 | 4,925 | |
0.0% | 1.0% | |
0.0 | 0.0 | |
9 months ago | over 2 years ago | |
Go | Rust | |
GNU General Public License v3.0 or later | 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.
go-sqlite3-stdlib
-
SQLite: Past, Present, and Future
Adding user-defined functions to SQLite is not difficult, and the mechanism is quite flexible. You can create extensions and load them when you create the SQLite connection to have the functions available in queries. I wrote a blog post explaining how to do that using Rust, and the example is precisely a `regex_extract` function [0].
If you need them, you also have a "stdlib" implemented for Go [1] and a pretty extensive collection of extensions [2]
[0]: https://ricardoanderegg.com/posts/extending-sqlite-with-rust...
[1]: https://github.com/multiprocessio/go-sqlite3-stdlib
[2]: https://github.com/nalgeon/sqlean
- SQLite has pretty limited builtin functions
-
OctoSQL allows you to join data from different sources using SQL
OctoSQL is an awesome project and Kuba has a lot of great experience to share from building this project I'm excited to learn from.
And while building a custom database engine does allow you to do pretty quick queries, there are a few issues.
First, the SQL implemented is nonstandard. As I was looking for documentation and it pointed me to `SELECT * FROM docs.functions fs`. I tried to count the number of functions but octosql crashed (a Go panic) when I ran `SELECT count(1) FROM docs.functions fs` and `SELECT count() FROM docs.functions fs` which is what I lazily do in standard SQL databases. (`SELECT count(fs.name) FROM docs.function fs` worked.)
This kind of thing will keep happening because this project just doesn't have as much resources today as SQLite, Postgres, DuckDB, etc. It will support a limited subset of SQL.
Second, the standard library seems pretty small. When I counted the builtin functions there were only 29. Now this is an easy thing to rectify over time but just noting about the state today.
And third this project only has builtin support for querying CSV and JSON files. Again this could be easy to rectify over time but just mentioning the state today.
octosql is a great project but there are also different ways to do the same thing.
I build dsq [0] which runs all queries through SQLite so it avoids point 1. It has access to SQLite's standard builtin functions plus* a battery of extra statistic aggregation, string manipulation, url manipulation, date manipulation, hashing, and math functions custom built to help this kind of interactive querying developers commonly do [1].
And dsq supports not just CSV and JSON but parquet, excel, ODS, ORC, YAML, TSV, and Apache and nginx logs.
A downside to dsq is that it is slower for large files (say over 10GB) when you only want a few columns whereas octosql does better in some of those cases. I'm hoping to improve this over time by adding a SQL filtering frontend to dsq but in all cases dsq will ultimately use SQLite as the query engine.
You can find more info about similar projects in octosql's Benchmark section but I also have a comparison section in dsq [2] and an extension of the octosql benchmark with different set of tools [3] including duckdb.
Everyone should check out duckdb. :)
[0] https://github.com/multiprocessio/dsq
[1] https://github.com/multiprocessio/go-sqlite3-stdlib
[2] https://github.com/multiprocessio/dsq#comparisons
[3] https://github.com/multiprocessio/dsq#benchmark
-
One year as a solo dev building open-source data tools without funding
Hey Kuba!
> Especially on the community building aspect, it's really impressive that you've been able to spark so many communities on various platforms (Reddit, GitHub, Discord, etc.)!
Yeah it's been so cool to see so many people come together, hobbyists and professionals.
> On a more technical note, since dsq is based on the "load it into SQLite and query it from there" architecture, have you considered integrating with the plugin ecosystems of other existing projects based on that same architecture, like Datasette[0]? It seems like a way to add a lot of value to your tools without much work.
Interesting idea! I haven't looked into Datasette too much. And I haven't thought about plugins too much either. The most I've done is extend the SQLite standard library [0] and I hope to continue growing that. I'd be curious to hear what specifically people like from Datasette they'd like to see in dsq.
> On a more commercial note, overall I think tools like this are very hard to monetize, because right now they're just a fairly niche use case, between - as you mentioned - full blown data analytics platforms and observability query systems, as well as standard unix tools. Especially since if you need the analytics a lot, you'll probably have time to integrate it into your preferred analytics solution (like BigQuery). Do you have any thoughts on that?
My idea was always to focus on smaller and less mature organizations, probably ones that have been around for 10+ years. They aren't using BigQuery, they prefer to host everything themselves, and they don't yet realize there are tools like DataStation that they can easily run to make analytics easier.
I've worked at a bunch of companies like this so I know the market exists. Actually I have been surprised how many people outside of this market showed up in the DataStation community. I've seen Googlers, MS-ers, modern startups, data science teams show up interested in DataStation compared to what they're already using.
For me it's just been a matter of time (and funding) to build out the product to serve these communities commercially as a SaaS or enterprise product.
[0] https://github.com/multiprocessio/go-sqlite3-stdlib
- Show HN: A standard library for mattn/go-sqlite3
- A standard library for mattn/go-sqlite3 including best-effort date parsing, url parsing, math/string functions, and stats aggregation functions
noria
-
Relational is more than SQL
> Automatically managed, application-transparent, physical denormalisation entirely managed by the database is something I am very, very interested in.
Sounds a bit like Noria: https://github.com/mit-pdos/noria
-
JetBrains Noria
It feels more than a little bit coincidental to call it Noria when https://github.com/mit-pdos/noria exists (and has been posted about here on HN)... especially with the whole bit about incrementally computing changes.
-
Uplevel database development with DataSQRL: A compiler for the data layer
Is this similar in spirit to Noria?
https://github.com/mit-pdos/noria
-
Dozer: A scalable Real-Time Data APIs backend written in Rust
I assume you have studied Noria? https://github.com/mit-pdos/noria
-
What are the Rust databases and their benefits?
If you want to look how databases are implemented in rust try https://github.com/mit-pdos/noria
- Materialized View: SQL Queries on Steroids
-
Measuring how much Rust's bounds checking actually costs
Only tangentially related, but I wondered what were the difference between ReadySet and Noria, and they address this exact question in their repository I'm really glad to know that the ideas behind Noria didn't die when Noria was abandoned after /u/jonhoo graduated.
-
PlanetScale Boost serves your SQL queries instantly
:wave: Author of the paper this work is based on here.
I'm so excited to see dynamic, partially-stateful data-flow for incremental materialized view maintenance becoming more wide-spread! I continue to think it's a _great_ idea, and the speed-ups (and complexity reduction) it can yield are pretty immense, so seeing more folks building on the idea makes me very happy.
The PlanetScale blog post references my original "Noria" OSDI paper (https://pdos.csail.mit.edu/papers/noria:osdi18.pdf), but I'd actually recommend my PhD thesis instead (https://jon.thesquareplanet.com/papers/phd-thesis.pdf), as it goes much deeper about some of the technical challenges and solutions involved. It also has a chapter (Appendix A) that covers how it all works by analogy, which the less-technical among the audience may appreciate :) A recording of my thesis defense on this, which may be more digestible than the thesis itself, is also online at https://www.youtube.com/watch?v=GctxvSPIfr8, as well as a shorter talk from a few years earlier at https://www.youtube.com/watch?v=s19G6n0UjsM. And the Noria research prototype (written in Rust) is on GitHub: https://github.com/mit-pdos/noria.
As others have already mentioned in the comments, I co-founded ReadySet (https://readyset.io/) shortly after graduating specifically to build off of Noria, and they're doing amazing work to provide these kinds of speed-ups for general-purpose relational databases. If you're using one of those, it's worth giving ReadySet a look to get these kinds of speedups there! It's also source-available @ https://github.com/readysettech/readyset if you're curious.
-
PlanetScale Boost
It seems similar to MIT's Noria [1]
> Noria is a new streaming data-flow system designed to act as a fast storage backend for read-heavy web applications based on Jon Gjengset's Phd Thesis, as well as this paper from OSDI'18. It acts like a database, but precomputes and caches relational query results so that reads are blazingly fast. Noria automatically keeps cached results up-to-date as the underlying data, stored in persistent base tables, change. Noria uses partially-stateful data-flow to reduce memory overhead, and supports dynamic, runtime data-flow and query change.
[1] https://github.com/mit-pdos/noria
-
OctoSQL allows you to join data from different sources using SQL
Materialize is really neat, also checkout https://github.com/mit-pdos/noria. It inverts the query problem and processes the data on insert. Exactly like what most applications end up doing using a no-sql solution.
What are some alternatives?
sqlite-past-present-future - Performance evaluation and optimization of SQLite
zombodb - Making Postgres and Elasticsearch work together like it's 2023
octosql-plugin-postgres
timely-dataflow - A modular implementation of timely dataflow in Rust
sqlite-plus - The ultimate set of SQLite extensions
realtime - Broadcast, Presence, and Postgres Changes via WebSockets
octosql-plugin-random_data - OctoSQL plugin serving random data
TablaM - The practical relational programing language for data-oriented applications
mycelite - Mycelite is a SQLite extension that allows you to synchronize changes from one instance of SQLite to another.
readyset - Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
cargo-semver-checks - Scan your Rust crate for semver violations.
mysql-live-select - NPM Package to provide events on updated MySQL SELECT result sets