与Cassandra等非SQL数据库有什么有趣的陷阱？

Question

在这个领域已经发生了很多事情，虽然技术上的差异显而易见，但我想更多地了解开发人员如何绕过坏点并采取不同方法的优势。

简要总结，以避免无聊的回应，说明显而易见的。     - 它们是无模式的     - 比SQL快

我特别感兴趣：

• 卡桑德拉

Answer 1

有趣的陷阱：

• 他们都非常不同。 Cassandra，MongoDB和CouchDB似乎基本相同，但它们不是。期望必须深入了解您的实施细节。
• 您需要了解如何map-reduce。 （使用您选择的数据库）
• 您必须重新构建数据。您通常会遇到的第一件事是，真正的“子”数据现在将与父项一起存储。这将产生大量的程序感，但你必须克服旧的冲动才能“正常化”。
• 当您意识到“核心”数据不是您认为的数据时，您将不得不重新调整数据结构。
• 您可能会写出比您习惯的更多for个循环。既不好也不坏，这实际上是一种副作用，即你意识到你用sum(field)做的一些事情不能完全相同，你现在拥有当前流程中的所有数据。

您将在MongoDB中找到的具体内容：   - 您将花费更少的时间进行管理。 DB＆amp; “桌子”创作现在是免费的＆amp;自动。起初这是一个小小的冒险。   - 您可能需要扩展一堆服务器监控软件。像Nagios或Scout这样的东西没有内置这种跟踪功能。   - 你用更仔细的眼光看待指数。在SQL中使用索引很容易粗略。 MongoDB中的无用索引会迅速降低性能。

最大的问题：你必须“思考与众不同”。

我们多年来一直困在关系世界。我们习惯于用关系术语来思考数据。我们大多数人在设计表格时自然地将数据标准化。我们希望尽早优化“所有可能的查询”。

NoSQL非常不同。你会早点开始反规范化。您将专注于最常运行的查询。您很快就会意识到，大多数慢查询并不需要实时答案。这些将成为更新数据的map-reduce作业。