纯文本用于其稳健性,长寿性和自我记录性.以另一种格式存储数据不是一种选择,它必须保持开放且易于处理.存在大量数据(数十TB),并且将副本加载到关系数据库中是不可承受的(我们必须购买两倍的存储空间).
由于我主要做选择和连接,我意识到我基本上需要一个基于.tsv的后备存储的数据库引擎.我不关心事务,因为我的数据都是一次写入多次读取.我需要就地处理数据,没有主要的转换步骤和数据克隆.
由于要以这种方式查询大量数据,我需要利用缓存和计算机网格有效地处理它.
有没有人知道一个系统可以提供类似数据库的功能,同时使用普通的制表符分隔文件作为后端？在我看来,这是一个非常普遍的问题,几乎所有科学家都会以某种方式处理.
解决方法
There is a lot of data (tens of TBs),and it is not affordable to load a copy into a relational database (we would have to buy twice as much storage space).
你比我们任何人都更了解你的要求,但我建议你再考虑一下这个问题.如果你有一个存储在csv文件中的16位整数(0-65535),你的.tsv存储效率大约是33％：它需要5个字节来存储大多数16位整数加上一个分隔符= 6个字节,而本机整数拿2个字节.对于浮点数据,效率更差.
我会考虑使用现有数据,而不是存储raw,以下面两种方式处理它：
>将其以众所周知的压缩格式(例如gzip或bzip2)压缩到永久存档介质(备份服务器,磁带驱动器等)上,以便保留.tsv格式的优势.
>将其处理成具有良好存储效率的数据库.如果文件具有固定且严格的格式(例如,列X始终是字符串,列Y始终是16位整数),那么您可能处于良好状态.否则,Nosql数据库可能会更好(参见Stefan的回答).
这将创建一个可审计(但可能缓慢访问)的存档,具有较低的数据丢失风险,以及一个快速可访问的数据库,无需关注丢失源数据,因为您始终可以将其重新读入数据库来自档案馆.
您应该能够减少存储空间,并且不需要像您所说的那样需要两倍的存储空间.
索引将是困难的部分;您最好知道需要哪些数据子集才能有效查询.
