【问题标题】:Shifting from SQL to NoSQL and to which DB?从 SQL 转移到 NoSQL 以及转移到哪个数据库?
【发布时间】:2011-12-08 14:50:06
【问题描述】:

我们最近在当前的 SQL Server 数据库中遇到了与性能相关的重大问题。 我们的应用程序在单个表上非常繁重,我们进行了一些分析,大约 90% 的数据库数据在单个表中。我们也在这张表上运行了大量查询,出于分析目的,我们现在遇到了主要的性能问题,即使添加单列有时也会减慢我们当前的 Sp。我们的大多数团队都是开发人员,我们没有 dba 访问权限,这可能有助于重新调整我们当前的数据库并加快工作速度。

由于这些限制,我们正在考虑将应用程序的这一部分移至 NoSQL 数据库。 我的问题是:

  1. 如果这是我们前进的正确方向?正如我们预计这张桌子上的指数增长一样。有大量的分析在上面运行。
  2. 对于我们来说,CouchDB、Cassandra、MongoDB 哪个是最佳选择?强调可扩展性和性能
  3. 对于类似于 SQL 的实时分析和支持,NoSQL 中的工作原理是否有一种工具可以让我们查看当前存储的数据?我在某处读到过有关 Hadoop 的 HIVE 可用于从 NoSQL 数据库中以 SQL 形式写入和检索数据的信息,对吗?
  4. 在从 SQL 转向 NoSQL 时,我们可能会失去哪些东西?

【问题讨论】:

  • 表格有多少行?您是否在尝试读取数据时插入了很多行?调整数据库或使用报告数据库等可能比将所有内容更改为 NoSQL 更容易。此外,您需要查询的数据有多新鲜以及每条记录的重要性如何?例如,CouchDB 使用“最终一致性”...
  • 目前只有 60000 行,但这会迅速增加。每个数据对我们来说都很重要,它本身就是我们应用程序的核心,查询也很繁重。但是我们可以忍受延迟的结果,但不能有不一致的地方,即希望数据不会改变。该表只有插入和读取,不允许更新。表中的数据本质上是静态的。
  • 如果您遇到 60k 行的性能问题,那么您的 SQL 设计肯定有问题。
  • Err 所以问题是我们应该如何在最终撞墙之前纠正它?
  • 表格有多少列?您正在运行哪种查询?

标签: nosql


【解决方案1】:

对于您的问题:

1.. 如果这是我们前进的正确方向?正如我们预计这张桌子上的指数增长一样。上面运行着大量的分析。

是的,大多数 noSQL 系统都是专门为解决可扩展性和可用性而开发的,如果您以预期的方式使用它们

2.. 哪个是我们 CouchDB、Cassandra、MongoDB 的最佳选择?强调可扩展性和性能

这完全取决于您的数据是什么样的以及您将如何使用它。您提到的 noSQL db 已实现并且行为彼此非常不同,请参阅此链接以获得比较您提到的几个的更详细的概述。 Comparisons of noSQL solution

3.. 对于类似于 SQL 的实时分析和支持,NoSQL 中的工作原理是否有一种工具可以让我们查看当前存储的数据?我在某处读到过有关 Hadoop 的 HIVE 可用于从 NoSQL db 中以 SQL 形式写入和检索数据的信息,对吗?

这取决于您使用的系统,因为某些 noSQL db 不支持范围查询或连接,因此您可以查看的内容和查看的速度受到限制。

4.. 在从 SQL 转移到 NoSQL 时,我们可能会失去哪些东西?

noSQL 有两个主要考虑因素:

查询/结构: NoSQL 表示没有 SQL。如果您的系统实际上需要结构化和复杂的查询,但您选择了其中一种很酷的新解决方案(尤其是键值存储,它基本上是一个巨大的哈希表),您可能很快就会发现自己正处于重新实现业余爱好者的过程中,设计不当的 RDBMS,包含您原来的所有问题。

一致性:如果您选择最终一致的系统进行水平扩展,那么您将不得不接受您的数据已经过时,这可能对某些应用程序(论坛?)无害,或者在其他一些应用程序中则很糟糕系统(银行)。

【讨论】:

  • 很好的答案,我唯一的反对意见是 noSQL 意味着 Not Only SQL 而不是 No SQL
【解决方案2】:

我认为您应该保持关系并调整表、它的索引以及它连接到的表。您还应该考虑使用聚合(汇总数据)。也许更非规范化的设计会帮助甚至将数据重新设计成更多的星形结构。此外,操作处理和决策支持(或报告)分析不应在同一张表上运行。

【讨论】:

    【解决方案3】:

    可以通过检查缺失的索引等以及查看您使用的隔离级别是否最佳来改进 SQL 方法。可以使用快照隔离等来提高性能。 MSDN link

    同时阅读 OLTP 与 OLAP。

    NoSQL 可能仍然是一个更好的选择,但您仍然需要学习如何正确使用数据库,它会带来另一组不同的问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-12-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-15
      • 2013-01-13
      • 1970-01-01
      相关资源
      最近更新 更多