1

我有一个场景，我需要存储非结构化数据，但我的其余数据是结构化的和相关的。非结构化数据类型的示例如下所述：

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，但我对如何存储这些非结构化数据有点困惑：

  1. 序列化为 JSON 并存储在 MySQL 中
  2. 使用 NoSQL

我的要求是高读取、平均更新、平均插入和无删除。无需加入。我需要保证写入和高可用性。如果我要选择 NoSQL，根据 CAP 定理，它将是 AP 类型。我不会很快达到数百万条记录。

我还计划将来为这些数据提供文本搜索，但它不需要是实时搜索，所以我总是可以定期使用Lucene索引数据。但当然，基于文档的 NoSQL实现确实提供了开箱即用的功能。但我在一些地方读过人们建议不要在 MySQL 中存储 JSON 数据。但是添加 NoSQL 层可能是矫枉过正。

我该怎么办？如果您建议我选择 NoSQL DB，我应该选择哪一个？

编辑： 为了澄清，我不需要从我存储的数据中查询特定字段。如果我需要数据，那么我将需要整个数据，而不是特定字段。我确实需要全文搜索，我也可以使用 Lucene 在 MySQL 上完成。

4

2 回答 2

2

您可以通过使用行 ID 和单个文本列使其与 MySQL 一起使用，但是您将无法查询这些字段。您也可以考虑表继承，但如果您确实有很多类型，这将是一团糟。底线是您有充分的理由考虑替代解决方案而不是弯曲关系数据库。

所以从你所说的来看，我认为这确实是polyglot persistence的一个很好的用例。话虽如此，MySQL + NoSQL 将增加应用程序的整体复杂性，因此您需要确保抽象两个数据访问层。

对于数据库选择，在查看数据（动态、隔离的聚合）时，面向文档的解决方案似乎很合适。我会研究 MongoDB 或 CouchDB，即使第二个选项似乎更合适（AP、Master/master、Lucene 集成......）。

编辑：见评论。

于 2013-06-03T10:39:07.983 回答
2

我最近在一个大量使用 SQL Server、MySQL 和 Mongo 的平台上工作。我们存储的数据分布在这三个数据库系统中。

这让我渴望只有一种数据库技术。

我会根据经验建议只制作一个文本字段并将 JSON 存储在其中。您不能直接查询该字段，但您可以在可查询的文本字段旁边创建静态字段。

在混合中引入另一个系统绝对不是微不足道的。

造成这种情况的一些原因：

  1. 文档建模的学习曲线很高。你不规范化，你非规范化数据 - 这样做有点艺术。
  2. 配置好 CouchDB 和 MongoDB 集群后，我可以告诉您，这并不是一件容易的事——尤其是当您转向生产时。
  3. 跨数据库技术进行查询当然不是一件容易的事。

作为最后的手段，我只会引入一个单独的 NoSQL 解决方案。

于 2013-06-03T16:22:15.277 回答