像 Cassandra 这样的非 sql 数据库有哪些有趣的陷阱......？ [关闭]

Question

在这个领域发生了很多事情，虽然技术差异很明显，但我想更多地了解开发人员是如何绕过坏处并利用不同方法的。

一个简短的总结，以避免陈述显而易见的无聊回应。 - 它们是无模式的 - 比 SQL 更快

我特别感兴趣：

• 卡桑德拉

Answer 1

有趣的陷阱：

• 它们都非常不同。 Cassandra、MongoDB 和 CouchDB 看起来基本上是一回事，但它们不是。预计必须深入了解您的实施细节。
• 您将需要学习如何进行 map-reduce。 （使用您选择的数据库）
• 您将不得不重组您的数据。您通常会遇到的第一件事是，真正的“子”数据现在将与父数据一起存储。这将产生大量的程序化意义，但您必须与旧有的“正常化”冲动作斗争。
• 当您意识到您的“核心”数据并非您认为的数据时，您将不得不对数据进行更多重构。
• 您可能会比以前编写更多的for 循环。不好也不坏，这实际上是一个副作用，因为您意识到您对 sum(field) 所做的某些事情与您现在拥有当前流程中的所有数据的 b/c 不太一样。

您会在 MongoDB 中找到以下具体内容： - 您将花费更少的时间进行管理。数据库和“表”创建现在是免费和自动的。一开始这有点迷。 - 您可能需要扩展一堆服务器监控软件。 Nagios 或 Scout 之类的东西（目前）还没有内置这种跟踪功能。 - 你用更仔细的眼光看索引。 SQL 中的索引很容易粗心大意。 MongoDB 中无用的索引会迅速降低性能。

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

多年来，我们一直被困在一个关系世界中。我们习惯于用关系术语来思考数据。我们大多数人在设计表格时都会自然地对数据进行规范化。我们希望尽早针对“所有可能的查询”进行优化。

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