自定义平面文件数据库 - 如何设计它们？

Question

通常我会将SQL / SQLite / Mongo用于任何数据库-y但我认为尝试创建自己的平面文件数据库结构会很有趣（它只是一个学习项目）。应用程序本身是一个音乐流，在服务器上有一个集中的库。

数据库：

我的应用程序是客户端/服务器，其中服务器所做的任何更改都会同步到所有客户端。服务器确实插入，编辑和删除操作。

客户端只能更改记录中的客户端修饰符布尔字段（其值特定于该客户端）。没有其他操作可供客户端使用，因此无需更改即可同步。

在初始数据库构建之后，服务器上的写操作很少，但确实发生了。这里的优先级肯定是客户端的读操作。

需要可扩展至500k +轨道或2GB（2 ^ 31字节）数据库文件大小（始终是第一位）。

存储的内容：

• 几张桌子，有一些关系。它只是一个模型，但你明白了这个想法：

+--------+         +--------+         +-------------------+
| id*    |         | id*    |         | id*               |
| ARTIST | ------> | ARTIST |         | track name        |
|        |         | ALBUM  | ------> | ALBUM             |
|        |         | year   |         | length            |
|        |         |        |         | filename**        |
|        |         |        |         | {client modifier} |
+--------+         +--------+         +-------------------+

* unique identifier
** not stored in client version of database
{client modifier} is only on the client version of database

必须克服的一个问题是如何处理关系并寻求最小化I / O操作。

• 所有字段都是可变长度，除了id，year＆amp;长度。

必备功能：

• Sever能够以最少的操作将数据库同步到所有客户端。

解决此问题的一种方法是存储上次修改每条记录的日期/时间，并让客户端存储上次同步的日期。当客户端联机时，所有更改都会将该日期同步回客户端。另一种方法是在服务器上有一个单独的表，列出已发生的所有操作及其发生的日期;并以类似的方式同步。

• 客户的快速阅读操作

由于表格较小，客户可以将艺术家，专辑表存储在内存中，但我会假设他们不会这样做。

我想要做的是为每个表分别创建文件，客户端始终打开每个文件以确保他们能够尽快阅读...这是个坏主意吗？

必须为每个表存储某种索引，以便每条记录的起始位置。这可能足够小，可以加载到内存中，并且可以存储在与实际表分开的文件中，以避免出现问题。

• 最小化I / O操作

服务器将使用id和文件名在内存中存储track数据库的“索引”，以便将读取操作保持在最低限度。

服务器还将缓冲数据库写操作，这样如果它检测到很多写操作将在很短的时间内发生，它将等待然后进行批量写操作。这是可能的，因为对文件系统的更改仍然是数据库崩溃，因此它可以在重新启动时重新加载所有更改。

• 非稀疏文件，以将文件大小保持在最低限度。

我将在字节级别工作以减小文件大小。删除记录时，主要问题是碎片。由于可变长度字段，您不能简单地在该位置添加新记录

当文件达到某个碎片级别（已删除的记录与记录的比率）时，我可以对文件进行解密，但我宁愿避免这种情况，因为这对于客户来说这将是一项昂贵的操作。

我宁愿不使用固定长度的字段（例如文件名可能很大），但这些只在选项中出现？

的评论：

那么我该如何解决这个问题并最大限度地提高绩效呢？

是的，我正在寻找重新发明的轮子，是的，我知道我可能不会接近其他数据库的表现。

那么有没有人有任何想法/意见/见解？

感谢阅读。

Answer 1

我的建议是设计和构建您的数据库。不要担心性能。首先担心可靠性。

一次完成一项功能：

  

Sever能够以最少的操作将数据库同步到所有客户端。

这需要记录数据库更改。你有正确的想法。

  

客户端的快速读取操作

在现代PC上，您可以足够快地阅读平面文件。每个表的单独平面文件是一个很好的设计。如果平面文件足够小（域表），您可以读取它们一次并将表保留在内存中。在数据库关闭时，您将编写一次表。

  

最小化I / O操作

数据库通过读写数据块来最小化I / O操作。我马上就不会太在意这件事了。您的数据库需要可靠。

  

非稀疏文件，以将文件大小保持在最低

大多数现代PC都有足够的磁盘空间，这是另一个功能，可以推迟到以后。数据库重组通常受DBA控制，因为它是一个非常昂贵的过程。

祝你好运。

Answer 2

这是几年前我不完整的项目。我无法解释它，它已经过时了，但它已经过时了。值得尝试（我实际上并没有这样做）。它在第一印象中完全是一个杂乱无章的数据库（平面文件），但在我的理论中，它并不是最糟糕的情况。任何人都可以添加概念或改进，例如加密，速度增强，数据绑定，数据格式化等。

按结构，数据被分类到文件夹，文件等。我还认为每次执行查询时关闭文件连接都会节省内存。

请与我交谈，这是几年前提出的，所以我仍然使用ASP。现在，我正在使用Ruby-on-Rails和NodeJS（以及一些PHP）

我称之为概念文件夹 - 文件数据委托，该数据按文件夹和文件结构化为层次结构，数据库中的最小结构称为原子。

文件夹 - 文件数据委派的5个主要目标

结构

Database/


    Table1/


        Fieldsinfo/


            username.mapper (file to provide info about the username field)


            password.mapper (file to provide info about the password field)


        Records/


            username/


                recordid1.tabledata (file that contains the data/value)


                recordid2.tabledata (file that contains the data/value)


            password/


                recordid1.tabledata (file that contains the data/value)


                recordid2.tabledata (file that contains the data/value)         

…

1. 速度 一个。通过提供结构化数据库系统草案并避免每次执行操作时重写/搜索大型数据库，文件夹 - 文件数据委派旨在提高平面文件数据库系统的速度声誉。 一世。文件夹 - 文件数据委派使用文件夹和文件存储数据，当您只能通过物理路径查询记录时，无需为平面文件数据库系统构建单个文件数据库，即查询（更新/删除） /排序等）通过使用安全性优于SQL的查询操作符，进一步简化和扩展了记录集合（表）。通过重写包含单个记录信息的小文件来提高速度，而不是重写整个数据库本身。文件夹 - 文件数据委派还存储关键映射，这进一步简化了新输入数据的验证。此外，您可以为您的应用程序创建无限制的访问门户，当一个门户正在使用时，将克隆一个新的门户文件，并且不会按顺序同时创建操作（警告：这可能导致RAM过载，使用风险自负）并将门户数量限制为适合CPU功率的数量。 II。免责声明：我们并未暗中声称文件夹 - 文件数据委派是有史以来最快的数据库，而是我们宣称使用此类算法有效地提高了速度。
2. 相干 一个。通过提供结构化数据库系统草案和草案定义组件（如集合，记录和字段），文件夹 - 文件数据委派旨在提高平面文件数据库系统的一致性。 一世。文件夹 - 文件数据委派以这种方式组织数据的有效分布几乎与关系数据库的
相似
3. 数据库 - 由相互关联的集合（文件夹）组成
4. 收藏集 - 由相互关联的唯一记录（文件夹）
组成
5. 记录 - 由相互关联的基本数据单元（文件夹）组成
6. 字段 - 由单个数据单元（文本，字符，整数，数组，对象）组成，并具有指定的查询速度和安全性长度。 （文件，由集合的字段映射器映射（定义））
7. 安全 一个。通过提供结构化数据库系统草案和NoSQL以及对数据库可能的攻击的严格过滤，文件夹 - 文件数据委派旨在提高平面文件数据库系统的安全性。 一世。文件夹 - 文件数据委派提供NoSQL数据，查询中的所有数据都被解释为数据而不是命令。查询只是访问物理路径和传输操作，然后必须以所使用的编程语言完成。这就像是一家服务公司到你家里为你提供服务和东西，你的房子就是被操纵的特定记录。
8. 简单 一个。通过提供结构化系统草案和文档草案以及计划的概念草案，文件夹 - 文件数据委派旨在提高平面文件数据库系统的安全性。 一世。文件夹 - 文件数据委派提供了一个GUI，因此如果您想要更改内容等，则无需手动执行操作和命令。操作也可以通过用户界面交互进行简化。
9. 灵活性 一个。通过提供结构化系统草案和抽象计划的数据库结构动态更新，文件夹 - 文件数据委派旨在提高平面文件数据库系统的灵活性。 一世。文件夹 - 文件数据委派会定期更新和维护，如果您的数据库受到某个可能受到威胁的黑客攻击，请不要担心;您的数据库文件夹存储在隐藏文件夹（.folder）中。