Vertica 12.0.0 中的新增功能和更改
1 - JDBC: CallableStatement
客户端驱动程序
Node.js 客户端驱动程序
vertica-nodejs 客户端驱动程序现在可用。
集中式 OAuth 配置
为了简化 OAuth 配置,您现在可以使用包含新的 oauthjsonconfig (ODBC) 和 OAuthJsonConfig (JDBC) 参数的单个 JSON
字符串设置 OAuth 参数。
要保留现有配置,请将旧参数的优先级设置为高于新的 JSON
参数,但推荐使用新的 JSON 参数进行配置,且旧参数已被弃用。
JDBC 数据源用户属性
您现在可以分别使用 getUser()
和 setUser()
获取和设置数据源的 user
属性。有关详细信息,请参阅
JDBC API。
ODBC 客户端驱动程序增强功能
为更好地符合 ODBC 规范,在以下多个方面对 ODBC 客户端驱动程序进行了增强。这些更改可能会导致现有 ODBC 客户端程序执行回归:
-
如果应用程序调用
SQLSetDescField
来设置以下字段以外的任何字段,则记录将变成未绑定状态:-
SET_DESC_COUNT
-
延迟字段:
-
SQL_DESC_DATA_PTR
-
SQL_DESC_INDICATOR_PTR
-
SQL_DESC_OCTET_LENGTH_PTR
-
-
-
SQLSetDescField
必须按照 Microsoft 文档中指定的顺序调用。 -
如果应用程序要为某个数字或日期类型设置精度或比例字段,则必须使用
SQLSetDescField
来显式设置这些字段,而不是依赖于SQLBindParameter
。有关详细信息,请参阅 Microsoft 文档。 -
如果应用程序调用
SQLGetData
,则StrLen_or_IndPtr
可以返回可用数据的实际长度,SQL_NO_TOTAL
或SQL_NULL_DATA
。如果数据被截断,Vertica 将返回SQL_NO_TOTAL
。检查可用缓冲区的长度时,必须考虑所有情况,包括SQL_NO_TOTAL
和SQL_NULL_DATA
。有关详细信息,请参阅有关SQLGetData
和获取长数据的 Microsoft 文档。 -
如果应用程序调用
SQLExecute
,响应将始终尝试设置SQLSTATE
,包括状态和其他元数据。 -
改进了多个异常消息,使其能够显示更详细的错误信息。
2 - 数据库管理
架构和表的磁盘配额
您可以为架构、单个表或两者设置磁盘配额。大多数增加存储大小的用户操作都会检查磁盘配额。配额不影响恢复、重新平衡或 Tuple Mover 操作。
在 Eon 模式下,磁盘使用量是架构或表的所有分片使用的所有磁盘空间的总和。此值仅针对主订阅计算。在 Enterprise 模式下,磁盘使用量是架构或表的所有节点上的所有存储容器使用的磁盘空间的总和。该总和不包括伙伴实例投影,但包括所有其他投影。
DISK_QUOTA_USAGES 系统表记录了设置有配额的对象的配额和配额当前使用情况。
有关详细信息,请参阅磁盘配额。
3 - 诊断工具
Scrutinize
scrutinize
现在通过运行以下命令收集完整时区:
timedatectl | grep "Time zone"
输出将定向到:
scrutinize-output-dir/VerticaScrutinize.timestamp/node-name/context/Commands/timezone
例如,在运行 scrutinize 之后:
$ cat ./VerticaScrutinize.20220513110429/v_vmart_node0001/context/Commands/timezone
Time zone: America/New_York (EDT, -0400)
5 - SDK 更新
多态聚合函数
用户定义的聚合函数 (UDAF) 现在可以为多态函数。多态函数可以接受任意数量和类型的实参。有关如何编写多态函数的信息,请参阅创建多态 UDx。
Python SDK 中的复杂类型
您现在可以使用以 Python 编写的用户定义扩展读取和写入复杂类型。复杂类型支持包括数组、行和两者。有关详细信息,请参阅实参和返回值。有关使用复杂类型的 Python UDx 的示例,请参阅 Python 示例:矩阵乘法和Python 示例:复杂类型的 JSON 解析器。
6 - 安全性和身份验证
通用身份验证错误
为了提高安全性,当用户尝试进行连接和身份验证时,Vertica 不再发出以下错误:
Invalid username or password
此外,Vertica 不再发出特定于方法的错误消息,任何身份验证失败都将生成相同的错误消息:
authentication failed for username "name"
此更改可能会影响根据连接错误代码类型尝试重新连接的客户端。例如 vsql
,它之前会在 TLS 失败(且 TLSMODE 为 ENABLE
)时尝试进行明文连接,但如果 vsql
收到报告用户凭据不正确的错误代码,则不会进行连接。
因为新的通用消息和错误代码没有指定失败的原因,因此 vsql
无法区分身份验证错误是由于无效的 TLS 配置还是无效的用户凭据,它会尝试在这两种情况下建立明文连接。
默认身份验证记录
Vertica 目前创建了 3 个默认身份验证记录,并将其授予 public
角色。这些身份验证记录的优先级为 -1
,因此所有用户创建的身份验证记录均优先于这些默认记录。
在以前版本的 Vertica 中,如果未启用任何身份验证记录,则会应用以下隐式身份验证记录:
-
没有密码的用户使用
trust
方法进行身份验证。在 12.0.0 中,此隐式身份验证记录仍适用于没有密码的用户。 -
具有密码的用户使用
password
方法进行身份验证。此隐式身份验证记录已被移除,取而代之的是默认记录。
Fallthrough 身份验证
您现在可以允许身份验证记录在失败时贯穿到下一条记录(按优先级顺序)。有关详细信息,请参阅Fallthrough 身份验证。
升级行为
在以前的版本中,此 Fallthrough 行为仅适用于 ident
(可以贯穿到任何其他身份验证方法)和 ldap
(只能贯穿到其他 ldap
方法)身份验证方法,且无法禁用。从 Vertica 12.0.0 开始,默认情况下对所有新身份验证记录禁用此行为,包括 ident
和 ldap
。
为了保留依赖于 ident
的 Fallthrough 的现有数据库的行为,如果满足以下所有条件,Vertica 会在升级时自动为 ident
身份验证记录启用 Fallthrough:
-
数据库包含一个
ident
身份验证记录。 -
ident 身份验证记录具有最高的优先级。
-
数据库包含另一个用户定义的身份验证记录。
同样,在以前的版本中,ldap
记录只会贯穿到其他的 ldap
记录,并跳过使用其他方法的记录。目前情况已不再如此;ldap
记录可与许多其他方法兼容贯穿。
因此,要复制 ldap
的旧 fallthrough 行为,您的 ldap
记录必须是连续的(按优先级顺序),可相互贯穿。
7 - SQL 函数和语句
INFER_TABLE_DDL 支持 JSON
您现在可以使用 INFER_TABLE_DDL 函数从 JSON 文件生成候选表定义。因为 JSON 文件不含显式架构,因此该函数会直接检查数据本身。JSON 数据可能因记录或文件而异,因此该函数可能会返回多个候选定义。在以下示例中,以高亮方式显示了差异:
=> SELECT INFER_TABLE_DDL ('/data/*.json'
USING PARAMETERS table_name='restaurants', format='json',
max_files=3, max_candidates=3);
WARNING 0: This generated statement contains one or more float types which might lose precision
WARNING 0: This generated statement contains one or more varchar/varbinary types which default to length 80
INFER_TABLE_DDL
------------------------------------------------------------------------
Candidate matched 1/2 of total files(s):
create table "restaurants"(
"cuisine" varchar,
"location_city" Array[varchar],
"menu" Array[Row(
"item" varchar,
"price" float
)],
"name" varchar
);
Candidate matched 1/2 of total files(s):
create table "restaurants"(
"cuisine" varchar,
"location_city" Array[varchar],
"menu" Array[Row(
"items" Array[Row(
"item" varchar,
"price" numeric
)],
"time" varchar
)],
"name" varchar
);
(1 row)
不可变表
不可变表只能插入,无论用户权限如何,都无法修改其中的现有数据。禁止更新行值和删除行。同时禁止对表元数据的某些更改(例如,重命名表),以防止尝试避开这些限制。
您可以使用 ALTER TABLE 将现有表设置为不可变:
ALTER TABLE table SET IMMUTABLE ROWS;
有关详细信息,请参阅不可变表。