MongoDB架构建议

我想挑选MongoDB作为我的首选数据库。我需要帮助我的桌子的设计。MongoDB架构建议

应用程序背景 - 分析应用程序，其中联系人推送他们自己的事件和相关的自定义数据。联系人可以有很多事件。如：接触这样做，这样做等

EVENT_TYPE，custom_data（JSON），epoch_time

如：事件1：EVENT_TYPE：page_visited，自定义数据：{网址：定价，引荐：谷歌}， CURRENT_TIME 事件2：EVENT_TYPE：video_watched，定制数据：{URL：VIDEO_LINK}，CURRENT_TIME 事件3：EVENT_TYPE：支付，custom_data：{计划：精简版，价格：35}

这些事件是自定义，并且被定义由用户。可伸缩性是一个问题。

这些都是常见的用例：

给我，谁是来定价页在过去7天的用户列表
给我谁看了视频和付出更多的用户列表50
给我谁访问过定价用户观看视频的名单，但没有支付至少20

什么是设计我的表的最佳方法是什么？在这种情况下使用嵌入式事件是个好主意吗？

来源

2014-06-20 cloudpre

在蒙戈，他们被称为集合和不表，因为数据是不是行/列:)

（1）我会做一个事件收集和用户收藏

（2）我每个事件都有一个userId文件。（3）如果你需要实时数据，你需要一个你想要查询的索引（即不要对整个集合进行扫描）。（4）如果有些事情只需要报告，我建议制作报告节点（即不同的mongo实例），并使用复制将数据复制到该mongo实例。您可以将其他索引放在该节点上进行报告。这样，额外的索引和任何昂贵的查询都不会影响生产性能。

上分片注

如果您的活动集合将会变大 - 你可能需要考虑拆分。也许用户ID分片。不过，我建议这可能是一个更长期的解决方案，而不是在需要之前深入研究。

有一点需要注意的是，mongo目前（2.6）有一个数据库级的写锁实现。这意味着您一次只能执行1次写入。它允许许多读取。这意味着如果你想要一个高写入系统并且拥有大量用户，你需要在某个时刻考虑分片。但是，根据我迄今为止的经验，具有辅助（和报告节点）的管理1主节点更容易设置。使用该设置，我们目前每秒可以处理大约10,000次操作。

但是，我们遇到了来自系统的用户高峰的问题。你会想确保你的索引有足够的内存。 SSD将被推荐。因为用户激增可能导致缓存未命中（即索引不在内存中），导致它从硬盘上读取。

最后一点 - 有很多NoSQL DB，他们都有自己的优点和缺点。我个人发现，高写入，低读取和实时分析大量数据并不是mongo的强项。所以这取决于你在做什么。这听起来像你还在学习基本面。可能值得阅读所有可用的类型来为正确的工作选择合适的工具。

来源

2014-06-20 11:13:51

感谢您的留言。对于高写入，低读取和实时分析，您会有什么建议？ – cloudpre

如果您使用的是AWS，那么DynamoDB速度很快，可能会满足您的事件需求（主键userId，日期范围或事件类型）。卡桑德拉有一些积极的评论（在网络上和我一起工作的人）。我正在研究一些其他的NoSQL数据库 - 我可以消除的大部分数据，尽管我对调查可能会/可能不会有好处的一些数据仍然是Riak或Couchbase。（但我目前倾向于DynamoDB或Cassandra） –

DynamoDB不支持嵌套的JSON搜索。自定义数据对于每个客户都是完全不同的，他们编写他们的自定义数据。 – cloudpre

MongoDB架构建议

回答

相关问题