我已经听说了一些关于 NoSQL 的事情,它可能最终会取代 SQL DB 存储方法,因为 DB 交互通常是网络速度的瓶颈。
我有几个问题:
到底是什么?
它是怎么工作的?
为什么它会比使用 SQL 数据库更好? 它有多好?
这项技术是否太新而无法开始实施,还是值得研究一下?
它就像按摩浴缸: 既是一个品牌,又是一个通用名称。它不仅仅是一种特定的技术,而是一种特定的 类型技术,在这里指的是大规模(通常是稀疏的)“数据库”,如 Google 的 BigTable 或 CouchDB。
如果我没记错的话,它指的是不一定遵循关系形式的数据库类型。想到文档数据库,数据库没有特定的结构,也不使用 SQL 作为特定的查询语言。
它通常更适合依赖于数据库性能的 Web 应用程序,而不需要关系数据库引擎的更高级特性。例如,按 id 接口提供简单查询的 Key-> Value 存储可能比相应的 SQL 服务器实现快10-100倍,开发人员维护成本更低。
一个例子是 OLTP Tuple Store 的 纸张,它为单线程处理牺牲了事务(没有并发问题,因为不允许并发) ,并将所有数据保存在内存中; 与类似的 关系数据库驱动系统相比,获得了10-100倍的性能。基本上,它正在从 SQL 和数据库系统的“一刀切”视图中脱离出来。
NoSQL 实际的程序似乎是在 awk 中使用后端的平面文件实现的一个关系数据库。尽管他们声称,“ NoSQL 本质上没有任意的限制,可以在其他产品不能工作的地方工作。例如,没有数据字段大小、列数量或文件大小的限制”,我不认为它是未来的大规模数据库。
正如 Joel 所说,像 大餐桌或 总部这样的大规模可伸缩数据库要有趣得多。GQL 是与 BigTable 和 AppEngine 关联的查询语言。它在很大程度上调整了 SQL,以避免 Google 认为的瓶颈(比如连接)。然而,我以前从来没有听说过“ NoSQL”这个词。
一方面,一个 特定的系统,但是它也已经成为一个通用词,表示不遵循关系数据库模型的 各种新的数据存储后端。
标有通用名称的每个系统的工作原理都不同,但基本思想是通过使用不支持通用 RDBMS 所有功能的 DB 模型来提供更好的可伸缩性和性能,但仍然有足够的功能可用。在某种程度上,它类似于 MySQL,它一度缺乏对事务的支持,但是,确切地说,它的 因为比其他 DB 系统性能更好。如果你能以一种不需要事务的方式编写你的应用程序,那就太棒了。
当您的站点需要如此大规模地扩展,以至于运行在您能够负担得起的最好硬件上的最佳 RDBMS 和尽可能多地进行优化的 RDBMS 根本无法跟上负载时,这种情况会更好。它的好坏取决于具体的用例(大量更新活动和大量连接对于“传统”RDBMS 来说非常困难)——在极端情况下可能是1000倍。
主要取决于你想达到的目标。它已经足够成熟可以使用了。但是很少有应用程序真正需要如此大规模的扩展。对于大多数情况,传统的 RDBMS 就足够了。然而,随着互联网使用变得越来越普遍,这样做的应用程序很可能会变得更加普遍(尽管可能不占主导地位)。
既然有人说我之前的文章跑题了,我会试着补偿一下: —— NoSQL 不是,也从来没有打算取代更主流的 SQL 数据库,但是有几个词是为了从正确的角度看问题。
NoSQL 哲学的核心在于这样一种考虑: 可能出于商业和可移植性的原因,SQL 引擎倾向于忽略 UNIX 操作系统及其衍生产品的巨大功能。
使用基于文件系统的数据库,您可以立即利用底层操作系统不断增长的功能和能力,这些功能和能力多年来一直按照摩尔定律稳步增长。使用这种方法,许多操作系统命令自动成为“数据库操作符”(想想“ ls”“ sort”、“ find”和其他无数的 UNIX shell 实用程序)。
考虑到这一点,再加上一点创造性,您确实可以设计一个基于文件系统的数据库,该数据库能够克服许多常见 SQL 引擎的局限性,至少对于特定的使用模式来说是如此,这就是 NoSQL 哲学背后的全部意义,在我看来也是如此。
我运行了数百个网站,他们都或多或少地使用 NoSQL。事实上,它们并不承载大量的数据,但即使其中一些承载了大量数据,我也可以想到创造性地使用 NoSQL 和文件系统来克服任何瓶颈。使用传统的 SQL“ jails”可能会更加困难。我强烈建议你搜索“ unix”,“ manis”和“ shaffer”来理解我的意思。
实际上,NoSQL 是一个数据库系统,它支持使用基于键的访问策略快速访问大型二进制对象(docs、 jpgs 等)。这与传统的 SQL 访问不同,传统的 SQL 访问只适用于字母数字值。不仅内部存储和访问策略受到限制,而且显示格式的语法和局限性也限制了传统 SQL 的应用。传统关系数据库的 BLOB 实现也受到这些限制。
在幕后,SQL 模型未能支持任何形式的 OLTP 或支持新的数据格式,这是间接的承认。“支持”不仅意味着存储,而且意味着完整的访问能力——使用标准模型进行编程和查询。
关系发烧友很快修改了 NoSQL 的定义,从 Not-SQL 改为 Not-Only-SQL,以保持 SQL 仍然在图片中!尤其是当我们看到今天大多数 Java 程序都依赖于底层关系模型的 ORM 映射时,这种情况就更不好了。一个新的概念必须有一个明确的定义。否则它会像 SOA 一样结束。
NoSQL 系统的基础在于随机键值对。但这并不新鲜。像 IMS 和 IDMS 这样的传统数据库系统确实支持散列随机密钥(不使用任何索引) ,现在仍然支持。实际上 IDMS 已经有了一个关键字 NONSQL,在这个关键字中,IDMS 支持 SQL 访问它们称为 NONSQL 的旧网络数据库。
NoSQL 是一个不使用基于字符串的 SQL 查询来获取数据的数据库系统。
相反,您可以使用它们将提供的 API 来构建查询,例如 AmazonDynamoDB 就是 NoSQL 数据库的一个很好的例子。
NoSQL 数据库更适合可伸缩性很重要的大型应用程序。
NoSQL 是指非关系数据库吗?
是的,NoSQL 不同于 RDBMS 和 OLAP,它使用比传统关系数据库更松散的一致性模型。
一致性模型用于分布式系统,如分布式共享存储处理机系统或分散式档案系统。
它在内部是如何运作的?
NoSQL 数据库系统通常对检索和追加操作进行了高度优化,除了记录存储(例如键值存储)之外,通常提供的功能很少。与完整的 SQL 系统相比,减少的运行时灵活性得到了某些数据模型的可伸缩性和性能的显著提高的补偿。
它可以处理结构化和非结构化数据化,它使用集合而不是表格
如何查询这样的“数据库”?
看看 SQL VS NoSQL: 后端之战,它解释了一切。
NoSQL 是个时髦词。
几十年来,当人们谈论数据库时,他们指的是关系数据库。当人们谈论关系数据库的时候,他们指的是那些你可以用 Edgar f. Codd 的 SQL 控制的数据库。以其他方式存储数据?太疯狂了!其他的都是平面文件。
但在过去的几年里,人们开始质疑这一教条。人们想知道具有行和列的表是否真的是表示数据的唯一方法。人们开始思考和编码,并提出了许多新的概念,如何组织数据。他们开始创建新的数据库系统,为这些新的数据处理方式而设计。
所有这些数据库的理念都是不同的。但所有这些数据库都有一个共同点,那就是 SQL 不再适合使用它们。因此,每个数据库都用自己的查询语言替换 SQL。因此,NoSQL 这个术语诞生了,作为所有数据库技术的标签,这些技术挑战了传统的关系数据库模型。
实际上,不多。
你经常听到这样的短语:
是真的吗?对于一些通常称为 NoSQL 的数据库,这些语句中的一些可能是真的,但是对于至少一个其他数据库,每个语句都是假的。实际上,NoSQL 数据库的唯一共同点是它们是不使用 SQL 的数据库。就是这样。唯一能定义他们的就是让他们彼此分离的东西。
因此,我们明确表示,所有这些通常被称为 NoSQL 的数据库差异太大,无法一起对它们进行评估。它们中的每一个都需要分别进行评估,以确定它们是否适合解决特定问题。但我们从哪里开始呢?值得庆幸的是,NoSQL 数据库可以分为某些类别,这些类别适用于不同的用例:
面向文档
示例: MongoDB、 CouchDB
优势: 异构数据、工作面向对象、敏捷开发
它们的优点是不需要一致的数据结构。当您的需求和数据库布局不断变化时,或者当您处理属于一起但看起来仍然非常不同的数据集时,它们是非常有用的。如果您有很多表,其中有两列分别称为“ key”和“ value”,那么这些表可能值得研究。
图形数据库
例如: Neo4j,GiraffeDB。
优势: 数据挖掘
虽然大多数 NoSQL 数据库放弃了管理数据关系的概念,但是这些数据库甚至比所谓的关系数据库更接受它。
他们的重点是通过数据与其他数据的关系来定义数据。当您有许多带有主键的表时,这些主键是另外两个表的主键(也许还有一些描述它们之间关系的数据) ,那么这些表可能适合您。
键值存储
示例: Redis,Cassandra,MemcacheDB
优势: 通过已知键快速查找值
它们非常简单,但这使得它们快速且易于使用。如果不需要存储过程、约束、触发器和所有这些高级数据库特性,只需要快速存储和检索数据,那么这些都是为您准备的。
不幸的是,他们认为你知道你正在寻找什么。您需要用户157641的配置文件吗?没问题,只要几微秒。但是如果你想知道所有年龄在16岁到24岁之间的用户的名字,他们最喜欢的食物是“华夫饼”,并且在过去的24小时内登录了该网站,那该怎么办呢?真不走运。当你没有一个明确的和唯一的关键为一个特定的结果,你不能得到它出你的 K-V 商店那么容易。
一些 NoSQL 的支持者声称他们最喜欢的 NoSQL 数据库是一种新的做事方式,而 SQL 已经是过去式了。
他们说的对吗?
不,他们当然不是。尽管存在 SQL 不适合的问题,但它仍然有自己的优势。许多数据模型最好表示为相互引用的表的集合。尤其是因为大多数数据库程序员经过数十年的培训,以关系的方式思考数据,并试图将这种思维方式强加到一种新技术上,而这种新技术并不适合它,结果往往不太好。
NoSQL 数据库不是 SQL 的替代品——它们是另一种选择。
大多数围绕不同 NoSQL 数据库的软件生态系统还不够成熟。虽然有了一些进步,但是你仍然没有得到像流行的 SQL 数据库那样成熟和强大的补充工具。
此外,还有更多关于 SQL 的专门知识。一代又一代的计算机科学家花费数十年的职业生涯专注于关系数据库的研究,它表明: 关于 SQL 数据库和关系数据建模的文献,包括实践和理论,可以填满多个图书馆的书籍。如何为你的数据建立一个关系数据库是一个研究得如此充分的话题,以至于很难找到一个没有被普遍接受的书本上的最佳实践的角落案例。
另一方面,大多数 NoSQL 数据库仍处于起步阶段。我们还在研究使用它们的最佳方法。