啊，是的。我曾经在一家初创公司工作，他们坚持使用Mongo，尽管我们根本不需要那么多的数据量，根本没必要使用Mongo。比如，我们所需要的数据量比合理预期的少五个数量级。我当时还只是一个菜鸟工程师，而主管们却不愿意接受像MySQL/Postgres这样普通的数据库。总之，后来我们被要求构建一个内部的消息服务。这时，Mongo的最终一致性变成了一个严重的问题。用户会收到新消息的通知，但当他们试图查看消息时，却发现消息还没一致。我们最终实施了各种丑陋的用户体验技巧来解决这个问题，但实际上，我们完全可以把整个系统运行在一台机器上的sqlite上，用户就能立即读取消息了，所以……
源讨论为什么一切都这么可扩展？原帖 370 条评论 · 导入时统计我认为这项工作是确定性的，但它经常（无意中）让所开发的系统变得非确定性！
完整原文把你的经验，加入这段讨论。
我之前也见过类似的情况，使用的是Firebase。幸运的是，我在这家公司担任技术负责人，因此能够带领团队迁移到Postgres。有趣的是，除了更可靠之外，Postgres版本（在一个小型数据库实例上）也比之前的Firebase版本快得多（因为数据库可以执行JOIN操作，而不是在应用代码中执行）。
完整原文我看到一家你可能听说过的企业浪费了大量资金，因为那里有个人试图打造自己作为图数据库专家的个人品牌，另一个人则对Neo4j的营销宣传深信不疑。稳定性问题、愚蠢的错误、功能集薄弱、对于他们想要做的大部分事情来说性能都很一般（至少在那个时候，Neo4j被优化为可以非常快速地执行某些图相关操作，但很容易找到其他它表现极差的图相关操作，而这些并不是什么冷门的功能），所有这些问题都使项目开发时间延长到原本的两倍，而且没有任何好处。真是蠢透了。 与此同时，他们真正需要的其实是……坦白说，可能只是SQLite，因为他们的特定用例，如果每个客户的资料都基于一个可移动的文件，实际上会是一个巨大的优势。他们每个客户的资料…
完整原文Dawg Tinder当时有2000万DAU，所有的数据库都基于Dynamo。可能现在还是这样。 而且确实有很多这些问题，但大家都是抱着玩一票的心态
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。