- 主题:hive分区如何选择
他如果有不带时间戳的查询,你不管怎么分区都没用
【 在 jimmycmh 的大作中提到: 】
: 按id检索,显然指的是where id = xxxx
: 如果你的检索date都是必选条件,那这点数据按天分区完全
:......
论坛助手,iPhone
--
FROM 180.158.5.*
确实完全没必要用hive,hive适合那种每天PB级查询本身也是批量的场景
【 在 RickyDu 的大作中提到: 】
: 这点数据搞个clickhouse或者doris不是嗖嗖的,用啥hive
论坛助手,iPhone
--
FROM 180.158.5.*
你增加一列,把ID映射一下,譬如叫idhash,用天和idhash分区,让单个分区的大小至少进入G级别,查询时多带一个idhash的条件,读速度影响不大,毕竟你这数据太小了。写速度能上两个数量级。
或者就像其他人说的,换个适合你这小体量的OLAP数据库。
推荐你去看Oreilly《数据密集型应用系统设计》,其中关于索引的章节,它循序渐进的介绍了主流OLAP系统索引常见设计,为什么要这么做,不同设计的差异。最重要的是,能帮助理解在使用OLAP的时候该注意哪些技巧,譬如你正在面对的分区问题。中文版如果遇到看不懂的地方去读英文版,中文版比机翻好点但是不多。
【 在 qianfeng018 的大作中提到: 】
: 2M大小的数据。不是200万数据
: 目前就是按天,按ID,
: 但一年365天
论坛助手,iPhone
--
FROM 180.158.5.*
遗留架构。更改太费劲
【 在 RickyDu 的大作中提到: 】
: 这点数据搞个clickhouse或者doris不是嗖嗖的,用啥hive
--
FROM 223.104.41.*
多谢指点
学习学习去
【 在 zeus2615 的大作中提到: 】
: 你增加一列,把ID映射一下,譬如叫idhash,用天和idhash分区,让单个分区的大小至少进入G级别,查询时多带一个idhash的条件,读速度影响不大,毕竟你这数据太小了。写速度能上两个数量级。
: 或者就像其他人说的,换个适合你这小体量的OLAP数据库。
: 推荐你去看Oreilly《数据密集型应用系统设计》,其中关于索引的章节,它循序渐进的介绍了主流OLAP系统索引常见设计,为什么要这么做,不同设计的差异。最重要的是,能帮助理解在使用OLAP的时候该注意哪些技巧,譬如你正在面对的分区问题。中文版如果遇到看不懂的地方去读英文版,中文版比机翻好点但是不多。
: ...................
--
FROM 223.104.41.*
按ID分区就有用啊
【 在 zeus2615 的大作中提到: 】
: 他如果有不带时间戳的查询,你不管怎么分区都没用
: :......
: 论坛助手,iPhone
: ...................
--
FROM 124.126.1.*
确实是, 有不同的查询需求:
1 按ID,取某一天到某一天的全部数据,
2 按天,取某些ID的数据
所以之前的分区,才会选择既按天、又按ID分区
本来预期会存秒级数据,所以数据量也不会太小
结果现在只存聚合后的数据,就只剩下每天每个ID 2M大小的数据了
减少每个分区文件大小设置,比如从128M减到2M,应该对加快查询效率没啥意义吧?
【 在 jimmycmh 的大作中提到: 】
: 按ID分区就有用啊
:
--
FROM 223.104.41.*
我前面说过了,你所有的查询里都有天,在每天数据量不多的情况下,按天分区就足够了,分区内遍历找id并不慢
如果按天分区,分区内数据量过多,可以天+id联合分区
也可以考虑按月+id联合分区,需要计算一下分区大小
【 在 qianfeng018 的大作中提到: 】
: 确实是, 有不同的查询需求:
: 1 按ID,取某一天到某一天的全部数据,
: 2 按天,取某些ID的数据
: ...................
--
FROM 124.126.1.*
收到,多谢
【 在 jimmycmh 的大作中提到: 】
: 我前面说过了,你所有的查询里都有天,在每天数据量不多的情况下,按天分区就足够了,分区内遍历找id并不慢
: 如果按天分区,分区内数据量过多,可以天+id联合分区
: 也可以考虑按月+id联合分区,需要计算一下分区大小
: ...................
--
FROM 223.104.41.*
大数据脱离时间,数据存储和索引就会有很大问题。
【 在 jimmycmh 的大作中提到: 】
: 按ID分区就有用啊
论坛助手,iPhone
--
FROM 58.247.23.*