线性的地址空间 如何存储线性可变数据 本帖最后由 shigaofei1 于 2011-11-15 12:04:28 编辑 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 根据什么说操作系统中文件的存储是线性的？知道或看过FAT，NTFS的分配单元，4k，8k？至少猜猜他们是作什么用的。 链表结构 解决不了这个问题这个问题是 实际的文件存储问题打个比方文件 A点处存储了一个长度为L的数据那么我要修改该数据 结果还是一样啊，还是要移动该数据向后的所有数据啊。如果我留下足够大的字节空间给每一个结构而且何况 我单独的一个区块还要动态添加新的Object所以在一定程度上可以解决但又会导致文件空间的浪费 既然想“设计一个单文件数据库的文件”，为什么不参考别人的数据库存储管理？这个领域，学术上已经非常成熟，资料和文献也非常的丰富。比如说微软SQL的页和区体系结构？http://msdn.microsoft.com/zh-cn/library/cc280360.aspx 根据进一步的搜索 查看 各项资料...现在 知道 基本上 数据库 貌似 都是 固定块划归固定大小的就好像 我们 定义一个 新的表 都要输入 类型，大小（长度）等相关信息。恩，看来即使是 想Oracle这样的数据库 也没有什么更好的策略，尽管Oracle很成功当某区域 信息失效时会，被标识。以备后用...而不是将后面的所有数据向后挪... 方案一：获取 磁盘扇区簇并且自己管理，在必要的时候修改簇指针 方案二：对数据文件进行预划分，然后使用索引值进行true/false 和文件分块指针集管理方案二比较容易实现，但是并不是很节约空间。方案一是最好的，但是技术上有难点，主要是 .net操作扇区可能比较困难，至少 似乎没有搜索到相关已有的实现... 你说的对，也不对。其实你翻开最近30年的任何一本数据库操作系统教程，都可以看到有磁盘管理系统作为基础。你不能说它是关系数据库了，所以就不用考虑磁盘管理基本概念了，应该搞什么更加时髦的概念了。关系数据库的磁盘管理，与操作系统的磁盘管理是两回事，但是也有相互借鉴的意义，甚至很大程度上是相同的（最近两年超级时髦的Mongo数据库则是16M一个磁盘数据块的）。关系数据库的磁盘块往往是操作系统的磁盘块大小的整倍数，例如可能是256K或者4M一个数据块都有可能。数据库保持两个链表，一个是所有的有数据的的磁盘块，一个是所有的空闲磁盘块。有数据的磁盘块，例如一个1024为大小的块吧，它可能保存一条或者多条记录。当记录修改的时候，如果要扩大，但是原来的空间放不下了，就可以转移到其它的磁盘块上去；如果空间放得下一条记录，那么记录之间有一点空隙也是正常的，没有必要立刻移动记录的位置。 有数据的磁盘块，例如一个1024为大小的块吧 --> 有数据的磁盘块，例如一个1024K为大小的块吧例如说我们知道SQL Server的记录最大也不到8K（实际上比8K小几十个字节，显然磁盘块里边需要有管理信息），而Mongo则是16M。后者经过了仔细的测试，证明16M要比8K高效多了（当然也是因为管理方式不同）。磁盘块里边当然可以有多条记录，而不是只能有一条。 看来你很难想象磁盘中的链表如何保存。举个例子。比如说1024K为一个块，那么你每一次以随机存取方式去读取数据库文件时，都是以1024K的整倍数为偏移量来开始读取1M字节的。假设你规定文件中前128个字节保存有一些主要管理信息，例如两个链表的第一个块的块号，那么读取第1001块数据那么当然就是从(1001-1)*1024+128字节开始读取1M的字节。而每一个磁盘块的前4个字节可以是指向之前的磁盘块号，第5～8个字节指向之后的磁盘块号，这就可以形成链表。 16M=256*64KB一个byte可以表示256个数字操作系统内存粒度大小是64KB我怀疑Mongo可能是为了1.索引时长度更短时间更快2.内存读取时按64KB为单位整块读取更加方便3.16M是一个适中的数据4.节约空间，256个内存块 这个数字多也不算多，少也不算少。在建立索引时只需要一个字节即可标出数据块位置， 没搞混 我说的是内存映射文件32位操作系统 内存粒度为每单元 64KB，微软建议使用这个粒度的整数进行内存操作。当然实际的我还是调用GetSystemInfo函数获取的这个值并且验证了网上的说法。 mongo不索引这些16M磁盘映像，而且完全无需索引。上面我也从来没有说过有什么关系数据库需要索引这个，顶多是需要链表而你，你怎么随便就给说成是索引了呢？关于你说的有关“字节”的一些理由，我不太理解。数据库管理的关键是建立高层次的管理机制，至于性能需要以测试为准，而不是空洞地抠字节概念。比如说你认为256字节比较“合理”，人家可能测试出512字节合理，谁更合理？当然是以测试为准。 我说的不是数据库中我们平时说的索引，而是比如 某一个数据位于 假设16M文件单元真的分为256个块，每个块分为64KB，而这64KB中可以存储若干数据如果我要表示这个某个数据的存储位置的话：存储这个数据时记录将16M文件这个单元的256个分块的第几块，64KB中的第几字节开始，然后是数据长度这样 我先排除 16M的文件单元的编号，如果我要 获取这个数据的位置以及长度的话可以这样表示：1个字节表示块在文件中的位置，2个字节表示数据在块中的位置，再用一个或者两个字节表示长度。这样在查找的时候利用这个“索引”就可以迅速找到相应的位置，至于256这个数 是因为 一个Byte总共可以表示256个数，如果您说512的话就要用两个字节了，两个字节仅仅表示512的话是很浪费的。数据库必须在保证 检索速度的同时尽量 减少空间的使用。 为啥要用，2个字节表示数据在块中的位置呢，我是这么想的，64KB内存页面=2个字节，也就是 ushort所能表示的最大值对于mongo 还真是不太清楚，看来 我得去 大肆搜索一翻 看看有没有相关的技术分析文章 请教dataGridView2绑定的一个问题 关于匿名方法和lambda表达式 在GroupBox上画线的问题（新手请教） 菜鸟求救c#高手！麻烦咯 ViewState问题 C# Winform程序用OleDbDataAdapter配合DataGird更新数据库问题 如何操作 一个EXE程序 中的输入输出？ 从面试题狗咬猫猫咬耗子猫叫耗子叫来理解多态 DataGrid问题：在数据中为11：00：00，可是到了dataGrid中变成了1899-00-00 给解决下！ c#难吗? ArgumentNullException值不能为空。\r\n参数名: item
至少猜猜他们是作什么用的。
这个问题是 实际的文件存储问题打个比方文件 A点处存储了一个长度为L的数据
那么我要修改该数据 结果还是一样啊，
还是要移动该数据向后的所有数据啊。如果我留下足够大的字节空间给每一个结构而且何况 我单独的一个区块还要动态添加新的Object
所以在一定程度上可以解决但又会导致文件空间的浪费
http://msdn.microsoft.com/zh-cn/library/cc280360.aspx
现在 知道 基本上 数据库 貌似 都是 固定块划归固定大小的
就好像 我们 定义一个 新的表 都要输入 类型，大小（长度）等相关信息。恩，看来即使是 想Oracle这样的数据库 也没有什么更好的策略，尽管Oracle很成功当某区域 信息失效时会，被标识。以备后用...
而不是将后面的所有数据向后挪...
方案二比较容易实现，但是并不是很节约空间。
方案一是最好的，但是技术上有难点，主要是 .net操作扇区可能比较困难，至少 似乎没有搜索到相关已有的实现...
你说的对，也不对。其实你翻开最近30年的任何一本数据库操作系统教程，都可以看到有磁盘管理系统作为基础。你不能说它是关系数据库了，所以就不用考虑磁盘管理基本概念了，应该搞什么更加时髦的概念了。关系数据库的磁盘管理，与操作系统的磁盘管理是两回事，但是也有相互借鉴的意义，甚至很大程度上是相同的（最近两年超级时髦的Mongo数据库则是16M一个磁盘数据块的）。关系数据库的磁盘块往往是操作系统的磁盘块大小的整倍数，例如可能是256K或者4M一个数据块都有可能。数据库保持两个链表，一个是所有的有数据的的磁盘块，一个是所有的空闲磁盘块。有数据的磁盘块，例如一个1024为大小的块吧，它可能保存一条或者多条记录。当记录修改的时候，如果要扩大，但是原来的空间放不下了，就可以转移到其它的磁盘块上去；如果空间放得下一条记录，那么记录之间有一点空隙也是正常的，没有必要立刻移动记录的位置。
16M=256*64KB
一个byte可以表示256个数字
操作系统内存粒度大小是64KB我怀疑Mongo可能是为了
1.索引时长度更短时间更快
2.内存读取时按64KB为单位整块读取更加方便
3.16M是一个适中的数据
4.节约空间，256个内存块 这个数字多也不算多，少也不算少。
在建立索引时只需要一个字节即可标出数据块位置，
32位操作系统 内存粒度为每单元 64KB，微软建议使用这个粒度的整数进行内存操作。
当然实际的我还是调用GetSystemInfo函数获取的这个值并且验证了网上的说法。
mongo不索引这些16M磁盘映像，而且完全无需索引。上面我也从来没有说过有什么关系数据库需要索引这个，顶多是需要链表而你，你怎么随便就给说成是索引了呢？关于你说的有关“字节”的一些理由，我不太理解。数据库管理的关键是建立高层次的管理机制，至于性能需要以测试为准，而不是空洞地抠字节概念。比如说你认为256字节比较“合理”，人家可能测试出512字节合理，谁更合理？当然是以测试为准。
比如 某一个数据位于
假设16M文件单元真的分为256个块，每个块分为64KB，而这64KB中可以存储若干数据如果我要表示这个某个数据的存储位置的话：存储这个数据时记录将16M文件这个单元的256个分块的第几块，64KB中的第几字节开始，然后是数据长度这样 我先排除 16M的文件单元的编号，如果我要 获取这个数据的位置以及长度的话可以这样表示：
1个字节表示块在文件中的位置，2个字节表示数据在块中的位置，再用一个或者两个字节表示长度。这样在查找的时候利用这个“索引”就可以迅速找到相应的位置，至于256这个数 是因为 一个Byte总共可以表示256个数，如果您说512的话就要用两个字节了，两个字节仅仅表示512的话是很浪费的。数据库必须在保证 检索速度的同时尽量 减少空间的使用。
为啥要用，2个字节表示数据在块中的位置呢，我是这么想的，
64KB内存页面=2个字节，也就是 ushort所能表示的最大值对于mongo 还真是不太清楚，看来 我得去 大肆搜索一翻 看看有没有相关的技术分析文章