我一直在听NoSQL的事情,它最终可能成为SQL DB存储方法的替代品,因为数据库交互通常是网络速度的瓶颈.
所以我只有几个问题:
究竟是什么？
它是如何工作的？
为什么它比使用SQL数据库更好？它有多好？
这项技术是否太新,无法开始实施,还是值得研究一下？
Philipp.. 131
NoSQL是一个流行语.
几十年来,当人们谈论数据库时,他们意味着关系数据库.当人们谈论关系数据库时,他们意味着你用Edgar F. Codd的结构化查询语言控制的那些数据库.以其他方式存储数据？疯狂!其他任何东西都只是flatfiles.
但在过去的几年里,人们开始质疑这个教条.人们想知道具有行和列的表是否真的是表示数据的唯一方式.人们开始思考和编码,并提出了许多关于如何组织数据的新概念.他们开始创建新的数据库系统,专为这些处理数据的新方法而设计.
所有这些数据库的哲学都不同.但是所有这些数据库有一个共同点,就是结构化查询语言不再适合使用它们.因此,每个数据库都用自己的查询语言替换SQL.因此,NoSQL这个术语诞生了,作为所有数据库技术的标签,它违背了传统的关系数据库模型.
实际上,并不多.
你经常听到这样的短语:
NoSQL是可扩展的!
NoSQL适用于BigData!
NoSQL违反了ACID!
NoSQL是一个美化的键/值存储!
真的吗？好吧,其中一些语句可能适用于一些通常称为NoSQL的数据库,但每一个数据库对于至少一个其他数据库也是假的.实际上,NoSQL数据库唯一的共同点就是它们是不使用SQL的数据库.而已.唯一定义它们的是使它们彼此分开的原因.
因此,我们明确指出,所有通常称为NoSQL的数据库都不同,无法将它们一起评估.需要对它们中的每一个进行单独评估,以确定它们是否适合解决特定问题.但是我们从哪里开始呢？值得庆幸的是,NoSQL数据库可以分为特定类别,适用于不同的用例:
文档导向
示例:MongoDB,CouchDB
优势:异构数据,面向工作对象,敏捷开发
它们的优点是它们不需要一致的数据结构.当您的需求和数据库布局不断变化,或者处理属于一起但看起来非常不同的数据集时,它们非常有用.当你有很多表有两列名为"key"和"value"的表时,这些可能值得研究.
图数据库
示例:Neo4j,GiraffeDB.
优势:数据挖掘
虽然大多数NoSQL数据库放弃了管理数据关系的概念,但这些数据库比那些所谓的关系数据库更能接受它.
他们的重点是通过与其他数据的关系来定义数据.如果你有很多带有主键的表,这些表是另外两个表的主键(也许是描述它们之间关系的一些数据),那么这些表可能适合你.
键值商店
示例:Redis,Cassandra,MemcacheDB
优点:通过已知密钥快速查找值
它们非常简单,但这使它们快速且易于使用.如果您不需要存储过程,约束,触发器和所有这些高级数据库功能,并且只是想快速存储和检索数据,那么这些都适合您.
不幸的是,他们认为你确切地知道你在寻找什么.您需要User157641的个人资料吗？没问题,只需几微秒.但是当你想要年龄在16到24岁之间的所有用户的名字时,有什么"华夫饼"作为他们最喜欢的食物并且在过去的24小时内登录了什么？倒霉.当您没有明确且唯一的特定结果密钥时,您无法轻松地将其从KV商店中取出.
一些NoSQL支持者声称他们最喜欢的NoSQL数据库是新的做事方式,SQL已经成为过去.
他们是对的吗？
不,当然不是.虽然SQL不适合存在问题,但它仍然有其优势.许多数据模型最好表示为相互引用的表的集合.特别是因为大多数数据库程序员都经过数十年的训练才能以关系的方式思考数据,并且试图将这种思维方式转变为一种新技术,而这项技术并非为此而设.
NoSQL数据库不是SQL的替代品 - 它们是替代品.
围绕不同NoSQL数据库的大多数软件生态系统还不够成熟.虽然有了进步,但您仍然没有像流行的SQL数据库那样成熟和强大的补充工具.
此外,SQL还有更多的专业知识.几代计算机科学家将他们几十年的职业生涯投入到关注数据库的研究中,它表明:关于SQL数据库和关系数据建模的文献,无论是实践还是理论,都可以填满多个图书馆.如何为您的数据构建关系数据库是一个如此深入研究的主题,很难找到一个没有普遍接受的书本最佳实践的角落案例.
另一方面,大多数NoSQL数据库仍然处于起步阶段.我们仍然在找出使用它们的最佳方法.
NoSQL是一个流行语.
几十年来,当人们谈论数据库时,他们意味着关系数据库.当人们谈论关系数据库时,他们意味着你用Edgar F. Codd的结构化查询语言控制的那些数据库.以其他方式存储数据？疯狂!其他任何东西都只是flatfiles.
但在过去的几年里,人们开始质疑这个教条.人们想知道具有行和列的表是否真的是表示数据的唯一方式.人们开始思考和编码,并提出了许多关于如何组织数据的新概念.他们开始创建新的数据库系统,专为这些处理数据的新方法而设计.
所有这些数据库的哲学都不同.但是所有这些数据库有一个共同点,就是结构化查询语言不再适合使用它们.因此,每个数据库都用自己的查询语言替换SQL.因此,NoSQL这个术语诞生了,作为所有数据库技术的标签,它违背了传统的关系数据库模型.
实际上,并不多.
你经常听到这样的短语:
NoSQL是可扩展的!
NoSQL适用于BigData!
NoSQL违反了ACID!
NoSQL是一个美化的键/值存储!
真的吗？好吧,其中一些语句可能适用于一些通常称为NoSQL的数据库,但每一个数据库对于至少一个其他数据库也是假的.实际上,NoSQL数据库唯一的共同点就是它们是不使用SQL的数据库.而已.唯一定义它们的是使它们彼此分开的原因.
因此,我们明确指出,所有通常称为NoSQL的数据库都不同,无法将它们一起评估.需要对它们中的每一个进行单独评估,以确定它们是否适合解决特定问题.但是我们从哪里开始呢？值得庆幸的是,NoSQL数据库可以分为特定类别,适用于不同的用例:
文档导向
示例:MongoDB,CouchDB
优势:异构数据,面向工作对象,敏捷开发
它们的优点是它们不需要一致的数据结构.当您的需求和数据库布局不断变化,或者处理属于一起但看起来非常不同的数据集时,它们非常有用.当你有很多表有两列名为"key"和"value"的表时,这些可能值得研究.
图数据库
示例:Neo4j,GiraffeDB.
优势:数据挖掘
虽然大多数NoSQL数据库放弃了管理数据关系的概念,但这些数据库比那些所谓的关系数据库更能接受它.
他们的重点是通过与其他数据的关系来定义数据.如果你有很多带有主键的表,这些表是另外两个表的主键(也许是描述它们之间关系的一些数据),那么这些表可能适合你.
键值商店
示例:Redis,Cassandra,MemcacheDB
优点:通过已知密钥快速查找值
它们非常简单,但这使它们快速且易于使用.如果您不需要存储过程,约束,触发器和所有这些高级数据库功能,并且只是想快速存储和检索数据,那么这些都适合您.
不幸的是,他们认为你确切地知道你在寻找什么.您需要User157641的个人资料吗？没问题,只需几微秒.但是当你想要年龄在16到24岁之间的所有用户的名字时,有什么"华夫饼"作为他们最喜欢的食物并且在过去的24小时内登录了什么？倒霉.当您没有明确且唯一的特定结果密钥时,您无法轻松地将其从KV商店中取出.
一些NoSQL支持者声称他们最喜欢的NoSQL数据库是新的做事方式,SQL已经成为过去.
他们是对的吗？
不,当然不是.虽然SQL不适合存在问题,但它仍然有其优势.许多数据模型最好表示为相互引用的表的集合.特别是因为大多数数据库程序员都经过数十年的训练才能以关系的方式思考数据,并且试图将这种思维方式转变为一种新技术,而这项技术并非为此而设.
NoSQL数据库不是SQL的替代品 - 它们是替代品.
围绕不同NoSQL数据库的大多数软件生态系统还不够成熟.虽然有了进步,但您仍然没有像流行的SQL数据库那样成熟和强大的补充工具.
此外,SQL还有更多的专业知识.几代计算机科学家将他们几十年的职业生涯投入到关注数据库的研究中,它表明:关于SQL数据库和关系数据建模的文献,无论是实践还是理论,都可以填满多个图书馆.如何为您的数据构建关系数据库是一个如此深入研究的主题,很难找到一个没有普遍接受的书本最佳实践的角落案例.
另一方面,大多数NoSQL数据库仍然处于起步阶段.我们仍然在找出使用它们的最佳方法.
究竟是什么？
一方面,一个特定的系统,但它也成为不遵循关系数据库模型的各种新数据存储后端的通用词.
它是如何工作的？
标有通用名称的每个系统的工作方式不同,但基本思想是通过使用不支持通用RDBMS的所有功能的DB模型来提供更好的可伸缩性和性能,但仍然有足够的功能.在某种程度上,它就像MySQL,它曾一度缺乏对事务的支持,但正因为如此,它成功地超越了其他数据库系统.如果您可以以不需要交易的方式编写应用程序,那就太棒了.
为什么它比使用SQL数据库更好？它有多好？
如果您的站点需要如此大规模地扩展以使最好的RDBMS运行在您能够承受的最佳硬件上并且尽可能地优化而无法跟上负载,那就更好了.它的好坏取决于具体的用例(大量的更新活动与大量的连接相结合对于"传统的"RDBMS来说非常困难) - 在极端情况下很可能是1000的因素.
这项技术是否太新,无法开始实施,还是值得研究一下？
主要取决于你想要实现的目标.它当然足够成熟,可以使用.但很少有应用程序确实需要大规模扩展.对于大多数人来说,传统的RDBMS就足够了.然而,随着互联网的使用越来越普遍,很可能应用程序会变得更加普遍(尽管可能不是主导).
既然有人说我以前的帖子是偏离主题的,我会尽力补偿:-) NoSQL不是,而且从来没有打算成为更主流的SQL数据库的替代品,但是为了获得正确的观点.
在的非常心脏的NoSQL理念撒谎说,可能是商业性和便携性的原因,SQL引擎往往忽视了UNIX操作系统及其衍生物的巨大力量的考虑.
使用基于文件系统的数据库,您可以立即利用底层操作系统不断增强的功能和强大功能,这些操作系统已根据摩尔定律多年来稳步增长.使用这种方法,许多操作系统命令也自动成为"数据库操作员"(想想"ls""sort","find"和其他无数的UNIX shell实用程序).
考虑到这一点,以及一些创造力,您确实可以设计一个基于文件系统的数据库,它能够克服许多常见SQL引擎的限制,至少对于特定的使用模式,这是NoSQL的理念背后的全部要点,我看到它的方式.
我运行了数百个网站,他们都或多或少地使用NoSQL.实际上,它们并不存储大量数据,但即使其中一些数据存在,我也可能会想到NoSQL和文件系统的创造性使用以克服任何瓶颈.传统的SQL"jails"可能会更加困难.我敦促你谷歌为"unix","manis"和"shaffer"来理解我的意思.
如果我没记错的话,它指的是不一定遵循关系形式的数据库类型.我想到了文档数据库,没有特定结构的数据库,以及不使用SQL作为特定查询语言的数据库.
它通常更适合依赖于数据库性能的Web应用程序,并且不需要关系数据库引擎的更高级功能.例如,通过id接口提供简单查询的Key-> Value存储可能比相应的SQL Server实现快10-100倍,开发人员维护成本较低.
一个例子是本文针对OLTP元组存储,它牺牲了单线程处理的事务(没有并发问题,因为不允许并发),并将所有数据保存在内存中; 与类似的RDBMS驱动系统相比,性能提高了10-100倍.基本上,它正在远离SQL和数据库系统的"One Size Fits All"视图.
实际上,NoSQL是一个数据库系统,它支持使用基于密钥的访问策略快速访问大型二进制对象(docs,jpgs等).这与传统的SQL访问不同,传统的SQL访问仅对字母数字值足够好.不仅内部存储和访问策略,而且显示格式的语法和限制限制了传统的SQL.传统关系数据库的BLOB实现也受到这些限制.
在场景背后,间接承认SQL模型无法支持任何形式的OLTP或支持新的数据格式."支持"不仅意味着存储而且意味着完全访问功能 - 使用标准模型进行编程和查询.
关系爱好者很快就将NoSQL的定义从Not-SQL修改为Not-Only-SQL,以保持SQL仍在图片中!这并不好,特别是当我们看到今天大多数Java程序采用底层关系模型的ORM映射时.新概念必须有明确的定义.否则它最终会像SOA一样.
NoSQL系统的基础在于随机键 - 值对.但这并不新鲜.像IMS和IDMS这样的传统数据库系统确实支持散列的ramdom密钥(不使用任何索引),但它们仍然可以.事实上,IDMS已经有一个关键字NONSQL,它支持对旧网络数据库的SQL访问,它们被称为NONSQL.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
