ClickHouse：如何正确存储JSON数据？

如何解决ClickHouse：如何正确存储JSON数据？

我将数据从Postgresql 数据库迁移到Yandex的ClickHouse。源表中的字段之一是JSON类型-称为additional_data。因此，Postgresql允许我例如在访问期间访问json列的属性。 SELECT ...用->>和->进行查询，等等。

我在ClickHouse存储区的结果表中需要相同的行为保留。（即在选择查询以及使用过滤和聚合子句时，JSON的可访问性及其属性）

这是我在CREATE TABLE ...期间在ClickHouse客户端中所做的事情：

create table if not exists analytics.events
(
    uuid UUID,...,created_at DateTime,updated_at DateTime,additional_data nested (
        message Nullable(String),eventValue Nullable(String),rating Nullable(String),focalLength Nullable(Float64)
        )
)
engine = MergeTree

ORDER BY (uuid,created_at)
PRIMARY KEY uuid;

如何存储JSON可序列化的数据是一个不错的选择吗？有任何想法吗？

也许最好将JSON数据存储为纯String而不是nested并使用special functions来处理它？

解决方法

尽管ClickHouse使用快速的JSON库（例如simdjson和rapidjson）来进行解析，但我认为嵌套字段应该更快。
如果JSON结构是固定的或可预测地更改，请尝试考虑对数据进行非规范化的方式：

..
    created_at DateTime,updated_at DateTime,additional_data_message Nullable(String),additional_data_eventValue Nullable(String),additional_data_rating Nullable(String),additional_data_focalLength Nullable(Float64)
..

一方面，它可以显着增加行数和磁盘空间；另一方面，它可以显着提高性能（尤其是在正确的索引编制中）。此外，可以使用LowCardinality-type和Codecs减小磁盘大小。

其他一些评论：

避免使用Nullable类型，更喜欢使用诸如''，0等的替换项（请参见说明Clickhouse string field disk usage: null vs empty）
UUID类型不提供index monotonicity，这应该更好（More secrets of ClickHouse Query Performance）：

..
ORDER BY (created_at,uuid);

考虑使用Aggregating-engines来显着提高计算聚合值的速度

无论如何，在做出最终决定之前，都需要对数据子集进行手动测试（这适用于选择模式（json为字符串/嵌套类型/非规范化方式），以及选择列编解码器）。