We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
起因是这样的,公司一个同事提了一个问题,说是MongoDB性能差,对一些时序数据做分析,要跨表查询。估计后面要生成报表啥的吧。我也不清楚。我推荐现在性能好可以用ClickHouse,我说ClickHouse这种专业的OLAP数据库,一张大宽表,不用跨表查。他说他的数据是有关联性的,对JOIN有需求,我直觉上觉得可以把关联数据处理成一张表,但是当时我没有给出来相关的方法,毕竟我以前没有做过大数据。至于直觉为什么是这样,是因为,我在知乎上好像看到有人问ClickHouse JOIN相关的问题,大部分人回答说这是OLAP数据库的使用姿势不对,一般来说就是一张大表,几万列。直接避免JOIN。本来大数据这种就不推荐JOIN。所以我就想着几万列不可能没有关联数据,肯定是做了一些处理。今天同事开会又提到,刚好被我听见了,我就查了下,顺腾摸瓜。查出来这种把关联数据处理成一张表的方式叫Data Denormalization
当然,以前上一些看过一些关系型的数据库,也有这种手法,就是设计表的时候故意不遵循范式(比如让多个表的读取量大的字段重复,这样避免跨表查询),叫反范式设计。我发现其实都是一样的,并没有区别。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
起因是这样的,公司一个同事提了一个问题,说是MongoDB性能差,对一些时序数据做分析,要跨表查询。估计后面要生成报表啥的吧。我也不清楚。我推荐现在性能好可以用ClickHouse,我说ClickHouse这种专业的OLAP数据库,一张大宽表,不用跨表查。他说他的数据是有关联性的,对JOIN有需求,我直觉上觉得可以把关联数据处理成一张表,但是当时我没有给出来相关的方法,毕竟我以前没有做过大数据。至于直觉为什么是这样,是因为,我在知乎上好像看到有人问ClickHouse JOIN相关的问题,大部分人回答说这是OLAP数据库的使用姿势不对,一般来说就是一张大表,几万列。直接避免JOIN。本来大数据这种就不推荐JOIN。所以我就想着几万列不可能没有关联数据,肯定是做了一些处理。今天同事开会又提到,刚好被我听见了,我就查了下,顺腾摸瓜。查出来这种把关联数据处理成一张表的方式叫Data Denormalization
当然,以前上一些看过一些关系型的数据库,也有这种手法,就是设计表的时候故意不遵循范式(比如让多个表的读取量大的字段重复,这样避免跨表查询),叫反范式设计。我发现其实都是一样的,并没有区别。
References
The text was updated successfully, but these errors were encountered: