我有一个场景，我需要存储非结构化数据，但我的其余数据是结构化和关系型的。非结构化数据类型的示例如下所述：
User Type 1:
How do you blah blah : 5 fields
User Type 2 :
How do you blah blah : 3 fields
User Type 3 :
How do you blah blah : 7 fields
所有3种类型都被问到相同的问题“你怎么骂”但每个用户类型使用不同数量的字段来回答它。并且可以有<很多不同的用户类型。
对于关系数据，我正在使用MySQL，但我对如何存储这些非结构化数据感到困惑：
我的要求是高读取，平均更新，平均插入和＆amp;没有删除。不需要JOINS。我需要保证写入＆amp;高可用性。如果我选择NoSQL，根据CAP定理它将是一个AP类型。我不会很快就会达到数百万条记录。
我还计划在将来为这些数据提供文本搜索，但它不需要是实时搜索，因此我总是可以使用 Lucene索引数据定期。但是，当然，基于文档的NoSQL 实现确实提供了开箱即用的功能。但是我已经在一些地方读过人们建议不要在MySQL中存储JSON数据。但是添加NoSQL层可能会有点过分。
我该怎么办＆amp;如果你建议我去NoSQL DB，我应该选择哪一个？
修改 为了澄清，我不需要查询我正在存储的数据中的特定字段。如果我需要数据，那么我将需要整个数据，而不是特定字段。我确实需要全文搜索，我也可以使用Lucene在MySQL上完成。
答案 0 :(得分：2)
你可以通过拥有行ID和单个文本列使它与MySQL一起工作，但是你将无法查询字段。你也可以考虑表继承，但如果你有很多类型，这将是一个烂摊子。最重要的是，您有充分的理由考虑替代解决方案而不是弯曲关系数据库。
因此，根据您的说法，我认为多语言持久性确实是一个很好的用例。话虽如此，MySQL + NoSQL会增加应用程序的整体复杂性，因此您需要确保抽象出两个数据访问层。
对于数据库选择，面向文档的解决方案在查看数据（动态，隔离聚合）时看起来非常合适。我会查看MongoDB或CouchDB，即使第二个选项看起来更合适（AP, Master/master, Lucene integration...）。
编辑：见评论。
答案 1 :(得分：2)
我最近在一个大量使用SQL Server，MySQL和Mongo的平台上工作。我们存储的数据分布在这三个数据库系统中。
这让我渴望只有一种数据库技术。
我会根据经验建议只创建一个文本字段并将JSON存储在那里。您无法直接查询该字段，但可以在文本字段旁边创建可查询的静态字段。
将另一个系统引入混合中绝对不是一件容易的事。
有些原因：
我只会介绍一个单独的NoSQL解决方案作为最后的手段。