3 ms·

is there something fundamental from us making a new frontend to something like postgres? I think all the solutions that compile to SQL kinda work but it would b

by klysm 4y ago

is there something fundamental from us making a new frontend to something like postgres? I think all the solutions that compile to SQL kinda work but it would be nice to have a new native interface that sucks less.

vkazanov 4y ago
Nope. Nothing but industry-wide inertia is so massive by now that it just doesn't make sense to switch. Nosqls tried hard and went nowhere. What i find funny is that most dbs translate sql into an internal representation that is remarkably similar to a proper relational algebra and optimise on that. I'd really just prefer the alebraic language as described in the original ages old paper. There were also a few dbs trying to push sql-but-better languages... haven't heard about them for a while.
jstrong 4y ago
I have experimented with a different query model from sql for time series data. A query took the form of a Rhai script. (Rhai is a scripting language that has great interop with rust, so it was similar to how lua would be used to script parts of a game.) Each query script would act on a few objects in global scope: `db` (handle to database), `start`, and `end` (time range of grafana dashboard that query was for). I found being able to write imperative (rather than declarative) code to build a query to be extremely powerful, especially for storing variables and looping over things. e.g. query script - just to get a feel for it: let dalmp = db.ts("pjm-da-lmp/western-hub") // ie retrieve the timeseries named 'pjm..' .with_time_range(start, end); let rtlmp = db.ts("pjm-5min-lmp-rt-lmp/western-hub") .with_time_range(start, end) .resample("1h", "mean"); let da_err = rtlmp.diff(dalmp); #{ dalmp: dalmp, rtlmp: rtlmp, da_err: da_err, } A query script would be expected to return a dictionary-like object. the keys would be used as labels and the values would each be a time series object. This is not the perfect solution for every problem but though it might be interesting to see an example of a very different approach to querying compared to sql.

by klysm 4y ago

vkazanov 4y ago

Nope. Nothing but industry-wide inertia is so massive by now that it just doesn't make sense to switch. Nosqls tried hard and went nowhere. What i find funny is that most dbs translate sql into an internal representation that is remarkably similar to a proper relational algebra and optimise on that. I'd really just prefer the alebraic language as described in the original ages old paper. There were also a few dbs trying to push sql-but-better languages... haven't heard about them for a while.

jstrong 4y ago

I have experimented with a different query model from sql for time series data. A query took the form of a Rhai script. (Rhai is a scripting language that has great interop with rust, so it was similar to how lua would be used to script parts of a game.) Each query script would act on a few objects in global scope: `db` (handle to database), `start`, and `end` (time range of grafana dashboard that query was for). I found being able to write imperative (rather than declarative) code to build a query to be extremely powerful, especially for storing variables and looping over things. e.g. query script - just to get a feel for it: let dalmp = db.ts("pjm-da-lmp/western-hub") // ie retrieve the timeseries named 'pjm..' .with_time_range(start, end); let rtlmp = db.ts("pjm-5min-lmp-rt-lmp/western-hub") .with_time_range(start, end) .resample("1h", "mean"); let da_err = rtlmp.diff(dalmp); #{ dalmp: dalmp, rtlmp: rtlmp, da_err: da_err, } A query script would be expected to return a dictionary-like object. the keys would be used as labels and the values would each be a time series object. This is not the perfect solution for every problem but though it might be interesting to see an example of a very different approach to querying compared to sql.