基于列存储的数据库存储系统研究
面向列存储的数据库设计与实现
面向列存储的数据库设计与实现近年来，随着大数据时代的到来，数据量急剧增长，数据处理能力的需求也越来越高。
传统的行存储数据库在处理大规模查询时存在一些瓶颈，因此，面向列存储的数据库逐渐被广泛采用。
本文将介绍面向列存储的数据库设计与实现的相关内容，包括数据模型设计、存储方式、查询优化等。
面向列存储的数据库与传统的行存储数据库有所不同。
传统数据库将数据按行存储，一条记录的所有字段值连续存放，而面向列存储的数据库将数据按列存储，即将每个字段的值存放在一起。
这种存储方式的优势在于可以只加载需要的列，大大提升了数据查询的效率。
因此，面向列存储的数据库尤其适用于大规模数据的分析查询场景。
在设计面向列存储的数据库时，一个关键的问题是如何表示和管理列。
一种常见的方法是使用列族（column family）的概念来组织数据。
列族是将相关字段（列）按照逻辑关系分组的集合。
每个列族可以含有不同的列，不同的列族可以包含相同类型的数据。
这样的设计可以有效地组织数据，并且提供了良好的横向扩展性。
此外，为了提高访问效率，可以采用压缩技术来减小存储空间，例如使用字典压缩、位图压缩等。
在面向列存储的数据库中，查询优化也是一个重要的研究方向。
由于数据存储的方式发生了变化，传统的查询优化技术不一定适用于列存储数据库。
因此，需要针对列存储的数据模型设计相应的查询优化算法。
一种常见的查询优化技术是基于预先分析的查询计划生成，即在执行查询之前，根据查询的特点和数据的分布情况，生成最优的查询计划。
此外，可以采用列存储索引来加速对数据的查询，例如基于列存储的B树索引、位图索引等。
与传统的行存储数据库相比，面向列存储的数据库在大数据处理和分析任务上有明显的优势。
首先，列存储数据库可以提供更快的查询效率。
由于将每个字段的值都存放在一起，可以减少不必要的IO访问，并且更好地利用CPU的缓存。
其次，列存储数据库适合处理大批量的读多写少的场景，如数据仓库、数据分析等业务。
关系型数据库与列式存储比较研究
关系型数据库与列式存储比较研究关系型数据库与列式存储是两种不同的数据存储和查询方式。
关系型数据库以表的形式存储数据，每个表由多个列组成，每一行代表一个实体，列存储的是该实体的属性。
而列式存储则是将每个列独立存储，相同列的数据存放在一起，每列存储的是相同属性的值。
本文将对两种存储方式进行比较研究。
1.存储结构关系型数据库采用行式存储，每一行包含所有的属性，每个表由多个行组成。
这种存储方式适合事务处理和OLTP应用，可以快速查询一整行数据。
而列式存储则将每个列独立存储，相同列的数据存放在一起。
这种存储方式适合分析查询和OLAP应用，可以快速查询特定列的数据。
2.查询性能在关系型数据库中，如果需要查询某个属性的数据，需要对整行进行扫描，性能较低。
而在列式存储中，只需要扫描特定列的数据，查询性能更高。
特别是在处理大规模数据时，列式存储可以大大减少磁盘I/O操作，提高查询效率。
3.压缩率关系型数据库对每一行进行存储，在数据类型固定的情况下，压缩性较好。
而列式存储可以采用更加灵活的压缩算法，因为每个列的数据类型可以不同，每个列可以根据其数据类型采用不同的压缩方式，从而提高存储效率。
4.数据更新关系型数据库在进行数据更新时，需要对整行进行更新，即使只修改了其中一个属性。
而列式存储可以只更新需要修改的列，其他列的数据不受影响。
这样可以极大地减少数据更新的开销。
5.查询灵活性关系型数据库支持多表的关联查询，可以进行复杂的查询操作。
而列式存储一般用于分析型查询，只针对特定列的查询进行优化，不适合复杂的关联查询。
6.存储需求关系型数据库需要存储各种属性的数据，无论是读取还是写入，都需要对整行数据进行操作，存储需求较高。
而列式存储只需要存储特定列的数据，对其他列的数据不感兴趣，存储需求较低。
7.数据一致性关系型数据库强调数据一致性，支持事务处理，适用于数据的插入、更新和删除。
而列式存储一般不支持事务处理，适用于只读或者批量插入的场景。
基于列存储的大规模并行数据库应用技术
列存储 最 核心 的技术就 是基 于垂直 分 区的存 储设计 和访
问模式 列存储数据 库完全划分为多个独立 的列 的集 合进行存
［收稿 日期Leabharlann ］２０１６—０３—１８ 隐患也得不 到处理 ．从而加速安全事故 的发生
信息 消息 的快速传 递 ．如 果检测到 大坝将要发生 或已经发生溃
（４）安全监控设 施落后 。我 国很 多水库都在 改革开放之 前 决 ，能够 在第一 时间进 行消息 传播 与扩散 ．避免大 范 围人 员伤
建成 ，因此并不配 备相应 的安全检测仪 器 。很 多时候 ．如果水库 亡 的发生。
之 中的相关 数据发生 异常 。工作人 员并不能够及 时察觉并 采取
（３）管理缺 失现象治理 。物联 网技术 与云技术相互结 合能
相 应 措 施 。
够达 到远程 监控 、远 程教学 的效果 ，这对 于大坝 的安全管 理有
（５）水库实 时监 管。工作人员难免会发生错误 ，这是人之 常
不可分 。相较于传统 的大坝安全 控制技术 而言 ．信息技 术有着 情 。为了避免此类 情况 的发 生 。不 应该去让工作人 员加倍努力
更加 明显 的优势 。物联 网通过对 网络信息 的整理 与归纳达到对 的进行安 全巡视 工作 ．而应该采取 相应措施将人 力巡视替换为
事故发生之 前 的种种 现象凭借人 类 的感 官并 不能发 现 ．这也导 息传递 给维护部 门。同时 。物联 网技术需要各种设施的支持 ，如
致大坝安全 事故频发
果水库选择采用物联 网与云技术 ．必将会推动相关设备 的更新
２ 物联 网与云技术 对大坝安全控制 的重 要意义
换代 。
当前是信 息化 时代 ．信 息技术 与人 们 的 日常生活早 已经密
HBase_LSM_列式存储
LSM-tree的另一大特点是除了使用两部分类树的数据结构外，还会使用日志文件（通常叫作 commit log）来为数据恢复做保障。这三类数据结构的协 作顺序一般是：所有的新插入与更新操作都首先被记录到 commit log中——该操作叫作 WAL（Write Ahead Log），然后再写到 memtable，最后当达 到一定条件时数据会从 memtable冲写到 sstable，并抛弃相关的 log数据； memtable与 sstable可同时供查询；当 memtable出问题时，可从 commit log与 sstable中将 memtable的数据恢复。
6）Cell
单元格，由五元组（row，column，timestamp，type，value） 组成的结构，其中type表示Put/Delete这样的操作类型， timestamp代表这个cell的版本。这个结构在数据库中实际是以 KV结构存储的，其中（row，column，timestamp，type）是K， value字段对应KV结构的V。
1.HBase简要介绍
目 2.LSM存储模型
录
基于循环的随机数列产生并存放研究
基于循环的随机数列产生并存放研究摘要：利用循环产生随机数列，并把这些随机数列依次存储在数据库中。
研究表明：选用不同的数据库会显示不同的存放效果。
关键词：循环结构；随机数列；Access；Sql Server0引言循环结构是程序设计的3种基本结构之一，它可以在某个条件下反复执行一段算法，从而减少重复书写的工作量。
Access和SQL Server均为微软产品。
Access为单机版数据库，多应用于小型系统上，它结合了“Microsoft Jet Database Engine”和“图形用户界面”两项特点，是Microsoft Office的成员之一。
SQL Server为网络数据库，安全性高，真正的客户机/服务器体系结构，图形化用户界面，使系统管理和数据库管理更加直观、简单，丰富的编程接口工具为用户进行程序设计提供了更大的选择余地，多为中型企业级的应用。
在开发各种管理系统时，常需要本地数据库和网络数据库配合使用，这种情况下，SQL Server和Access往往是首选数据库。
但是相同的循环程序，应用不同的后台数据库，却产生了不同的存储结果。
1随机数列的生成与存放在很多时候，需要通过循环产生多个随机数列，并把它们依次存储在数据库中。
例如在某网络测评系统中，既要保证有授权的人员进行投票，又要实现匿名投票，所以需要产生多个不同的随机数列作为登陆码，并存放在数据库中。
产生随机数列的方法如下：public string RandLetter（int n）{char[] arrChar = new char[]{'a'，'b'，'c'，'d'，'e'，'f'，'g'，'h'，'i'，'j'，'k'，'l'，'m'，'n'，'p'，'q'，'r'，'s'，'t'，'u'，'v'，'w'，'x'，'y' ，'z'，'A'，'B'，'C'，'D'，'E'，'F'，'G'，'H'，'I'，'J'，'K'，'L'，'M'，'N'，'P'，'Q' ，'R'，'S'，'T' ，'U'，'V'，'W'，'X'，'Y'，'Z' }；StringBuilder num = new StringBuilder（）；Random rand = new Random（lisecond）；for （int i = 0；i < n；i++）{num.Append（arrChar[rand.Next（0，arrChar.Length）].ToString （））；}return num.ToString（）；}为了产生多个随机码，则通过循环多次调用上述产生随机数列的程序，如下所示：for （int i = 0；i < g_voter.Rows.Count；i++）{Session["code"]=null；int i_groupId = Convert.ToInt32（groupId）；String s_groupId = i_groupId.ToString（）；if （i_groupId < 10）{s_groupId = "0" + groupId；}else{s_groupId = groupId；}Session["code"] = cc.RandLetter（6）；passCode = s_groupId + （（Label）（g_voter.Rows[i].FindControl （"Label1"）））.Text.ToString（）+ Session["code"]；if （Session["voteId"] ！= null）{voteId = Session["voteId"].ToString（）；}else{this.ClientScript.RegisterStartupScript（this.GetType（），""，cc.MessageBox（"验证码生成失败！"））；return；}……}上述程序，如果选用Access作为存储随机数列的数据库，则产生如图1中“投票人验证码”字段中的效果，能够按照编码规则产生不同的随机数列，不会出现重复序列。
列式存储数据库
列式存储数据库近年来，随着大数据和人工智能技术的不断发展，数据库的存储方式也在不断创新。
近年来，一种新的数据库存储方式——列式存储数据库受到了广泛的关注和应用。
在这篇文章中，我们将探讨列式存储数据库的概念和优势。
一、列式存储数据库的概念列式存储数据库，也称为列存储数据库，是一种面向列而非行的数据库实现方式。
相比传统的行式存储方式，列式存储方式将数据按列存储，每一列包含相同类型或相似类型的数据。
数据按列存储后，表现出对于数据仓库和大型分析应用来说更加优异的性能。
二、列式存储数据库的优势1. 高效性能由于列式存储方式将数据存储在独立的列中，所以每个查询只需要读取需要的列，而不必读取整个行。
相对而言，列式存储方式在处理大型数据集时明显优于行式存储方式。
2. 压缩率高由于列式存储数据库将具有相同数据类型或相似数据类型的数据存储在同一列中，因此这些数据可以采用非常高效率的压缩算法进行存储。
反过来，这还意味着列式存储数据库需要的存储空间更少，能够支持更高的数据密度。
3. 易扩展性列式存储数据库能够很好地处理大型数据集，这意味着数据规模可以随扩展而快速增加，而不会影响性能。
而行式存储数据库在数据规模增加时，需要增加行数或分隔表，这与列式存储方式相比较而言，容易引起系统崩溃等问题。
4. 数据质量高由于列式存储数据库采用了高效率的压缩算法进行数据存储，能够针对数据集的特定部分进行优化。
在数据查询和分析过程中，列式存储数据库能够给出更准确、更可靠的值。
三、列式存储数据库的应用场景1. 数据仓库数据仓库是列式存储数据库的主要应用场景之一。
数据仓库需要处理大量、复杂的数据，而列式存储数据库可以处理大量数据，并且在从数据查找时特别有效。
由于列式存储数据库可以对部分表进行优化而忽略不需要的数据，因此适用于大型的数据仓库。
2. 实时分析应用实时分析应用需要快速的查询响应时间和迅速的分析数据。
列式存储数据库提供了满足速度需求的条件，能够进行快速的查询和分析，且在处理大规模的数据集时有很好地性能优势。
列式数据库的研究
列式数据库的研究列式数据库是一种用于存储和管理海量数据的数据库技术。
与传统的行式数据库相比，列式数据库以列为单位存储数据，而不是以行为单位。
由于其独特的存储方式和数据结构，列式数据库在处理大规模数据分析和实时查询方面具有显著的性能优势。
传统的行式数据库使用行存储的方式，它们将一行数据的所有字段存储在一起。
这在查询指定行的数据时速度较快，但在进行聚合查询和更新操作时会遇到性能问题。
因为在行式存储下，需要扫描整行数据来计算聚合结果，而且每次更新操作都需要将整行数据写入磁盘。
当数据量非常大时，这种操作会导致性能下降。
相比之下，列式数据库按照列存储数据，每列的数据连续存放在一起。
这种存储方式使得列式数据库在聚合查询、大规模数据分析和快速查询方面表现出色。
由于数据存储在列中，只需要读取需要的列数据即可，大大减少了磁盘的读取量。
此外，列式数据库还能够高效地进行压缩，进一步减少存储空间占用。
1.存储和压缩技术：在列式数据库中，数据存储和压缩是关键技术。
研究者通过设计高效的存储结构和压缩算法，使得列式数据库能够在有限的存储空间下存储更多的数据。
其中，列存储和位图压缩是列式数据库中常用的技术。
2.查询和优化算法：列式数据库需要设计高效的查询和优化算法来实现快速的数据查询和分析。
研究者通过优化查询计划、并行化查询操作和使用高级索引等方式来提高查询性能。
此外，还可以利用预处理和缓存技术来减少查询的延迟。
3.数据一致性和事务管理：列式数据库通常被用于大数据分析场景，需要能够处理复杂的数据一致性和事务管理问题。
研究者通过设计高效的并发控制和事务管理机制，来保证数据的一致性和可靠性。
4.分布式存储和处理：随着大数据技术的发展，列式数据库的研究也开始关注分布式存储和处理。
研究者致力于设计高效的分布式存储和处理框架，以应对海量数据的存储和计算需求。
总之，列式数据库的研究旨在提高大规模数据分析和实时查询的效率和性能。
通过存储和压缩技术、查询和优化算法、数据一致性和事务管理以及分布式存储和处理等方面的研究，列式数据库可以更好地支持大数据应用，满足企业和科研机构对于高效数据分析和查询的需求。
opengauss列存储引擎的存储基本单位
标题：深度解析opengauss列存储引擎的存储基本单位在讨论opengauss列存储引擎的存储基本单位之前，我们首先要了解列存储引擎的基本概念。
opengauss是一款开源的关系型数据库管理系统，其列存储引擎是其核心特性之一。
列存储引擎使用列存储的方式来组织数据，与传统的行存储方式不同，它将每一列的数据分别存储在磁盘上，这样可以大大提高数据的读取和查询效率。
在opengauss列存储引擎中，存储基本单位是一个重要的概念，它直接影响着数据的组织和存储方式，对于数据库的性能和效率具有重要的影响。
1. 存储基本单位的定义和作用存储基本单位是指在列存储中，最小的数据单位是如何组织和存储的。
在opengauss列存储引擎中，存储基本单位通常是一个数据块，用来存储一定数量的列数据。
通过合理设置存储基本单位，可以有效地利用磁盘空间，提高数据的读取和查询效率。
存储基本单位的大小不是固定的，可以根据实际情况进行合理的设置。
2. 存储基本单位的选择在opengauss列存储引擎中，选择合适的存储基本单位非常重要。
一般来说，存储基本单位的大小应该根据数据的特点和查询的需求来进行选择。
如果数据的列比较多，且查询时经常需要读取多个列的数据，那么可以选择较大的存储基本单位，这样可以减少IO次数，提高查询效率。
相反，如果数据的列比较少，且查询时往往只需要读取其中的一两列，那么可以选择较小的存储基本单位，这样可以提高查询的灵活性和效率。
3. 存储基本单位的管理和优化在实际的数据库管理中，对存储基本单位的管理和优化也非常重要。
opengauss提供了丰富的管理和优化工具，可以根据实际情况对存储基本单位进行调整和优化。
在实际使用中，可以通过分区表、压缩和分布式存储等方式来优化存储基本单位，以提高数据的存储和查询效率。
总结通过本文的介绍，我们对opengauss列存储引擎的存储基本单位有了更深入的了解。
存储基本单位作为列存储引擎的重要概念，对于数据库的性能和效率具有重要的影响，合理的选择和优化存储基本单位对于提高数据的存储和查询效率非常重要。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于列存储的数据库存储系统研究
基于列存储的数据库，相对于传统的基于行的数据库，更适合在数据仓库存储方面发挥特长1简介
在项目中，将研究一个客户（常规）文件系统设计，以提高基于列存储数据库的查询性能。
该基于列存储数据库除了在磁盘上存储数据方式不同外，类似于典型的关系型数据库（基于行存储的数据库,如MySQL或Postgres）。
不同之处如图1所示：在一个基于行存储的数据库中，每一行的属性按顺序存储，并在每一行被存储在一个连续的文件中。
而在一个基于列存储的数据库中，每个属性列存储在一个单独的文件。
这个文件的配置有一个优势，主要是适合只读数据库（数据仓库）。
首先，任何查询涉及到的数据库属性的子集回归，只需要较少的磁盘带宽，因为只加载所需的属性。
随着装载属性增多，查询次数也就增加。
其次，每个列存储一个单一类型使文件比传统的数据库可压缩（整数，八进制，字节，等等）性更高。
压缩减少了磁盘上的数据读取量，可以进一步提高性能。
第三，CPU只处理为所需属性的数据列，只需要在内存中缓存，节省内存资源，提高CPU的性能。
基于行存储的数据库
Source IP Dest IP Source Port Dest Port
基于列存储的数据库
图1：基于行存储数据库和基于列存储数据库文件系统布局
面向列存储的缺点之一是：一个表中包含多个files。
推测由于基于列存储可以降低磁盘带宽要求，因此基于列存储的数据库可以提高查询性能。
但是它将增加磁盘查找时间，因为查询期间在一个磁盘上要定位更多的files。
因此希望文件系统可以定制，这样可以使基于列存储数据库的file寻求时间最小化，这样提高查询性能。
这个项目的目的是为了提高基于列存储数据库的操作性能，用于探讨如何捕获和储存大容量（数兆兆字节）网络流量（目前的数据包或网络流动数据NetFlow data）的高查询性能。
因此，这个项目的数据集来自劳伦斯伯克利国家实验室（LBNL）收集了几个月的包头数据。
该网络数据在基于列的环境中运行良好，因为数据一旦写入就很少修改，使其适合于只读型的数据存储，也就适合数据仓库类型的数据存储。
2背景
为了实现这个项目，使用一个基于列存储数据库——Fastbit，而劳伦斯伯克利国家实验室的包头数据作为测试数据集。
Fastbit支持一个SQL查询语言子集和可以进行快速数据检索的位图索引。
它支持索引压缩，但没有数据压缩。
劳伦斯伯克利国家实验室的数据集有2个月的包头数据相当于2/16个网络。
该网络包含7000主机总数（3000人及其他的4000）。
数据加载到数据库中,该数据库使用SiLK网络数据分析工具包，而数据可以根据自定义的数据加载工具加载。
数据被水平划分成10万个纪录块。
这样做，主要是因为网络数据是高度突发性的。
在一个典型的环境中，数据按时间被分割，但是，这就造成了在网络高流量时出现数据量大的捕获文件，而在低流量时出现小的捕获文件。
因此保持设置分区大小，有助于在进行某些类型查询时候可以减少和预测磁盘的读取量。
在进行数据库并行操作时候还可以发挥辅助作用，因为分区可以分发和复制一些节点，在查询时候每个节点可以负责处理大约相同数量的分区。
这将有助于每台计算机在一个相同的时间段内返回查询结果。
每个数据库分区由一个列文件及其对应的索引文件组成，如图1所示。
它还包含一个分区描述文件，描述分区中的文件。
每个分区有相同数量的文件（19）。
如上所述，每个分区包含高达10万条纪录，因此，一列的大小应是相同的，列并且横跨所有事先已知的分区。
由于有些分区没有完全充满，因此，列文件的大小可能要小些，但是在一个连续的网络数据集中分区最终有望被存满。
分区文件描述了分区中的所有列（见表1 part.txt）。
既然横跨所有分区的列的数量是不变的，那么文件的大小也应和横跨所有分区的类似。
不过，分区的文件是基于文本的，所以文件的大小在每一种情况下不会完全一样。
每个数据列都有一个对应的索引文件，索引文件保存了每一列的独特值和一个位图，描述了该行以及所具有的值。
判断索引文件的大小是非常困难的，因为他们依赖于列的基数，以及位图的压缩率。
在大多数情况下，索引要比其对应的列文件小。
在某些情况下，他们要小100倍左右。
不过，也有例外，索引文件的大小类似对应的列部分，但在少数情况下，其实更大。
有一个较高基数的列往往有一个大索引文件。
例如，字节计数列可以有较宽的值，因此一些索引文件的字节数要高于列。
3 方法
在这个项目中，打算修改现有的Linux文件系统模块，以便在磁盘上最佳地安排数据库文件，以提高阅读磁盘能力。
知道一个分区的文件数目和大概空间将提供一些磁盘上的分区安排优势，以减少某些特定查询的磁盘寻找时间。
在Linux中，文件系统建成独立的内核，形成可以从操作系统中加载和卸载的模块。
方法是利用自定义的一个简单的Linux文件系统为基础的系统模块，并修改它以直接支持数据库分区。
初步选定MINIX v2的文件系统作为基础平台。
MINIX开始建立时是作为学
习操作系统课程学生的学习工具。
在被Ext2取代之前，它适应并成为第一个Linux文件系统。
选择MINIX，是因为它简单。
与Ext2不同，MINIX只支持一个超级块、索引节点（inode）位图、和数据块位图。
这将使它更容易理解和修改模块。
除了修改MINIX的模块，还可能要修改虚拟文件系统的某些方面，尽管目前还不清楚这是否必要。
另一个应用程序可能需要修改的是“mkfs.minix“应用程序，该程序用于格式化硬盘驱动器和安排超级块以及和磁盘上的索引节点（inode）和数据位图。
表1 数据库分区中的文件
如何定位到分区展开。
块预分配将是这一发展的一个重要方面，因为希望确保特定文件与特定的分区块相当接近，以减少磁盘寻道时间。
此项努力的大部分预计将集中在对新系统的设计和评价方面。
4试验环境
为了实施这个项目，使用一个安装在VMware的虚拟机（VM）中的Fedora14。
将建立注册在MINIX操作系统中的一个最新的特殊调试版本内核和模块。
这将允许我们在开发中万一有错误时候启动这两个核心模块。
使用“mkfs.minix“在虚拟机中创建5GB的空间并格式化以创建MINIX版本2文件系统。
期望建立由自定义的文件系统模块管理的另外5 GB的磁盘空间。
然后，可以在两个磁盘上加载相同的数据库分区，以便进行系统评价。
5评价和预期成果
为了评估自定义文件系统，打算在通用的Minix文件系统和自定义文件系统中装载一个小规模的数据库分区（可能是5至10个）然后，将选择大约10个不同的数据库查询，其查询范围如下：
1.改变数据库分区的装载量。
将尝试查询只涉及一个分区和查询所有的分区情况。
2.改变列（属性）的返回量。
预期查询时间会因查询返回的列不同而改变——返回更多的列意味着更多的文件和更长的时间。
3.索引查询- 即只有查询索引文件，而不是查询列数据。
将在两个文件系统（刷新磁盘高速缓存之间）中执行5次以记录返回的时间和结果。
这样，可以计算出两个系统上查询的均值和标准差。
算法是在查询时，安排一个分区上的文件与磁盘密切结合，最大限度地减少磁盘寻道时间。
此外，按时间顺序写磁盘分区，以便降低分区寻找时间。
最后，希望利用这一算法可以减少磁盘文件碎片，进一步提高查询性能和使磁盘空间最大化。
一般来说，期望定制文件系统所显示的查询性能要比普通Minix文件系统明显改善。
六，结论
该项目研究一个定制的文件系统，以减少一般文件系统的寻找时间，最终用于提高基于列存储数据库性能。
该文件系统对基于列存储数据库有一个很大的影响，因为每一个关系表的属性是存储在一个单独的文件中，这意味着打开该文件时，必须寻找到文件在磁盘上的位置。
希望通过聚类分区，可以减少磁盘的寻找读取，
从而提高性能。
打算建立和评估的自定义文件系统用的是来自劳伦斯伯克利国家实验室的包头数据集和Fastbit的基于列存储数据库，并将其与MINIX的第2版（Linux）文件系统执行情况进行对比。
评价将包括执行对基于列存储的两种文件系统的查询和比较。
希望自定义文件系统能够显示对现有Minix文件系统性能的改善。