phoenix 索引相关
来源:互联网 发布:哪些网络公选课容易过 编辑:程序博客网 时间:2024/06/16 13:11
* fully covered within itself and stores the fully 'pre-joined' version of that values for that
* group of columns.
* <p>
* <h2>Index Layout</h2> The row key for a given index entry is the current state of the all the
* values of the columns in a column group, followed by the primary key (row key) of the original
* row, and then the length of each value and then finally the total number of values. This is then
* enough information to completely rebuild the latest value of row for each column in the group.
* <p>
* The family is always {@link CoveredColumnIndexCodec#INDEX_ROW_COLUMN_FAMILY}
* <p>
* The qualifier is prepended with the integer index (serialized with {@link Bytes#toBytes(int)}) of
* the column in the group. This index corresponds the index of the value for the group in the row
* key.
*
* <pre>
* ROW || FAMILY || QUALIFIER || VALUE
* (v1)(v2)...(vN)(pk)(L1)(L2)...(Ln)(#V) || INDEX_FAMILY || 1Cf1:Cq1 || null
* (v1)(v2)...(vN)(pk)(L1)(L2)...(Ln)(#V) || INDEX_FAMILY || 2Cf2:Cq2 || null
* ...
* (v1)(v2)...(vN)(pk)(L1)(L2)...(Ln)(#V) || INDEX_FAMILY || NCfN:CqN || null
* </pre>
*
* <h2>Index Maintenance</h2>
* <p>
* When making an insertion into the table, we also attempt to cleanup the index. This means that we
* need to remove the previous entry from the index. Generally, this is completed by inserting a
* delete at the previous value of the previous row.
* <p>
* The main caveat here is when dealing with custom timestamps. If there is no special timestamp
* specified, we can just insert the proper {@link Delete} at the current timestamp and move on.
* However, when the client specifies a timestamp, we could see updates out of order. In that case,
* we can do an insert using the specified timestamp, but a delete is different...
* <p>
* Taking the simple case, assume we do a single column in a group. Then if we get an out of order
* update, we need to check the current state of that column in the current row. If the current row
* is older, we can issue a delete as normal. If the current row is newer, however, we then have to
* issue a delete for the index update at the time of the current row. This ensures that the index
* update made for the 'future' time still covers the existing row.
* <p>
* <b>ASSUMPTION:</b> all key-values in a single {@link Delete}/{@link Put} have the same timestamp.
* This dramatically simplifies the logic needed to manage updating the index for out-of-order
* {@link Put}s as we don't need to manage multiple levels of timestamps across multiple columns.
* <p>
* We can extend this to multiple columns by picking the latest update of any column in group as the
* delete point.
* <p>
* <b>NOTE:</b> this means that we need to do a lookup (point {@link Get}) of the entire row
* <i>every time there is a write to the table</i>.
at org.apache.phoenix.hbase.index.covered.data.LazyValueGetter.getLatestValue(LazyValueGetter.java:71)
at org.apache.phoenix.index.IndexMaintainer.buildRowKey(IndexMaintainer.java:328)
at org.apache.phoenix.index.IndexMaintainer.buildDeleteMutation(IndexMaintainer.java:473)
at org.apache.phoenix.index.PhoenixIndexCodec.getIndexDeletes(PhoenixIndexCodec.java:170)
at org.apache.phoenix.hbase.index.covered.CoveredColumnsIndexBuilder.addDeleteUpdatesToMap(CoveredColumnsIndexBuilder.java:405)
at org.apache.phoenix.hbase.index.covered.CoveredColumnsIndexBuilder.addCleanupForCurrentBatch(CoveredColumnsIndexBuilder.java:286)
at org.apache.phoenix.hbase.index.covered.CoveredColumnsIndexBuilder.addMutationsForBatch(CoveredColumnsIndexBuilder.java:237)
at org.apache.phoenix.hbase.index.covered.CoveredColumnsIndexBuilder.batchMutationAndAddUpdates(CoveredColumnsIndexBuilder.java:134)
at org.apache.phoenix.hbase.index.covered.CoveredColumnsIndexBuilder.getIndexUpdate(CoveredColumnsIndexBuilder.java:97)
at org.apache.phoenix.hbase.index.builder.IndexBuildManager$1.call(IndexBuildManager.java:134)
at org.apache.phoenix.hbase.index.builder.IndexBuildManager$1.call(IndexBuildManager.java:130)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
: 1 time, servers with issues: nobida145:60020, (state=,code=0)
- phoenix 索引相关
- Phoenix 索引初探
- Phoenix二级索引浅谈
- Phoenix二级索引
- HBase phoenix二级索引
- Phoenix二级索引
- phoenix索引操作
- Phoenix 索引生命周期
- phoenix二级索引
- Phoenix Tips (6) 索引基础
- 利用Phoenix为HBase创建二级索引
- Phoenix二级索引那些事儿(下)
- phoenix 写二级索引的触发机制
- phoenix为 HBase建立二级索引表
- phoenix-4.8.0本地索引实现原理
- Phoenix二级索引(Secondary Indexing)的使用
- Phoenix二级索引(Secondary Indexing)的使用
- Phoenix二级索引(Secondary Indexing)的使用
- Bat批处理
- sql server在多个数据库间 快速查询某个表的信息
- 使用GPS定位为什么location总为空 而且onLocationChanged()方法没调用呀
- Tomcat配置问题
- 智能电视,到底是什么
- phoenix 索引相关
- PHP中复杂类型的一些探究。。。
- Sysklogd系统日志记录器
- json解析转map
- 面对现实,我变得束手无策
- oracle报错——字符集不匹配
- 24点游戏
- 关于使用jQuery - 获得内容和属性的心得
- 对Thread.interrupt()方法很详细的介绍 中断线程