java nosql_Java EE的NoSQL的未来

java nosql

从现在开始一段时间以来，我一直在关注NoSQL的近期发展势头，似乎这个流行语也引起了企业Java界的某种关注。即EclipseLink 2.4开始支持MongoDB和Oracle NoSQL 。将EclipseLink作为JPA参考实现，您可能想知道这对Java EE 7意味着什么。在这里简短说明一下：即使我是JSR-342 EG的一部分，也并不意味着要成为正式声明。在下面的内容中，我仅尝试总结自己对使用将来的Java EE版本进行NoSQL支持的个人经历和感受。非常感谢Emmanuel Bernard提供早期反馈！很高兴讨论以下内容：

什么是NoSQL？

NoSQL是不符合关系数据库或SQL标准的数据库系统的分类。大多数情况下，它们是根据存储数据的方式进行分类的，并属于诸如键值存储，BigTable实现，文档存储数据库和图形数据库之类的类别。通常，该术语的定义不够好，无法将其简化为支持单个JSR或技术的单个术语。因此，找到合适的集成技术的唯一方法是深入研究每个类别。

键/值存储

键/值存储允许以无模式的方式存储数据。它可以存储在编程语言或对象的数据类型中。因此，不需要固定的数据模型。显然，这可以与JSR 338 （Java持久性2.1）和JSR 347 （Java平台的数据网格）的部分相媲美，还可以与JSR 107 （ JCACHE – Java临时缓存API ）一起完成。

使用本地JPA2

JPA L2缓存也是主要用于缓存的对象。 JPA缓存API非常适合基本的缓存操作，而L2缓存在各种持久性上下文中共享实体的状态（可在实体管理器工厂的帮助下进行访问）。 2级缓存是持久性上下文的基础，而持久性上下文对应用程序是高度透明的。启用2级缓存后，持久性提供程序将首先在持久性上下文中查找实体。如果在此处找不到它们，则持久性提供程序将在下一个二级缓存中查找，而不是向数据库发送查询。显然，这里的缺点是，到今天为止，它仅在NoSQL中作为某种“缓存”起作用。而不是代替RDBMS数据存储。考虑到该规范的范围，将是一个很好的选择：但是我坚信JPA旨在作为RDBS的抽象，而没有别的。如果必须对非关系数据库提供某种支持，我们可能最终会拥有一个更高层次的抽象层，其中包含许多不同的持久性模式和功能（例如Spring Data ）。通常，在对象级别进行映射具有许多优点，包括考虑对象的能力以及在需要时让底层引擎驱动反规范化。因此，将JPA减少到缓存功能可能是错误的决定。

使用JCache

JCache具有CacheManager来保存和控制Cache的集合，每个Cache都有它的条目。基本的API可以认为具有类似地图的功能，并具有其他功能（请参阅Greg的博客）。由于JCache被设计为“缓存”，并使用它作为针对NoSQL数据存储的标准接口，因此乍一看并不适合。但是，鉴于使用企业级Java的非结构化基于键/值的数据的用例的性质，这可能是正确的集成方式。 NoSQL概念还允许使用“ RAM中的键值缓存”类别，该类别完全适合JCache和DataGrid。

使用DataGrids

该JSR提出了一个API，用于与内存中和基于磁盘的分布式数据网格进行交互。该API旨在允许用户以异步且非阻塞的方式在数据网格（PUT，GET，REMOVE）上执行操作，并返回java.util.concurrent.Futures而不是实际的返回值。此刻的过程目前还不是很明显（至少对我而言）。因此，直到今天，还没有任何有关NoSQL键/值存储集成的示例或概念。除此之外，还有与JCache API相同的保留。

使用EclipseLink

EclipseLink的NoSQL支持基于自EclipseLink 1.0开始提供的以前的EIS支持。 EclipseLink的EIS支持允许将对象持久保存到旧数据库和非关系数据库。 EclipseLink的EIS和NoSQL支持使用Java连接器体系结构（JCA）来访问数据源，类似于EclipseLink的关系支持使用JDBC的方式。通过创建EclipseLink EISPlatform类和JCA适配器，EclipseLink的NoSQL支持可以扩展到其他NoSQL数据库。目前，它支持MongoDB（面向文档）和Oracle NoSQL（BigData）。有趣的是，Oracle没有首先解决键/值数据库。可能是因为可能与缓存功能（例如一致性）混淆。

基于列的数据库

读取和写入使用列而不是行完成。最著名的例子是Google的BigTable，以及受BigTable启发的HBase和Cassandra之类的东西。 BigTable论文说BigTable是一个稀疏，分布式，持久性，多维排序的Map。例如，GAE仅适用于BigTable。它提供了多种API：从“本地”低级API到“本地”高级API（ JDO和JPA ）。 Google使用了较旧的Datanucleus版本，似乎有很多限制可以删除（请参阅注释），但仍然存在。

面向文档的数据库

面向文档的DB最明显地最好由JSR 170 （Java的内容存储库）和JSR 283 （Java Technology API版本2.0的内容存储库）解决。使用JackRabbit作为参考实现，这是一个有力的信号：)截至目前，对其他NoSQL文档存储的支持已不存在。甚至Apache的CouchDB也没有提供符合JSR 170/283的访问文档的方式。唯一的缺点是，两个JSR都不性感或没有前沿性。但是对我来说，这将是支持面向文档的DB的正确选择。反面是？内容存储库API并不是应用程序的自然模型。应用程序真的要处理Java中的节点和属性吗？域模型的概念对许多应用程序都适用，如果没有机会使用它，那么最好直接使用本机并直接使用MondoDB驱动程序。

面向图的数据库

这种数据库被认为是用于以图形形式很好地表示关系的数据（元素之间相互关联的不确定数量的关系）。主要针对任何一种网络拓扑，最近被拒绝的JSR 357（社交媒体API）将是提供支持的好地方。至少从用例的角度来看。如果将那些面向图形的DB视为数据存储，则有两种选择。如果Java EE持久性正朝着更通用的数据抽象层的方向发展，那么338或其后继者将是提供支持的合适之地。如果您对Coherence在内部的工作原理有所了解，并且需要做些什么才能将JPA放在首位，那么您也可以认为347非常适合它。具有已经提到的所有缺点。另一种选择是为其提供单独的JSR。该类别中最杰出的代表是Neo4J，它本身具有易于使用的API，可以将您需要的所有内容直接包含到项目中。如果需要通过应用程序服务器控制Neo4J实例，还需要考虑其他事项。

结论

总结一下：对于所谓的“ NoSQL”数据库，我们已经有了很多准备。将其集成到新的Java EE标准中的基础工作很有希望。嵌入式NoSQL实例的控制应通过JSR 322（Java EE连接器体系结构）来完成，这是唯一允许的场所生成线程并直接从文件系统打开文件。我并没有大力支持该平台具有与Spring对Spring Data所做的相当的通用数据抽象JSR。对我而言，不同的NoSQL类别的概念与采用一种千篇一律的方法太过不同了.NoSQL的主要痛点除了缺乏标准的API之外，还在于用户被迫通过以下方式去规范化并保持去规范化手。

我希望看到的是对产品进行了一些较小的更改，以便更加支持Java EE，并且还完成了对规范的集成。简单定义不同的持久性类型并通常定义可能受此影响的JSR并相应地对它们进行noSQL可能是一个好主意。

对于愿意促进域模型的用户（即，与原始NoSQL API相比，抽象水平更高），JPA可能是目前的最佳工具。需要EclipseLink和Hibernate OGM用户的反馈，以评估有效的方法和无效的方法。从政治角度来看，追求347也可能是有意义的。特别是由于主要的主要参与者已经在这里出现。

真正困难的部分是查询。每个家族是否应该有标准化的查询API？使用Java EE？还是最好将其放置在NoSQL空间中？很想阅读您对此的反馈！

参考： JCG合作伙伴 Markus Eisele在Java企业软件开发博客上的NoSQL with Java EE的未来。