I thought I was decent at SQL until I saw this. Nice article!
Stochastic gradient descent written in SQL
11–20 of 187 posts
Re: Stochastic gradient descent written in SQL
#12This is genius I love it.
On stream inference with something like "continuous" data in the same structure I think is the final material form for "AI" so this is a great step towards that
Thanks for the writeup
Re: Stochastic gradient descent written in SQL
#13>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL.
First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powerful than we think, they're not going to go away, only get better, and having the data and the logic in the same space really removes tons of headaches. ML models, transformation of data, generating json for an API can all be done within the database rather than outside scripting language.
Are others seeing this? Are the current tradeoffs just that more people know python vs sql or database specific languages to where moving logic to postgres or snowflake is looked down on?
Re: Stochastic gradient descent written in SQL
#14This is really interesting, but a basic part I don't understand: What would it actually look like to run this on a live dataset? If I understand correctly: you'd run the recursive query, it produces results for every step, effectively showing you the progression of output over time, and then once it hits "present day", it completes and stops? How would you generate results going forward? I.E. A minute elapses after t…
Good question. I touched upon this in the conclusion. Basically, if you run this in a streaming SQL database, such as Materialize, then you would get a true online system which doesn't restart from scratch.
Did you try running it using DuckDB?
Re: Stochastic gradient descent written in SQL
#15>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
I have yet to see a decent IDE or system which allows great version control, unit testing and collaboration with SQL source code.
So I think a lot of the reluctance is from practical concerns.
Re: Stochastic gradient descent written in SQL
#16>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
Absolutely.
Consider too that PostgreSQL databases support different languages, like Python.
Loads of for-profit companies have tried to cash in on this. SAP HANA is one of the ones I've had recent experience with. It is unfortunately a poor implementation. The right architecture tends to be: put your model behind an API interface, not internal on the system. Train your model separately from production systems, and so on.
You might also be interested in checking out MLOps platforms like Kubeflow, Flyte, and others.
Re: Stochastic gradient descent written in SQL
#17>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
had a very good chat with https://postgresml.org/ last week which is focusing on bringing ML to postgres: https://youtu.be/j8hE8-jZJGU
Re: Stochastic gradient descent written in SQL
#18You might want to consider checking out ClickHouse which supports many ML functions natively:
- stochasticLinearRegression (https://clickhouse.com/docs/en/sql-reference/aggregate-funct...)
- stochasticLogisticRegression (https://clickhouse.com/docs/en/sql-reference/aggregate-funct...)
Re: Stochastic gradient descent written in SQL
#19>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
+1 sql is extremely elegant composable and is under rated
Postgres is very powerful. While I sought a short detour in nosql Mongodb land now back to Mysql Postgresql sql territory and glad for it
Being able to generate views is and stored procedures is useful as well.having sql Take over more like ml, gradient descent does open up good possibility.
Also since sql is declarative it Makes it so it's rather easier than imperative scripting languages
Re: Stochastic gradient descent written in SQL
#20>A machine learning algorithm which can be trained using SQL opens a world of possibilities. The model and the data live in the same space. This is as simple as it gets in terms of architecture. Basically, you only need a database which runs SQL. First paragraph of the conclusion, and this very much fits with the mindset that's been growing in me in the data world over the past few years. Databases are much more powe…
I have yet to see a decent IDE or system which allows great version control, unit testing and collaboration with SQL source code. So I think a lot of the reluctance is from practical concerns.
We store individual sql files in github and keep them in separate folders
This is very simple and scales well for our purposes