何时选择 NoSQL 而不是 SQL？

这篇博客的目的很简单。我们将讨论在为我们的应用服务选择理想的数据库时需要考虑的各种参数。

从数据工程的角度来看，数据压力指的是系统以合理的成本或时间处理大量数据的能力。当其中一个维度被突破时，就会触发技术革新，新的发明就会随之而来，最终催生新的数据技术。简而言之……

SQL 并没有过时，只是我们现在有了不同的选择。

在我们开始比较SQL和NoSQL数据库之前，让我们花点时间来了解一个事实：SQL 已经进入该行业很长时间了（超过 30 年），并且在现代应用程序开发环境中仍然占有一席之地。

比较时间…… 🤞

1. SQL：针对存储进行了优化
   NoSQL：针对计算/查询进行了优化

2. SQL：规范化/关系型
   NoSQL：非规范化/分层

3. SQL：基于表的数据结构
   NoSQL：取决于数据库，数据结构是...
   ★ 键值（DynamoDB、Redis、Voldemort）
   ★ 宽列即行容器（Cassandra、HBase）
   ★ 文档集合（MongoDB、CouchDB、DynamoDB）
   ★ 图形结构（Neo4J、InfiniteGraph）

4. SQL：临时查询
   NoSQL：实例化视图

5. SQL：垂直扩展且成本高昂。可以水平扩展，但挑战性高且耗时。NoSQL
   ：水平扩展且成本低廉

6. SQL：固定模式，修改需要修改整个数据库
   NoSQL：模式是动态的

7. SQL：适合 OLAP
   NoSQL：适合大规模 OLTP

8. SQL： ACID（原子性、一致性、隔离性、持久性）属性
   NoSQL： BASE（基本可用、软状态、最终一致性）属性

何时选择 NoSQL？ 👍

对于我们的应用服务，当涉及到...

✔ 众所周知且易于理解的访问模式类型
✔ 需要简单的查询
✔ 不涉及太多数据计算
✔ 具有通用的业务流程
✔ OLTP 应用程序

如果这是真的，那么 NoSQL 就是一个完美的数据库，并且效率最高。我们必须专门构建数据模型来支持特定的访问模式。

什么时候不该选择 NoSQL？ 👎

如果我们的应用服务有支持要求...

✔ 临时查询。例如，BI 分析用例或 OLAP 应用程序
✔ 可能需要“重塑”数据
✔ 复杂查询、内连接、外连接等
✔ 复杂值计算

简而言之，对于我们的应用服务，如果我们非常了解访问模式，它们是可重复的、一致的，并且可扩展性是一个重要因素，那么 NoSQL 是一个完美的选择。

附言：成熟的开发人员不会用“灵活”这个词来形容NoSQL数据库。动态和灵活是有区别的。在NoSQL数据库中，数据模型设计是一项智能工程。

你对我上面的讨论有什么看法？为什么你选择 NoSQL 而不是 SQL？

...

感谢您阅读本博客！

如果您喜欢这个比较，请点个❤。如果您有任何问题/反馈，请在下方留言。我计划在这里写一个关于 DynamoDB 的系列文章，请关注我获取最新资讯。

更多关于作者：Om Bharatiya

编码愉快 <3