5 ms·

> The problem with Parquet is it’s static. Not good for use cases that involve continuous writes and updates. parquet is columnar storage, so it’s use case is

> The problem with Parquet is it’s static. Not good for use cases that involve continuous writes and updates. parquet is columnar storage, so it’s use case is lots of heavy filtering/aggregation within analytical workloads (OLAP). consistent writes / updates, i.e. basically transactional (OLTP), use cases are never going to have great performance in columnar storage. its the wrong format to use for that. for faster writes/updates you’d want row-based, i.e. CSV or an actual database. which i’m glad to see is where you kind of ended up anyway.

yorwba 2y ago
There's no reason why an update query that doesn't change the file layout and only twiddles some values in place couldn't be made fast with columnar storage. When you run a read query, there's one phase that determines the offsets where values are stored and another that reads the value at a given offset. For an update query that doesn't change the offsets, you can change the direction from reading the value at an offset to writing a new value to that location instead, and it should be plenty fast. Parquet libraries just don't seem to consider that use case worth supporting for some reason and expect people to generate an entire new file with mostly the same content instead. Which definitely doesn't have great performance!
- rbetts 2y ago
  Columnar storage systems rarely store the raw value at fixed position. They store values as run length encoded, dictionary encoded, delta encoded, etc... and then store metadata about chunk of values for pruning at query time. So rarely can you seek to an offset and update a value. The compression achieved means less data to read from disk when doing large scans and lower storage costs for very-large-datasets that are largely immutable - some of the important benefits of columnar storage. Also, many applications that require updates also update conditionally (update a where b = c). This requires re-synthesizing (at least some of) the row to make a comparison, another relatively expensive operation for a column store.
  - lmeyerov 2y ago
    Also typically stored with binary compression (snappy, lib) after the snappy compression. In-memory might only be semantic, eg, arrow. But it's... Fine? Batch writes and rewrite dirty parts. Most of our cases are either appending events, or enriching with new columns, which can be modeled columnarly. It is a bit more painful in GPU land bc we like big chunks (250MB-1GB) for saturating reads, but CPU land is generally fine for us. We have been eyeing iceberg and friends as a way to automate that, so I've been curious how much of the optimization, if any, they take for us

yorwba 2y ago

There's no reason why an update query that doesn't change the file layout and only twiddles some values in place couldn't be made fast with columnar storage. When you run a read query, there's one phase that determines the offsets where values are stored and another that reads the value at a given offset. For an update query that doesn't change the offsets, you can change the direction from reading the value at an offset to writing a new value to that location instead, and it should be plenty fast. Parquet libraries just don't seem to consider that use case worth supporting for some reason and expect people to generate an entire new file with mostly the same content instead. Which definitely doesn't have great performance!

rbetts 2y ago
Columnar storage systems rarely store the raw value at fixed position. They store values as run length encoded, dictionary encoded, delta encoded, etc... and then store metadata about chunk of values for pruning at query time. So rarely can you seek to an offset and update a value. The compression achieved means less data to read from disk when doing large scans and lower storage costs for very-large-datasets that are largely immutable - some of the important benefits of columnar storage. Also, many applications that require updates also update conditionally (update a where b = c). This requires re-synthesizing (at least some of) the row to make a comparison, another relatively expensive operation for a column store.
- lmeyerov 2y ago
  Also typically stored with binary compression (snappy, lib) after the snappy compression. In-memory might only be semantic, eg, arrow. But it's... Fine? Batch writes and rewrite dirty parts. Most of our cases are either appending events, or enriching with new columns, which can be modeled columnarly. It is a bit more painful in GPU land bc we like big chunks (250MB-1GB) for saturating reads, but CPU land is generally fine for us. We have been eyeing iceberg and friends as a way to automate that, so I've been curious how much of the optimization, if any, they take for us