7 ms·

> immudb is the first database which allows you to do queries across time. I don't think it is e.g. Datomic already had this for a long time, no?

branko_d 5y ago
Oracle has had flashback queries for a long time. Though this does not do what immudb claims: > immudb is the first database to provide tamper-evident data management, immutable history and client-cryptographic proof. And: > Clients do not need to trust the server and every new client adds trust to the deployment
waheoo 5y ago
Yes. https://youtube.com/watch?v=Cym4TZwTCNU https://youtube.com/watch?v=Cym4TZwTCNU
endymi0n 5y ago
Datomic does, so does Oracle, Snowflake and BigQuery.
- CharlesW 5y ago
  Teradata Vantage, too.
dspillett 5y ago
Several databases (MS SQL Server, MariaDB, Postgres with appropriate extension) support system versioned temporal tables (added in the SQL2011 standard, though I don't know if any DB entirely follows the standard) which I'm pretty sure counts as "queries across time". Maybe they are claiming to be the first with it built-in as a core part of the engine that it is specifically optimised for, but even that might not be true.
- refset 5y ago
  > even that might not be true It's not. For example, see SAP HANA's "Timeline Index" https://websci.informatik.uni-freiburg.de/publications/sigmod2013-timeline https://websci.informatik.uni-freiburg.de/publications/sigmo...
deleted 5y ago
[deleted]
chatmasta 5y ago
We're building something similar to this at Splitgraph, at least in the sense that we have immutable data in a Postgres-compatible DB with point-in-time queries across versioned, addressable snapshots. In our case, we apply the idea of immutability to "data images" that are analogous to Docker images. You build and push them in the same way, and then you can reference any "image" (version) [0] of data by addressing it with the correct tag. For example, here is a link to a live query on our Data Delivery Network (DDN) that runs a JOIN on two daily snapshots (20200809 and 20200810). [1] In this case, these images are the result of a daily script that builds and pushes a new image each day. The storage costs are minimal, as each new image only needs to store the changed rows, rather than a duplicative snapshot. Each immutable image is comprised of a set of small content-addressable cstore fragments uploaded to object storage, which we only load into the database when they become necessary to satisfy a query. When a query arrives at the DDN, we intercept it at the network level by scripting PgBouncer with embedded Python to orchestrate the infrastructure required to answer the query. The embedded code parses the AST of the query for table references, which it uses to "mount" a temporary schema for serving the query. The temporary schema includes an FDW that implements a "layered querying" protocol (think AUFS) to lazily download only the fragments required to satisfy the query. (Also, we support live data. But that's for another time!) [0] https://www.splitgraph.com/docs/concepts/images https://www.splitgraph.com/docs/concepts/images [1] https://www.splitgraph.com/workspace/ddn?layout=hsplit&query=SELECT%0A++++new.domain+AS+domain%2C%0A++++new.id+AS+id%2C%0A++++new.name+AS+name%0AFROM%0A++++%22splitgraph%2Fsocrata%3A20200809%22.datasets+old%0ARIGHT+OUTER+JOIN%0A++++%22splitgraph%2Fsocrata%3A20200810%22.datasets+new%0AON%0A++++old.id+%3D+new.id%0AWHERE%0A++++old.id+IS+NOT+DISTINCT+FROM+NULL+AND+new.domain+%3D+%27data.texas.gov%27%0A https://www.splitgraph.com/workspace/ddn?layout=hsplit&query...
cbsmith 5y ago
Yeah, that line was a real head scratcher. I think someone in the marketing department got a bit ahead of their reality.
- foobarbazetc 5y ago
  It’s not marketing as much as it is “try to get a patent for something that’s been done for decades by doing it slightly differently”.
foobarbazetc 5y ago
Yeah, it’s not. Which makes the rest suspect.
ignoramous 5y ago
Doesn't Bigtable, according to the 2006 paper, allow for this too? > Each cell in a Bigtable can contain multiple versions of the same data; these versions are indexed by timestamp. Bigtable timestamps are 64-bit integers. They can be assigned by Bigtable, in which case they represent realtime in microseconds... https://research.google/pubs/pub27898.pdf https://research.google/pubs/pub27898.pdf
deleted 5y ago
[deleted]

branko_d 5y ago

Oracle has had flashback queries for a long time. Though this does not do what immudb claims: > immudb is the first database to provide tamper-evident data management, immutable history and client-cryptographic proof. And: > Clients do not need to trust the server and every new client adds trust to the deployment

waheoo 5y ago

Yes. https://youtube.com/watch?v=Cym4TZwTCNU https://youtube.com/watch?v=Cym4TZwTCNU

endymi0n 5y ago

Datomic does, so does Oracle, Snowflake and BigQuery.

CharlesW 5y ago
Teradata Vantage, too.

dspillett 5y ago

Several databases (MS SQL Server, MariaDB, Postgres with appropriate extension) support system versioned temporal tables (added in the SQL2011 standard, though I don't know if any DB entirely follows the standard) which I'm pretty sure counts as "queries across time". Maybe they are claiming to be the first with it built-in as a core part of the engine that it is specifically optimised for, but even that might not be true.

refset 5y ago
> even that might not be true It's not. For example, see SAP HANA's "Timeline Index" https://websci.informatik.uni-freiburg.de/publications/sigmod2013-timeline https://websci.informatik.uni-freiburg.de/publications/sigmo...

deleted 5y ago

[deleted]

chatmasta 5y ago

We're building something similar to this at Splitgraph, at least in the sense that we have immutable data in a Postgres-compatible DB with point-in-time queries across versioned, addressable snapshots. In our case, we apply the idea of immutability to "data images" that are analogous to Docker images. You build and push them in the same way, and then you can reference any "image" (version) [0] of data by addressing it with the correct tag. For example, here is a link to a live query on our Data Delivery Network (DDN) that runs a JOIN on two daily snapshots (20200809 and 20200810). [1] In this case, these images are the result of a daily script that builds and pushes a new image each day. The storage costs are minimal, as each new image only needs to store the changed rows, rather than a duplicative snapshot. Each immutable image is comprised of a set of small content-addressable cstore fragments uploaded to object storage, which we only load into the database when they become necessary to satisfy a query. When a query arrives at the DDN, we intercept it at the network level by scripting PgBouncer with embedded Python to orchestrate the infrastructure required to answer the query. The embedded code parses the AST of the query for table references, which it uses to "mount" a temporary schema for serving the query. The temporary schema includes an FDW that implements a "layered querying" protocol (think AUFS) to lazily download only the fragments required to satisfy the query. (Also, we support live data. But that's for another time!) [0] https://www.splitgraph.com/docs/concepts/images https://www.splitgraph.com/docs/concepts/images [1] https://www.splitgraph.com/workspace/ddn?layout=hsplit&query=SELECT%0A++++new.domain+AS+domain%2C%0A++++new.id+AS+id%2C%0A++++new.name+AS+name%0AFROM%0A++++%22splitgraph%2Fsocrata%3A20200809%22.datasets+old%0ARIGHT+OUTER+JOIN%0A++++%22splitgraph%2Fsocrata%3A20200810%22.datasets+new%0AON%0A++++old.id+%3D+new.id%0AWHERE%0A++++old.id+IS+NOT+DISTINCT+FROM+NULL+AND+new.domain+%3D+%27data.texas.gov%27%0A https://www.splitgraph.com/workspace/ddn?layout=hsplit&query...

cbsmith 5y ago

Yeah, that line was a real head scratcher. I think someone in the marketing department got a bit ahead of their reality.

foobarbazetc 5y ago
It’s not marketing as much as it is “try to get a patent for something that’s been done for decades by doing it slightly differently”.

foobarbazetc 5y ago

Yeah, it’s not. Which makes the rest suspect.

ignoramous 5y ago

Doesn't Bigtable, according to the 2006 paper, allow for this too? > Each cell in a Bigtable can contain multiple versions of the same data; these versions are indexed by timestamp. Bigtable timestamps are 64-bit integers. They can be assigned by Bigtable, in which case they represent realtime in microseconds... https://research.google/pubs/pub27898.pdf https://research.google/pubs/pub27898.pdf

deleted 5y ago

[deleted]