概述

在InfoQ Dev Summit Munich上，Markus Kett介绍了一种Java数据库替代方案：内存数据库EclipseStore。EclipseStore通过将Java对象图存储为二进制文件在本地或云文件系统中，并使用Java Streams进行查询，承诺提供更快的数据处理速度，同时降低云成本和减少二氧化碳排放。然而，应用程序需要管理并发写入，并在多个JVM实例之间共享存储时使用商业版的MicroStream Cluster。

背景与问题

Java应用程序的对象图与数据库之间存在阻抗不匹配问题：关系数据库以行和列存储数据，而NoSQL数据库存储键值对、JSON文档等格式。应用程序可以通过自身进行转换或依赖如Hibernate或Spring Data等ORM框架来实现转换。无论是哪种方式，都会增加内存和CPU使用率，并导致延迟。本地缓存或远程缓存层（如Redis）可以减少延迟，但会增加复杂性和成本。

EclipseStore的特点

EclipseStore是一个Eclipse开源项目。与其他内存数据库一样，它可以仅将数据存储在RAM中，也可以持久化到本地文件系统。但在云容器中，应用程序会丢失本地文件，尤其是在使用新版本的容器镜像时。因此，像Amazon S3、Azure Blob Storage或Google Cloud Firestore这样的文件服务更适合在云中使用EclipseStore。

启动与加载

EclipseStore在启动时将存储的所有对象的ID加载到内存中，随着存储对象数量的增加，应用程序的内存需求线性增长。默认情况下，完整对象是按需延迟加载的，但也可以在初始化时预先加载。

查询方式

EclipseStore不使用SQL等查询语言，而是使用Java Stream API进行查询。例如：

List<Article> unavailableArticles =
  shop.getArticles().stream()
    .filter(article -> article.available() == false)
    .collect(groupingBy(article -> article.vendor()));

在内存中查询对象的速度为微秒级，而传统数据库查询需要数十或数百毫秒。然而，EclipseStore在存储中查询对象时速度较慢，因为可能需要从云文件存储中加载数百万个对象并在应用程序中评估它们。传统数据库服务器则在本地运行查询，仅通过网络将结果发送到Java应用程序。

数据存储与转换

EclipseStore存储对象的格式为专有的二进制格式。保存对象更改会添加一个新的二进制文件，并且是一个阻塞的、事务安全的操作。每个对象只存储一次。除了云文件系统，EclipseStore还可以使用数据库进行存储。EclipseStore不管理并发写入，因此应用程序必须防止线程相互覆盖。

垃圾回收与API

EclipseStore通过垃圾回收器删除旧的对象版本和损坏的文件。它还提供了一个显示数据的Web应用程序，并支持REST和GraphQL API。目前，流行的数据库查询工具还不支持EclipseStore。

MicroStream与商业支持

MicroStream是EclipseStore背后的公司，他们从2013年开始开发并在2021年开源，2023年成为Eclipse项目。Helidon和Micronaut提供了对EclipseStore的一流支持。

MicroStream提供了一个MicroStream Enterprise的测试版，作为EclipseStore的商业支持版本。它仅服务于单个JVM实例，但增加了索引、自动延迟加载和异步写入功能。要在多个JVM实例之间共享存储，需要使用商业版的MicroStream Cluster，该产品支持本地部署和SaaS，但不包含用户管理、日志记录、锁定或备份等数据库功能。

成本与环保对比

Kett以在亚马逊存储1TB数据并保留六个副本的年度成本和二氧化碳排放为例进行比较。一个六节点的RDS PostgreSQL集群成本为$27,048，排放3,608 kg CO2；而六个S3标准层副本的成本为$1,827，减少了93%，排放5.88 kg CO2，减少了99.84%。然而，该计算未考虑Java应用程序可能更高的内存使用率，也未计算MicroStream Cluster在多JVM实例共享存储时的许可成本。