文件儲存和關係數據庫混合。存在嗎？可能的？
有誰知道任何試圖將 Mongo DB 和 MySQL 捆綁在一起的產品或開源項目？
我聽到很多關於關係數據庫如何符合 ACID 使得幾乎不可能像在 Mongo 中那樣輕鬆地進行分片，這是阿喀琉斯之踵。NoSQL 粉絲肯定是對的。一項技術最終必須並行化或消亡。
拒絕 NoSchema
然而，無模式數據庫並不是許多問題的可持續解決方案。架構更改之所以困難，是因為它們會迫使您查看正在破壞的內容。沒有看到並不意味著你沒有打破。
兩全其美？
我需要幫助理解的是為什麼在理論上你不能同時擁有兩者的優勢似乎被接受。關係數據庫不能被設計成與最終一致性的明智策略妥協嗎？我理解為什麼它比文件更困難 - 一次提取由物理儲存在磁碟上的記錄組成。但是作為關係數據庫前端的文件儲存呢？
想像
數據庫有一個內置的 ORM可以從關係集合映射到文件集合，您可以在應用程序中與文件進行互動。本質上，文件集合就像具有回寫能力的物化視圖。預設情況下，關係數據庫部分是 ACID 兼容的，並確保非酸性文件最終是一致的。交叉記錄模式約束可能不夠高效，但大多數其他模式控制可能。
當您查詢大量文件時，如果有一些文件不同步——因為剛剛寫入了另一個共享相同非規範化數據的文件——那麼預設情況下，它們會從底層數據庫靜默刷新。如果阻塞是一個問題，那麼您可以選擇使用許多其他更鬆散的一致性選項來處理那些臟文件。
優點和優點
..和小缺點
您沒有獲得快速寫入的文件儲存優勢，但是
**獲得 NoSQL 優勢：**大規模快速讀取、易於分片以及前端開發人員沒有 OR 阻抗不匹配。
**獲得 SQL 優勢：**組織可以保持敏捷，能夠從最初沒有想到的新角度處理數據。Schema 有助於防止生產數據在為時已晚之前變成一團糟的異常。
**獲得混合優勢：**可以在 RDB 中對行進行物理重組，以遵循最常訪問的文件集合所建議的模式。當一個盒子上的關係數據庫的負載變得太高時，這將使分片更有可能（可能會權衡整個系統的分析查詢，但這就是您擁有 OLAP 的目的）。與直接面向使用者的情況相比，關係數據庫的讀取次數也會少得多。
我誤解了一些東西。我必須有。
我不認為這是一個簡單的工程，但它似乎在那些為我們帶來我們已經擁有的產品的人的權力範圍內。
我不是在這裡尋求一般性討論，但如果我在這個帳戶中缺少一個大而具體的陷阱，我不會感到驚訝，我想知道它是什麼。
SQL Server 支持 JSON，儘管它似乎是它對 XML 支持的一種變體。
PostGres 從 9.2 開始支持 JSON。自 2014 年以來，Teradata 就擁有它。
這使他們成為混血兒。顯然 PostGres 是開源的。
這實際上取決於您對 JSON 支持的需求。如果要在密鑰上返回文件，那麼在沒有明確的 JSON 支持的情況下總是可以做到的。
如果您想索引 JSON 文件的某些部分，那麼確實需要特定的 JSON 支持。問題是要索引的屬性有多稀疏。如果它存在於絕大多數情況下（甚至是強制屬性），那麼我會將它從 JSON 中分離出來，並將其作為混合儲存中的顯式屬性。
如果並行化或死亡是指支持分佈式數據集或死亡，那麼我不確定我是否同意。對於 OLTP 工作，您必須在泰晤士報 100 強公司工作才能接近傳統 RDBMS 的限制。根據定義，大多數公司並沒有像他們想的那樣生成盡可能多的有用數據。
Facebook、Twitter 和 NetFlix 等公司處理的數據數量級遠遠超出大多數人所能看到的。
對於高端網路分析工作，是的，您可能需要一個 NOSQL 產品作為收集器。Cassandra 在這方面很有用，而且它具有可調的一致性。
分佈式系統中的陷阱是 Brewers CAP 定理。您可以具有一致性、可用性或分區容差中的任何兩個。它比這更模糊，但 2 of 3 規則通常是正確的。
如何處理參照完整性以及在某些情況下如何遵守主鍵約束是一個挑戰。您的數據可能會分散在許多伺服器上，因此遵守外鍵概念可能需要在一台伺服器和另一台伺服器之間進行查找。即使這是一個功能，它也會嚴重影響性能。
如果人們想與只討論 JSON 的 API 互動，那麼我認為沒有問題，只要有一個底層 DAL 混淆數據屬性是否存在於 JSON 文件中或混合設計中的顯式屬性。
不確定這是否是您正在尋找的，但我認為 RDBMS 領域的主要參與者將添加對 JSON 的支持，就像他們幾年前添加對 XML 的支持一樣。例如，您可以查看：
http://www.ibm.com/developerworks/data/library/techarticle/dm-1306nosqlforjson1/另一種方法是添加某種產品，可以將不同的 dbms 範例粘合在一起。Apache Spark 可能就是這樣的一個例子：
http://spark.apache.org/