transaction isolation, any SELECT query that touches data in the middle of an UPDATE or DELETE modification (or a Collapse modification as we noted above) will get whatever data is currently in each part" из модной статьи https://blog.timescale.com/blog/what-is-clickhouse-how-does-it-compare-to-postgresql-and-timescaledb-and-how-does-it-perform-for-time-series-data/?utm_source=timescaledb&utm_medium=social&utm_campaign=abl-oct-2021&utm_content=clickhouse-benchmark-blog ?
Мне казалось, что select читает данные из партов, существовавших на момент начала запроса, и консистентность обеспечивается.
парты иммутабельны. он либо есть либо нет. во время апдейта половина партов обновилась - другая нет - ваш селект вернет те парты что есть. поэтому мутации - сложная вещь которую лучше делать в бекграунде...
1. один select консистент. Сложные SELECT .... from t Join (select .... from t) // SELECT .... from t where in (select ..) -- не консистентны потому что это несколько селектов. Это решено в КХ транзакциях. (В том бенчмарке почти все запросы такие) 2. UPDATE or DELETE не атомарны, они обрабатывают партами, поэтому консистентный селект видит половину еще не удаленных строк и не видит половину удаленных
Обсуждают сегодня