In this lesson we will:
- Explain some of the tradeoffs of using ClickHouse and other OLAP datastores.
In order to achieve such high performance, there are also a few tradeoffs and limitations associated with ClickHouse:
- Limited Updates and Deletes - Support for updates and deletes of data within ClickHouse is rudimentary. We can allow old data to be removed automatically, but it is not designed for ad-hoc updates and deletions as we would use a transactional database for;
- No Transactions - ClickHouse does not have the concept of transactions, meaning that data could end up in an inconsistent state if steps are not taken by the administrator protect against concurrent access issues;
- Management Overhead - You may find yourself comparing ClickHouse with an option such as Snowflake, BigQuery or Redshift. Compared to these, ClickHouse does need to be self-installed and self-managed in a traditional way, though this is changing with the recent general availability of ClickHouse Cloud;
- Clustering and Sharding - Though ClickHouse is frequently deployed as a cluster, administering this is a more manual undertaking than other cloud native databases which can perform automatic clustering and rebalancing of data.
To be fair to ClickHouse, many of these tradeoffs are also found in other OLAP databases, which are optimised for certain analytical use cases at the expense of others. As is always the case in the data world, it is important to choose the right tool for your particular use case.