首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Phoenix index 二级索引

    一、索引的创建 通过二级索引,索引的列或表达式形成一个备用行键,以允许沿着这个新轴进行点查找和范 围扫描。 (1)覆盖索引 覆盖索引,一旦找到索引的条目,不需要返回主表,会把我们关心的数据绑定到索引行,节 省读取的开销。 例如:以下内容将在v1和v2列上创建一个索引,并在索引中包含v3列,以防止从原始数据 表中获取该列: CREATE INDEX my_index ON my_table(v1,v2)INCLUDE(v3) (2)功能索引 功能索引,允许您不仅在列上而且在任意表达式上创建索引。然后,当一个查询使用该表达 式时,索引可以用来检索结果而不是数据表。 例如:在EMP上创建索引UPPER_NAME_IDX(UPPER(FIRST_NAME ||''|| LAST_NAME)) 有了这个索引,发出下面的查询时,将使用索引而不是数据表来检索结果: SELECT EMP_ID FROM EMP WHERE UPPER(FIRST_NAME ||''|| LAST_NAME) ='JOHN DOE' (3)全局索引 全局索引适合读操作任务重的用例。使用全局索引,索引的所有性能损失都是在写入时发生 的。我们拦截数据表更新写(DELETE,UPSERT VALUES和UPSERT SELECT),建立索引 更新,然后发送任何必要的更新到所有感兴趣的索引表。在读的时候,phoenix会选择索引 表,然后使用它,这使得查询加快并且直接可想其它表一样scan索引表。默认情况下,除 非暗示,否则索引不会用于引用不属于索引的列的查询。 在用使用全局索引之前需要在每个RegionServer上的hbase­site.xml添加如下属性: 注意:如果使用的是ambari或者cloudera搭建的集群,可直接创建全局或本地索引,这些配置文件已经配置好了 <property> <name>hbase.regionserver.wal.codec</name> <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value> </property> CREATE INDEX USERIDINDEX ON CSVTABLES(USERID); 以下查询会用到索引 SELECT USERID FROM CSVTABLES WHERE USERID='9bb8b2af925864bb275b840c578df3c3'; (4)本地索引 本地索引适用于写多读少,空间有限的场景,和全局索引一样,Phoneix在查询时会自动选 择是否使用本地索引,使用本地索引,为避免进行写操作所带来的网络开销,索引数据和表 数据都存放在相同的服务器中,当查询的字段不完全是索引字段时本地索引也会被使用,与全局索引不同的是,所有的本地索引都单独存储在同一张共享表中,由于无法预先确定 region的位置,所以在读取数据时会检查每个region上的数据因而带来一定性能开销。 在使用本地索引需要在Master的hbase-site.xml添加以下属性 注意:注意本地索引与全局索引的区别,全局只有在,select和where中都为索引才会使用索引 复制代码 <property> <name>hbase.master.loadbalancer.class</name> <value>org.apache.phoenix.hbase.index.balancer.IndexLoadBalancer</value> </property> <property> <name>hbase.coprocessor.master.classes</name> <value>org.apache.phoenix.hbase.index.master.IndexMasterObserver</value> </property> 复制代码 Phoeinx4.3以上为支持在数据region合并时本地索引region也能进行合并需要在每个 region servers中添加以下属性 <property> <name>hbase.coprocessor.regionserver.classes</name> <value>org.apache.hadoop.hbase.regionserver.LocalIndexMerger</value> </property> 创建本地索引 CREATE LOCAL INDEX MYINDEX ON CSVTABLES(USERID); 删除索引 CREATE LOCAL INDEX MYINDEX ON CSVTABLES(KEYWORD); 如果表中的一个索引列被

    01

    记录我删库没跑路的处理方式

    就在今天刚过中午,部门经理让我处理一下一个部署项目的solr索引与实际数据不符合的问题,我们的系统在主页面用了solr进行加载,在数据库中有两篇文章是已经删除了的,而在系统主页还在展示,之前我处理过好几次这种问题,于是我轻车熟路的去检查了一遍数据库和solr的差异数据,随后到服务器上将主系统重新启动(公司内部系统)按照系统业务,在系统启动后应该更新索引,在启动完成后我检查页面发现还存在那两篇文章(现在它俩还不让我那么激动)于是我重启了solr服务再检查一遍,发现还有真是顽固不堪,我只能使出我的必杀技了:删索引,正是这一步导致了我半个下午的暴躁。

    06

    一次ES故障排查过程

    思路:现象是阻塞,通常是 CPU 彪高,导致业务线程分配不到 CPU 时间片,或者内存吃紧,频繁 GC 导致的 STW。登录到目标服务器,由于 ES 的用户不是 LZ,因此找运维要了 root 权限,登录到服务器。sudo -i 切到 root,使用 ps -ef | grep Elasticsearch 找到该用户,然后 su - es 切到 es 用户(不切是无法处理 es 用户的 Java 进程的,例如打印 jstack 日志)。 top 查看服务器状态,发现 pid 4335 进程的 CPU 占用达到 180%,查看 CPU 核数:cat /proc/cpuinfo| grep “processor”| wc -l, 核数为 4,根据经验,通常是 C2 编译器,或者 GC 线程,最后是业务代码导致。因此需要定位该线程。使用 top -Hp 4335,得到线程号 30785,使用 printf "%x" 得到 16 进制数字 7841,方便在 jstack 日志查找线程。使用 jstack -l 4335 > jstacklog.txt 打印日志,然后找线程,vim jstacklog.txt, 开始查找,gg,/7841,enter,n, 找到 "Concurrent Mark-Sweep GC Thread" os_prio=0 tid=0x00007fd380063800 nid=0x7841 runnable 这个 CMS GC 线程,看来是内存不够了。 使用 jps -l 找到 es 启动类名称,然后使用 ps aux | grep Elasticsearch 找到启动详细信息,发现启动配置为 -Xmx2g -Xms2g, -XX:CMSInitiatingOccupancyFraction=50 ,这里为了防止串行 FGC,让 CMS 在 old 区达到 50% 时就开始 GC,所以 CMS 非常繁忙。为了验证此问题,使用 jstat -gcutil 4335 1000 查看 gc 状态,发现 fgc 频繁(5 秒一次),ygc 正常(3 秒一次) ,这里说一下,CMS 的 fgc 此时和我们想象的不一样,CMS GC 只工作在老年代,每次 GC 会对 FGC 次数加 2,一次是 init mark,一次是 remark,这两个阶段会影响暂停应用,其他的清理阶段是并行清理的,对业务线程无影响,所以,当使用 CMS GC ,如果 jstat 看到 FGC 次数很多,不用在意。但当 CMS 出现 concurrent mode failure(CMS GC 的速度赶不上对象晋升到 old 区的速度),则会使用备用收集器 Serial,开始串行 GC,此时将会彻底 STW。 因此,这个 ES 将 CMS 的阈值调的很低,就是为了防止出现 concurrent mode failure。

    01
    领券