Oracle中的lob
在Oracle数据库中,有blob和clob这两种较为特殊的数据类型,之所以特殊,是因为这两个类型中能存储大量的数据,最高可达4GB,因此比较适合用来存文件,其中blob用于存储二进制数据,而clob用于存储纯文本数据。
另外,如果表里有字段是这两种类型,那么这些类型的数据也会有个单独的存储扩展段。而表内这两列实际存储的是“LOB locator”,即LOB定位器,相当于一个索引值,可以根据这个值在另外的存储扩展段里找到实际的lob数据。
也是由于存储是分开的,所以对这两种字段的操作会比较麻烦,比如插入空值时不能插null,而要插入一个 empty_blob()或empty_clob();对数据内容进行拼接更新,不能直接用管道符拼接数据update,而是需要使用dbms_lob包进行管理,等等。诸如此类的“常规操作”需要用“非常规”的方式进行。
oracle的文本类型varchar2只能操作32767的字节长度,而管道符和concat函数都是针对varchar2类型进行的操作,就算clob和varchar2可以隐式互转,可一旦超过这个长度限制就会报错,所以不得不用dbms_lob包来处理。
另外,有to_clob(varchar2)和to_blob(raw)这两个函数可以通过转换得到clob及blob类型的数据,这其实也说明了clob/blob与varchar2/raw之间的关系。
openGauss中的lob
openGauss是基于postgresql 9.2的内核进行的深度开发,而postgresql是没有clob、blob、raw类型的。为了方便从oracle中进行迁移(当然sql标准里其实也定义了blob和clob类型),openGauss里添加了这些pg里没有的类型。
但是,openGauss里添加的这些类型,并不完全等同于oracle中对应的类型
官方文档
https://opengauss.org/zh/docs/3.0.0/docs/Developerguide/二进制类型.html
https://opengauss.org/zh/docs/3.0.0/docs/Developerguide/字符类型.html
分组 | 名称 | 描述 | 存储空间 |
---|---|---|---|
二进制类型 | BLOB | “二进制大对象。说明:列存不支持BLOB类型。” | 最大为1GB-8203字节(即1073733621字节)。 |
二进制类型 | RAW | “变长的十六进制类型。说明:列存不支持RAW类型。” | 4字节加上实际的十六进制字符串。最大为1GB-8203字节(即1073733621字节)。 |
二进制类型 | BYTEA | 变长的二进制字符串。 | 4字节加上实际的二进制字符串。最大为1GB-8203字节(即1073733621字节)。 |
字符类型 | VARCHAR2(n) | 变长字符串。是VARCHAR(n)类型的别名。n是指字节长度。 | 最大为10MB。 |
字符类型 | TEXT | 变长字符串。 | 最大为1GB-1,但还需要考虑到列描述头信息的大小, 以及列所在元组的大小限制(也小于1GB-1),因此TEXT类型最大大小可能小于1GB-1。 |
字符类型 | CLOB | 文本大对象。是TEXT类型的别名。 | 最大为1GB-1,但还需要考虑到列描述头信息的大小, 以及列所在元组的大小限制(也小于1GB-1),因此CLOB类型最大大小可能小于1GB-1。 |
首先从大小上来说,BLOB/CLOB在ORACLE里为4GB,而openGauss里只有约1GB;ORACLE里RAW只有32767字节长度,而openGauss里却保持和BLOB一样的接近1GB。感觉可以这么理解,在openGauss里,BLOB可以完全和RAW互相转换,TEXT和CLOB也可以互相转换。
并且我刚好在源码里翻到了这段
CREATE CAST (BLOB AS RAW) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (RAW AS BLOB) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (TEXT AS CLOB) WITHOUT FUNCTION AS IMPLICIT;
CREATE CAST (CLOB AS TEXT) WITHOUT FUNCTION AS IMPLICIT;
这更加印证了我的猜想,BLOB到RAW的隐式转换不需要经过任何函数,同理TEXT到CLOB也是如此。所以,如果要把一个RAW转成BLOB,只需要"::blob" ;TEXT转CLOB也是同理。
兼容性分析
其实文本类型还好说,比较各种数据库里对文本类型处理的函数大多是一致的,因此很少存在sql语法兼容问题,麻烦的还是二进制类型,比如这个BLOB和RAW。前面有说到,oracle里有专门的包来处理这些二进制类型,比如dbms_lob/utl_raw等,但openGauss里仅仅只对raw有一些基础处理的函数(【openGauss】谈谈openGauss中的raw类型)。不过在【openGauss】记录一次关于openGauss(postgresql)数据类型的摸索经过及感想这篇文章里,我知道了对于每种类型来说,都有四个很重要的函数:
select typname,typinput,typoutput,typreceive,typsend
from pg_type where typname in ('raw','blob','bytea')
typname | typinput | typoutput | typreceive | typsend |
---|---|---|---|---|
bytea | byteain | byteaout | bytearecv | byteasend |
blob | rawin | rawout | bytearecv | byteasend |
raw | rawin | rawout | rawrecv | rawsend |
bytea这个pg内置的类型自不必说,pg原生就提供了很多处理bytea的函数,像length、substr这种用于字符类型的,一样可以用于处理bytea类型,而且处理逻辑和按字符串不一样,是按十六进制字节处理,因此不需要考虑十六进制文本的转换导致的长度翻倍。而openGauss自己增加的类型,则没有这种函数可以处理,所以得利用这些*send函数,将raw/blob转换成bytea再进行处理。
从上面这个表里可以得知,raw类型可以用rawsend来转换成bytea,见下面这个sql
select '1234ff'::raw,length('1234ff'::raw),length(rawsend('1234ff'::raw))
可以看到,如果我们直接对RAW类型使用length,得出来的长度其实是其十六进制字符串的长度,是个错误的值,而转换成bytea后,再用length,长度才正确。其他诸如substr函数均是如此,这里就不演示了。
然后就是BLOB类型,我不确定这里是开发人员有意为之或是其他什么原因,竟然把blob的send函数写成了byteasend,用这个函数去查blob类型是会报错的,因为不存在一个"byteasend(blob)"这样的函数
数据库操作时出错。 确认要继续执行吗?
单击“详细信息”了解详情。
SQL错误码: = 42883
[127.0.0.1:52633/ocalhost/127.0.0.1:5434] ERROR: function byteasend(blob) does not exist
建议:No function matches the given name and argument types. You might need to add explicit type casts.
位置:55
在位置:referenced column: byteasend
行号: 9
另外,我在openGauss源码里也没找到blobsend这个函数,因此,只能借助于比较完备的raw类型来处理,即对blob类型先用"::raw"转换成raw类型,再rawsend转换成bytea类型,才能正确的使用相关函数来对这个二进制数据进行处理。
而且如果是像dbms_lob.copy这样,输入BLOB,输出还是BLOB,则需要将blob转raw转bytea,经过bytea的一系列专用函数处理后,再通过rawout转换成cstring再转成text再转成raw再转成blob。(cstring不能直接转raw,而且理论上此处使用rawrecv函数效率更高,但它的输入类型是internal,传bytea类型会报错,因此只能输出文本再转raw了)
DECLARE
a blob:='1234ff'::blob;
b bytea;
c blob;
BEGIN
b:=rawsend(a::raw);
----
--中间过程略
----
c:=rawout(b)::text::raw::blob;
end;
/
大对象?
其实oracle中的clob和blob,统称为大对象;而在pg体系中,大对象其实并非是blob/clob这样的类型,而是专门有一套处理机制。
大对象客户端接口
大对象服务端函数
每个大对象都有一个对应的oid作为标识符,像截取、合并等操作都是以oid来进行处理,参考前文,其实这个才更像oracle对lob对象的处理方式,表里只存一个标识符(定位器),实际数据在另外的地方存。而openGauss文档里说自己的clob是大对象,其实不太符合其实现机制,因为它只是text的同义词,而且text并非大对象。
总结
如果有从oracle迁移到openGauss的,而且有使用二进制数据类型及处理的,一定要谨慎处理这些兼容问题,否则可能会出现代码不报错但数据处理出错的情况。
当然,也可以使用compat-tools组件。目前compat-tools已经加入了utl_raw及dbms_lob这两个包,欢迎大家测试使用
https://gitee.com/enmotech/compat-tools
注:本篇文章纯属个人研究的一些记录,其中如有疏漏,请联系本人改正,感谢。
- 本文作者: DarkAthena
- 本文链接: https://www.darkathena.top/archives/about-opengauss-lob-type
- 版权声明: 本博客所有文章除特别声明外,均采用CC BY-NC-SA 3.0 许可协议。转载请注明出处!