国内最专业的IT技术学习网

UI设计

当前位置:主页 > UI设计 >

30亿日志,检索+分页+后台展示,你是否遇到过更

发布时间:2019/09/16标签:   分区表    点击量:

原标题:30亿日志,检索+分页+后台展示,你是否遇到过更
沈教师,你好,想求教一个数据库查问日记,前台页面表现的成绩。需要: 依照某些特定检索前提查问日记; 经过前台Web页面查问并表现相干日记信息; 检索需要包括用户,时光段区间,范例等特定字段;盼望做到: 查问速率尽能够快; 支撑分页查问;现在计划:日记信息存储在Oracle中,依据日期对Oracle做了分区处置,天天天生一个分区表,每个分区表中的数据总量大略在1000W阁下。在相干查问字段比方用户,范例上树立索引,来满意差别维度的查问需要。潜伏成绩:跨分区的查问,求记载总数(盘算分页时的查问),耗时要3-4分钟,叨教有甚么优化方式么?==成绩描写完==这个需要仍是十分反常的,平日日记会停止过滤/构造化/汇总,放入数据堆栈,树立营业宽表,宽表上的查问,个别不会详细查一行一行的记载。假如要支撑检索,并一行一行在Web后盾停止展现,最少要处理几个方面的成绩: 存储成绩; 检索成绩; 扩大性成绩(数据量扩大,检索字段扩大);1、存储成绩能否能够用关联型数据库存储日记?假如日记格局牢固,检索前提牢固,是能够的。比方:2019-08-1123:19:20uid=123action=paytype=wechatmoney=12能够转化为表:t_log(date,time,uid,action,type,money)而后在相干字段上树立索引,以满意后盾查问与展现的需要。数据量太大,怎样处理?依照标题描写,日数据量大略在1000W级别,1年的数据量大略在36Y级别。 假如用Oracle存储,1000W为一个分区表:一年须要365个分区,跨分区的查问机能较低,不太适合。 改成1个月一个分区:单分区3Y记载,大局部分区无写操纵(拔出,修正,删除),只要索引上的读操纵,读写机能基础能抗住。一年12个分区,机能比365个分区好许多。固然本例的日记能够构造化(将日记转化表),因为数据量太大,实在关联型数据库不太实用,能够用合适更大数据量的ES或许Hive来存储。2、检索成绩日记格局牢固,检索前提牢固,假如用关联型数据库或许Hive存储,能够在相干字段上树立索引,来满意查问需要。假如用ES来存储,其外部用倒排表完成,自然支撑检索。3、扩大性成绩1. 数据量扩大不论用Oracle,ES仍是Hive来存储,它们的差别只是单实例/单集群存储容量纷歧样,假如数据量无穷扩大,实质上的处理计划仍是“程度切分”。须要留神的是,只管不要应用自带的“分区表”来扩大,而在营业层本人拆分。画外音:《互联网公司为啥都不必分区表?》。2. 检索字段扩大假如日记不是尺度化的,检索字段也不是牢固的,那就费事了,那就酿成了也“搜寻引擎”的成绩。此时应用ES是更加适合的,不外联合无穷的数据量,终极能够须要本人完成存储于检索引擎(相似于百度,存储容量无穷,检索字段不牢固)。总结:联合本例,日记量大,形式牢固,倡议: 最倡议,应用Hive存储,应用索引的方法完成日记后盾检索需要; 假如扩大性请求稍高,能够应用ES完成存储与检索,应用程度扩大来存储更大的数据量;【本文为51CTO专栏作者“58沈剑”原创稿件,转载请接洽原作者】

版权信息Copyright © 银河官网 版权所有    ICP备案编号:鲁ICP备09013610号