Phoenix使用ROW_TIMESTAMP字段导致无法从null更新数据的故障描述

在Phoenix 4.14.0及阿里云5.2.0版本中,当ROW_TIMESTAMP字段用于主键时,更新VARCHAR字段为null后无法再次更新。通过创建测试表和数据操作展示问题,表明ROW_TIMESTAMP的实现存在缺陷,建议避免使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在使用Phoenix的过程中,发现了一个奇怪的异常现象,其中一个表,有个字段(VARCHAR类型),一旦这个字段被更新为null值,从此就无法重新更新该字段的值。

我在测试过程中,重新新建一张表,就发现可以正常更新,是我困惑不已。

最后经过反复对比,发现是另外一个字段设置成ROW_TIMESTAMP导致的,下面详细讲述一些问题的复习。

 

目前测试发现问题的Phoenix版本为4.14.0,另外,我在阿里云的5.2.0版本上测试,也同样发现该问题。

 

先来讲一下正常的逻辑情况。

 

首先我们先建立一个测试表,语句如下:

CREATE TABLE hyy_test_1(

f_index CHAR(2) not null,

f_create_time date not null,

f_content VARCHAR,

constraint pk primary key(f_index, f_create_time)

)

SALT_BUCKETS = 20;

 

注意一下,这里的f_create_time是主键,但没有设置为ROW_TIMESTAMP类型,f_content就是我们要测试的VARCHAR字段。

 

接下来,我们往该表加一条有值的数据,语句如下:

upsert into hyy_test_1(f_index, f_create_time, f_content) values('1', '2019

### 关于 Row-Key 函数或用法 Row-key 是许多分布式数据库和 NoSQL 数据库中的核心概念之一,尤其是在像 HBase 或 Bigtable 这样的列族存储系统中。Row-key 设计对于性能优化至关重要。 #### Row-Key 的作用 Row-key 主要用作表内记录的唯一标识符,在某些情况下也用于索引构建。通过精心设计 row-key 可以实现高效的读写操作以及良好的数据分布[^1]。 #### 行键的设计原则 - **唯一性**:确保每条记录都有唯一的 key 值。 - **长度适中**:过长会影响查询效率;太短则可能无法满足业务需求。 - **前缀一致性**:如果经常按范围扫描,则应使相似项具有相同的前缀以便提高访问速度。 - **散列均匀度**:防止热点问题的发生,即避免过多请求集中在少数几个节点上。 #### 实际应用案例 假设有一个电商网站想要跟踪用户的浏览历史: ```sql ROWKEY = user_id + "_" + timestamp; ``` 这里 `user_id` 和时间戳组合成复合型主键,既保证了唯一性又方便按照用户维度做聚合分析。 当涉及到具体编程接口时,同类型的数据库有同的方法来处理 row-key 。例如在 Google Cloud Spanner 中创建一张新表时可以指定 primary key 字段作为逻辑上的 row-key : ```sql CREATE TABLE Users ( UserId STRING(MAX), Name STRING(1024), EmailAddress STRING(1024), ) PRIMARY KEY(UserId); ``` 而在 Apache Phoenix 上则是通过定义 unique constraint 来间接设置 rowkey : ```sql CREATE TABLE IF NOT EXISTS my_table( id VARCHAR NOT NULL, col_a INTEGER, CONSTRAINT pk PRIMARY KEY(id) ); ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值