我正在尝试选择MongoDB作为我的首选数据库。我需要帮助设计我的桌子。
应用程序背景 - 联系人推送自己的事件和相关自定义数据的分析应用程序。联系可以有很多活动。例如：联系人这样做了，做了那个等等。
event_type，custom_data（json），epoch_time
例如： 事件1：event_type：page_visited，custom-data：{url：pricing，referrer：google}，current_time 事件2：event_type：video_watched，custom-data：{url：video_link}，current_time 事件3：event_type：付费，custom_data：{plan：lite，price：35}
这些事件是自定义的，由用户定义。可伸缩性是一个问题。
这些是常见用例：
设计餐桌的最佳方式是什么？ 在这种情况下使用嵌入式事件是个好主意吗？
答案 0 :(得分：0)
在Mongo中，它们被称为集合而不是表，因为数据不是行/列：）
（1）我制作了一个Event集合和一个Users集合
（2）我会为每个事件做一个文档，其中包含userId。
（3）如果您需要实时数据，您需要索引要查询的内容（即从不对整个集合进行扫描）。
（4）如果只有报告需要的东西，我建议建立一个报告节点（即一个不同的mongo实例）并使用复制将数据复制到该mongo实例。您可以在该节点上添加其他索引以进行报告。这样，额外的索引和任何昂贵的查询都不会影响生产性能。
关于分片的说明
如果您的事件集合变得很大 - 您可能需要考虑分片。也许按用户ID进行分片。但是，我建议这可能是一个长期的解决方案，在你需要之前不要深入研究。
有一点需要注意的是，mongo目前有（2.6）数据库级写锁定实现。这意味着您一次只能执行1次写操作。它允许许多读取。这意味着如果你想要一个高写系统并拥有大量用户，你需要在某个时候研究分片。但是，根据我迄今为止的经验，管理上1个具有辅助节点（和报告节点）的主节点更容易设置。我们目前每秒可以处理大约10,000次操作。
但是，我们遇到了用户进入系统时出现峰值的问题。您需要确保为索引提供足够的内存。并且建议使用SSD。因为用户激增可能导致缓存未命中（即索引不在内存中）导致它被从硬盘上读取。
最后一点 - 有很多NoSQL DB，它们各有利弊。我个人发现大量数据的高写入，低读取和实时分析并不是真正的mongo强度。所以它取决于你在做什么。听起来你还在学习基础知识。可能值得阅读所有可用类型，以便为正确的工作选择合适的工具。