自一段時間以來，我一直在關注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版本，似乎有很多限制可以刪除（ 請參閱注釋 ），但仍然存在。

面向文檔的數據庫

顯然，面向文檔的數據庫最好由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 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的未來 。