在使用关系数据时,有多种轻量级数据库可供选择,如 SQLite 和 SQL Server Compact。但当文档型数据库能够更好地满足需求时,选择余地之小令人吃惊。于是,我们创建了 Biggy。
Biggy 由 Rob Conery 发起创建,面向.NET,与 Node 的 NeDB 数据库相当。此后,它发展成为一个类 ORM 库,但遵循文档数据库的准则。表面看来,开发人员使用的似乎是正常的列表。但这些列表是由一个基于文档的存储层提供支持,比如:
- 在磁盘上的 JSON 文件中(每个记录类型 T 一个文件)
- 使用内置的 JSON 数据类型存储在 Postgres 数据库中
- 使用普通文本存储在 SQL Server 中
其它存储选项,如 MongoDB 和 Azure Table Storage,目前正在开发之中。
下面是一个例子,在 Postgres 中新建一个名为“products”的表,并把一条记录存入其中:
var products = new PGList<Product>("tekpub", "products"); var newProduct = new Product(); // 添加到表中 products.Add(newProduct);
由于所有记录的副本都存储在内存中,所以可以完全在内存中使用正常的 LINQ 查询。但如果需要更强大一点的功能,则可以针对特定的行启用全文搜索。
要实现这一点,开发人员需要将 FullText 特性应用到他想索引的属性上。这会在表创建的时候“将该列中的文本分离出来”,以便单独对它进行索引。此后,就可以在它上面进行全文搜索。
应用场景
显然,开发人员不应该使用这样一个东西将整个数据库保存在内存中。它主要用于 Rob Conery 所说的“输入数据”。这类数据很少发生变化,而且需要即时提供,如产品目录。从这种意义上讲,Biggy 很像一个可更新的缓存。
Biggy 总是实时可用,这是它与缓存的最大不同之一。典型的设计模式是,在应用程序启动的时候,把整个表从磁盘或数据库加载到内存中。在一些基础的基本问题测试中,Biggy 能够在 1 秒钟内从 Postgres 加载 10 万条记录。
不过,它确实有一些与缓存相同的局限。例如,如果同时运行一个应用程序的多个实例,那么没有办法使内存中的实例保持同步。
读者可以从 GitHub 上获取 Biggy 的源代码,它已经在开源许可证下发布。API 还处于不断变化之中,所以还没有在 NuGet 上提供。
查看英文原文:**** Introducing Biggy: An ORM-like Library for Document Databases
评论