3 ms·
Nice, thanks. It seems like sometimes what we want is the state at a point in time (eg. for rolling back the database of a managed networked embedded device).
by jddj 3y ago
Nice, thanks.
It seems like sometimes what we want is the state at a point in time (eg. for rolling back the database of a managed networked embedded device).
Other times what we really want in these systems is state as of a point in time based on the current set of timestamped, (effectively) mutable facts.
- refset 3y agoI believe people interested in the latter are almost always interested in the former also, at least in the context of transactional systems (and particularly anything subject to complex regulatory requirements). Analytical systems are a different world where time seems to often be regarded as "just another dimension", but strong consistency and auditability are increasingly relevant there too, which is also a natural reflection of how a lot of modern OLAP systems operate internally using immutable snapshots of blob storage (see Snowflake, Iceberg, LakeFS etc.). I know there are definitely lots of potential tricks for making better use of a first-class understanding of time in analytics though, and not just treating it the same as other dimensions, e.g. https://duckdb.org/2023/09/15/asof-joins-fuzzy-temporal-lookups.html https://duckdb.org/2023/09/15/asof-joins-fuzzy-temporal-look... and https://materialize.com/blog/temporal-filters/ https://materialize.com/blog/temporal-filters/
- jddj 3y agoBoth great links, thanks. You're right, of course. We want both. As it turns out, AsOf in SQL is a problem I ran into just yesterday when ensuring that serialized report snapshots point to the correct historical versions of their resources.