自一段時間以來，我一直在關(guān)注NoSQL的近期發(fā)展勢頭，似乎這個流行語也引起了企業(yè)Java界的某種關(guān)注。 即EclipseLink 2.4開始支持MongoDB和Oracle NoSQL 。 將EclipseLink作為JPA參考實現(xiàn)，您可能想知道這對Java EE 7意味著什么。這里簡短說明：即使我是JSR-342 EG的一部分，也并不意味著要成為正式聲明。 在下面的內(nèi)容中，我僅嘗試總結(jié)自己對使用將來的Java EE版本進行NoSQL支持的個人經(jīng)歷和感受。 非常感謝Emmanuel Bernard提供早期反饋！ 很高興討論以下內(nèi)容：

什么是NoSQL？

NoSQL是不符合關(guān)系數(shù)據(jù)庫或SQL標(biāo)準(zhǔn)的數(shù)據(jù)庫系統(tǒng)的分類。 大多數(shù)情況下，它們是根據(jù)存儲數(shù)據(jù)的方式進行分類的，并屬于諸如鍵值存儲，BigTable實現(xiàn)，文檔存儲數(shù)據(jù)庫和圖形數(shù)據(jù)庫之類的類別。 通常，對術(shù)語的定義不夠好，不足以將其簡化為支持單個JSR或技術(shù)的單個術(shù)語。 因此，找到合適的集成技術(shù)的唯一方法是深入研究每個類別。

鍵/值存儲

鍵/值存儲允許以無模式的方式存儲數(shù)據(jù)。 它可以存儲在編程語言或?qū)ο蟮臄?shù)據(jù)類型中。 因此，不需要固定的數(shù)據(jù)模型。 顯然，這可以與JSR 338 （Java持久性2.1）和JSR 347 （Java平臺的數(shù)據(jù)網(wǎng)格）的部分相媲美，也可以與JSR 107 （ JCACHE – Java臨時緩存API ）一起完成。

使用本地JPA2

JPA L2緩存也是主要用于緩存的對象。 JPA緩存API非常適合基本的緩存操作，而L2緩存在各種持久性上下文中共享實體的狀態(tài)（在實體管理器工廠的幫助下可以訪問該實體的狀態(tài)）。 2級緩存是持久性上下文的基礎(chǔ)，而持久性上下文對應(yīng)用程序是高度透明的。 啟用2級緩存后，持久性提供程序?qū)⑹紫仍诔志眯陨舷挛闹胁檎覍嶓w。 如果在此處找不到它們，則持久性提供程序?qū)⒃谙乱粋€二級緩存中查找，而不是向數(shù)據(jù)庫發(fā)送查詢。 顯然，這里的缺點是，到今天為止，它僅與NoSQL一起用作某種“緩存”。 而不是代替RDBMS數(shù)據(jù)存儲。 考慮到此規(guī)范的范圍，將是一個很好的選擇：但是我堅信JPA旨在作為RDBS的抽象，而沒有別的。 如果必須對非關(guān)系數(shù)據(jù)庫提供某種支持，那么我們可能最終會擁有一個更高層次的抽象層，其中包含許多不同的持久性模式和功能（例如Spring Data ）。 通常，在對象級別進行映射具有許多優(yōu)點，包括考慮對象的能力以及讓基礎(chǔ)引擎根據(jù)需要驅(qū)動反規(guī)范化。 因此，將JPA減少到緩存功能可能是錯誤的決定。

使用JCache

JCache具有一個CacheManager來保存和控制Cache的集合，每個Cache都有它的條目。 基本的API可以認為具有類似地圖的功能，并具有其他功能（請參閱Greg的博客 ）。 由于JCache被設(shè)計為“緩存”，并使用它作為針對NoSQL數(shù)據(jù)存儲的標(biāo)準(zhǔn)接口，因此乍一看并不適合。 但是，鑒于使用企業(yè)Java的非結(jié)構(gòu)化基于鍵/值的數(shù)據(jù)的用例的性質(zhì)，這可能是正確的集成方式。 NoSQL概念還允許使用“ RAM中的鍵值緩存”類別，該類別完全適合JCache和DataGrid。

使用DataGrids

該JSR提出了一個API，用于與內(nèi)存中和基于磁盤的分布式數(shù)據(jù)網(wǎng)格進行交互。 該API旨在允許用戶以異步且無阻塞的方式在數(shù)據(jù)網(wǎng)格（PUT，GET，REMOVE）上執(zhí)行操作，并返回java.util.concurrent.Futures而不是實際的返回值。 此刻的過程目前還不是很明顯（至少對我而言）。 因此，到目前為止，還沒有任何有關(guān)NoSQL鍵/值存儲集成的示例或概念。 除此之外，還有與JCache API相同的保留。

使用EclipseLink

EclipseLink的NoSQL支持基于自EclipseLink 1.0以來提供的以前的EIS支持。 EclipseLink的EIS支持允許將對象持久保存到舊數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫。 EclipseLink的EIS和NoSQL支持使用Java連接器體系結(jié)構(gòu)（JCA）來訪問數(shù)據(jù)源，這類似于EclipseLink的關(guān)系支持使用JDBC的方式。 通過創(chuàng)建EclipseLink EISPlatform類和JCA適配器，EclipseLink的NoSQL支持可以擴展到其他NoSQL數(shù)據(jù)庫。 目前，它支持MongoDB（面向文檔）和Oracle NoSQL（BigData）。 有趣的是，Oracle沒有首先解決鍵/值數(shù)據(jù)庫。 可能是因為可能與緩存功能（例如一致性）混淆。

基于列的數(shù)據(jù)庫

讀取和寫入使用列而不是行完成。 最著名的例子是Google的BigTable以及受BigTable啟發(fā)的HBase和Cassandra之類的東西。 BigTable論文說BigTable是一個稀疏，分布式，持久性，多維排序的Map。 例如，GAE僅適用于BigTable。 它提供了各種API：從“本地”低級API到“本地”高級API（ JDO和JPA ）。 Google使用了較舊的Datanucleus版本，似乎有很多限制可以刪除（ 請參閱注釋 ），但仍然存在。

面向文檔的數(shù)據(jù)庫

顯然，面向文檔的數(shù)據(jù)庫最好由JSR 170 （Java的內(nèi)容存儲庫）和JSR 283 （Java Technology API版本2.0的內(nèi)容存儲庫）解決。 使用JackRabbit作為參考實現(xiàn)，這是一個有力的信號：) 到目前為止 ，對其他NoSQL文檔存儲的支持已不存在。 甚至Apache的CouchDB也沒有提供符合JSR 170/283的訪問文檔的方式。 唯一的缺點是，兩個JSR都不是性感的也不是前沿。 但是對我來說，這將是對面向文檔的數(shù)據(jù)庫的支持的正確選擇。反面是內(nèi)容存儲庫API并不是應(yīng)用程序的自然模型。 應(yīng)用程序真的要處理Java中的節(jié)點和屬性嗎？域模型的概念對許多應(yīng)用程序都適用，如果沒有機會使用它，那么最好直接使用本機并直接使用MondoDB驅(qū)動程序。

面向圖的數(shù)據(jù)庫

這種數(shù)據(jù)庫被認為是用于以圖形形式很好地表示關(guān)系的數(shù)據(jù)（元素之間相互關(guān)聯(lián)的關(guān)系數(shù)量不確定）。 主要針對任何一種網(wǎng)絡(luò)拓撲，最近被拒絕的JSR 357（社交媒體API）將是提供支持的好地方。 至少從用例的角度來看。 如果將那些面向圖形的DB視為數(shù)據(jù)存儲，則有兩種選擇。 如果Java EE持久性正朝著更通用的數(shù)據(jù)抽象層的方向發(fā)展，那么338或其后繼者將是提供支持的合適之地。 如果您對Coherence在內(nèi)部的工作原理有所了解，并且需要做些什么才能將JPA放在首位，那么您也可以認為347非常適合它。 具有已經(jīng)提到的所有缺點。 另一種選擇是為其提供單獨的JSR。 該類別中最杰出的代表是Neo4J，它本身具有易于使用的API，可以將您需要的所有內(nèi)容直接直接包含到項目中。 如果需要通過應(yīng)用程序服務(wù)器控制Neo4J實例，還需要考慮其他事項。

結(jié)論

總結(jié)一下：對于所謂的“ NoSQL”數(shù)據(jù)庫，我們已經(jīng)有了很多東西。 將其集成到新的Java EE標(biāo)準(zhǔn)中的基礎(chǔ)工作很有希望。 嵌入式NoSQL實例的控制應(yīng)通過JSR 322（Java EE連接器體系結(jié)構(gòu)）完成，這是唯一允許的場所生成線程并直接從文件系統(tǒng)打開文件。 我并沒有大力支持該平臺具有與Spring對Spring Data所做的相當(dāng)?shù)耐ㄓ脭?shù)據(jù)抽象JSR。 對我而言，不同的NoSQL類別的概念與采用一種千篇一律的方法太不同了.NoSQL的主要痛點除了缺乏標(biāo)準(zhǔn)API之外，還在于用戶被迫通過以下方式進行非規(guī)范化和維護非規(guī)范化：手。

我希望看到的是對產(chǎn)品進行了一些較小的更改，以使它們更適合Java EE，并且還完成了與規(guī)范的集成。 最好簡單地定義不同的持久性類型，并通常定義可能受此影響的JSR，并相應(yīng)地對它們進行noSQL處理。

對于愿意促進域模型的用戶（即，與原始NoSQL API相比，抽象級別更高），JPA可能是目前的最佳工具。 需要EclipseLink和Hibernate OGM用戶的反饋，以評估有效的方法和無效的方法。 從政治角度來看，追求347也可能是有意義的。特別是因為主要的主要參與者已經(jīng)在這里出現(xiàn)。

真正困難的部分是查詢。每個系列是否應(yīng)該有標(biāo)準(zhǔn)化的查詢API？ 使用Java EE？ 還是最好將其放置在NoSQL空間中？ 很想閱讀您對此的反饋！

參考： JCG合作伙伴 Markus Eisele在Java企業(yè)軟件開發(fā)博客上的NoSQL with Java EE的未來 。

翻譯自: https://www.javacodegeeks.com/2012/05/future-of-nosql-with-java-ee.html

總結(jié)

以上是生活随笔為你收集整理的Java EE与NoSQL的未来的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。