【建议】增加存储(组表、集文件)元数据管理
SPL极致性能需结合自己设计的组表和集文件存储方式,那么随着所有采集同步以及加工的数据都转化/生成组表,对组表/集文件(元数据)的管理目前是怎么操作的?是否有类似数据库的元数据管理那样,有专门存储所有组表元数据信息的地方,是否有相应的访问接口可以实时获取组表/集文件的信息(包括有哪些组表、具体某个组表的大小,该组表有哪些列,组表上面创建了哪些索引...)
SPL的思路和RDB不同,它是开放的计算体系,没有“库”的概念,只要能访问到的数据都能计算,无非是访问性能不同。组表和其它文本文件以及从RDB/NoSQL中读出来的数据,在计算功能上,并没什么本质不同。”有哪些组表“这个问题对SPL并没有意义,自己到文件系统下看就可以了,甚至网络文件系统以及远程对象存储也可。 至于组表的数据结构(以及索引),有函数可以读出来。大小之类的信息,问文件系统就可以了。
没有元数据,才会有开放性,这是个基本理念。这个体系做成云原生后,也非常轻,很容易做到serverless和弹性扩展。 后面会逐步提供一些方便的编辑与管理工具,但仍然是对着文件系统的,没有“库”。数据计算无处不在,不需要“库”这个概念。
远程分布式对象(minIO)存储之后,试了使用file()和httpFile()读取函数出来数据都是乱码,是否有现成的读取分布式存储上面的组表的函数接口?请问能否研发新函数读取对象存储的组表数据;
file要求是文件系统的协议(POSIX的一部分)。httpfile就是HTTP的协议了。对象存储是它独特的协议,肯定不能直接用这个了。 对象存储目前还不直接支持,后续的外部库会支持S3等协议,把对象存储映射成一个文件对象,提供类似s3file这样的函数,之后再生成组表等动作都是一样的。 完善的S3接口要考虑缓存,否则性能比较差,这会比较麻烦,有一些开发工作量。本地或网络文件系统不用管这个。 也可以使用第三方的文件系统,有不少开源产品已经能把S3这类对象存储封装成满足POSIX协议的文件系统了,就可以直接用file函数了。不过会在架构上又多一层,复杂化了