我想知道你会为我的用例做哪些选择。 它是关于构建一个社交网络应用程序，每个用户都有自己的个人文件系统。
规范
目前，我们出于某些原因选择MongoDB
MongoDB需要非规范化（以及ElasticSearch）
痛苦直接来自目录之间的关系部分：每个目录引用其父目录和parentId属性。这意味着当目录被加入书签并被访问时，面包屑应该可用。没有面包屑的非规范化，这会导致昂贵的递归。
在对内容进行搜索查询时，它是相同的：我希望目录的痕迹可以直接在文档中使用（实际上，我使用相同的解析器从ElasticSearch和MongoDB返回我的对象两者都在使用JSON / BSON。
因此，非规范化工作正常，直到用户移动其根目录之一，其中有数千个子类别：子类别面包屑应该更新 - ＆gt; MongoDB在这里并没有真正帮助实现一致性，并且很难将这种非规范化的面包屑维护到最新状态。
图形数据库似乎适合构建文件系统结构，但可伸缩性呢？
我不太了解像Neo4J或Titan这样的图形数据库......但它有助于构建文件系统结构吗？据我所知，图形不适合分发，并且分布用户的目录对于痕迹计算似乎不太好。
但是用户拥有自己的文件系统，这是一个单独/孤立的图形。这意味着我可能会为每个用户创建和分片图形数据库？但那么共享目录的权限呢？我应该把它们存放在哪里？
无论如何，在我的搜索引擎中，我仍然需要为文件元数据设置非规范化的痕迹（至少如果我继续使用ElasticSearch）。 并且很难对所有共享目录权限进行非规范化，以便用户可以搜索另一个用户的内容的子集。 无论如何，似乎很难为搜索索引图形： How to store tree data in a Lucene/Solr/Elasticsearch index or a NoSQL db?
MongoDB可能不是存储像用户这样的结构化和近乎静态内容的不错选择
另一件重要的事情是一致性。创建新用户时，我需要创建8个根目录。这些根目录不是用户文档的子文档。那么我应该如何在用户创建过程中创建这些目录？ MongoDB没有事务，所以如何确保9个插入是以原子方式完成的（用户+8个目录）。用一半的目录创建用户对我们来说不太好。在用户文档上创建异步作业和标志来检查目录是不是很好......
因此，传统的SQL数据库（免费）似乎很好的一致性，以存储用户相关的数据。可伸缩性可以使用应用程序级别的分区来完成，就像Facebook或Tumblr一样。用户相关数据可以共存到同一个实例，以便能够执行一些连接：例如，在用户的文件系统上......我知道SQL和多租户策略。
所以最后，我完全迷失在这个NoSQL / SQL世界中。我只是想知道你是否可以帮助我做出这个用例的选择？
我不是想过度优化，只是为了看看我们将来可能需要做些什么。
有人知道任何正在做类似事情的公司吗？
我想到的一些事情是使用混合解决方案，例如，我们在MySQL / PosgreSQL中存储结构化数据，MongoDB中的文件元数据，（？不知道）中的目录，以及当用户连接时，我们可以使用嵌入式Neo4J数据库缓存整个文件系统图（假设图的大小很大但可以接受） 这似乎是一个好主意吗？