西安网站建设哪家好,国内新闻50条简短,贵州省建设网官方网站,代理一个手游需要多少钱自一段时间以来#xff0c;我一直在关注NoSQL的近期发展势头#xff0c;似乎这个流行语也引起了企业Java界的某种关注。 即EclipseLink 2.4开始支持MongoDB和Oracle NoSQL 。 将EclipseLink作为JPA参考实现#xff0c;您可能想知道这对Java EE 7意味着什么。这里简短说明我一直在关注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旨在允许用户以异步且无阻塞的方式在数据网格PUTGETREMOVE上执行操作并返回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 NoSQLBigData。 有趣的是Oracle没有首先解决键/值数据库。 可能是因为可能与缓存功能例如一致性混淆。 基于列的数据库 读取和写入使用列而不是行完成。 最著名的例子是Google的BigTable以及受BigTable启发的HBase和Cassandra之类的东西。 BigTable论文说BigTable是一个稀疏分布式持久性多维排序的Map。 例如GAE仅适用于BigTable。 它提供了各种API从“本地”低级API到“本地”高级API JDO和JPA 。 Google使用了较旧的Datanucleus版本似乎有很多限制可以删除 请参阅注释 但仍然存在。 面向文档的数据库 显然面向文档的数据库最好由JSR 170 Java的内容存储库和JSR 283 Java Technology API版本2.0的内容存储库解决。 使用JackRabbit作为参考实现这是一个有力的信号) 到目前为止 对其他NoSQL文档存储的支持已不存在。 甚至Apache的CouchDB也没有提供符合JSR 170/283的访问文档的方式。 唯一的缺点是两个JSR都不是性感的也不是前沿。 但是对我来说这将是对面向文档的数据库的支持的正确选择。反面是内容存储库API并不是应用程序的自然模型。 应用程序真的要处理Java中的节点和属性吗域模型的概念对许多应用程序都适用如果没有机会使用它那么最好直接使用本机并直接使用MondoDB驱动程序。 面向图的数据库 这种数据库被认为是用于以图形形式很好地表示关系的数据元素之间相互关联的关系数量不确定。 主要针对任何一种网络拓扑最近被拒绝的JSR 357社交媒体API将是提供支持的好地方。 至少从用例的角度来看。 如果将那些面向图形的DB视为数据存储则有两种选择。 如果Java EE持久性正朝着更通用的数据抽象层的方向发展那么338或其后继者将是提供支持的合适之地。 如果您对Coherence在内部的工作原理有所了解并且需要做些什么才能将JPA放在首位那么您也可以认为347非常适合它。 具有已经提到的所有缺点。 另一种选择是为其提供单独的JSR。 该类别中最杰出的代表是Neo4J它本身具有易于使用的API可以将您需要的所有内容直接直接包含到项目中。 如果需要通过应用程序服务器控制Neo4J实例还需要考虑其他事项。 结论 总结一下对于所谓的“ NoSQL”数据库我们已经有了很多东西。 将其集成到新的Java EE标准中的基础工作很有希望。 嵌入式NoSQL实例的控制应通过JSR 322Java 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的未来 。 翻译自: https://www.javacodegeeks.com/2012/05/future-of-nosql-with-java-ee.html
