189 8069 5689
1. 键值数据库
十多年的微山网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都营销网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整微山建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联公司从事“微山网站设计”,“微山网站推广”以来，每个客户项目都认真落实执行。
相关产品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
应用：内容缓存
优点：扩展性好、灵活性好、大量写操作时性能高
缺点：无法存储结构化信息、条件查询效率较低
使用者：百度云（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Ridis和Memcached）
2. 列族数据库
相关产品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
应用：分布式数据存储与管理
优点：查找速度快、可扩展性强、容易进行分布式扩展、复杂性低
使用者：Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Facebook（HBase）
3. 文档数据库
相关产品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit
应用：存储、索引并管理面向文档的数据或者类似的半结构化数据
优点：性能好、灵活性高、复杂性低、数据结构灵活
缺点：缺乏统一的查询语言
使用者：百度云数据库（MongoDB）、SAP（MongoDB）
4. 图形数据库
图形数据库-使用图作为数据模型来存储数据。
相关产品：Neo4J、OrientDB、InfoGrid、GraphDB
应用：大量复杂、互连接、低结构化的图结构场合，如社交网络、推荐系统等
优点：灵活性高、支持复杂的图形算法、可用于构建复杂的关系图谱
缺点：复杂性高、只能支持一定的数据规模
使用者：Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）
传统观念中 NoSQL数据库非常适合某些数据类型，如：非关系数据源。同时，NoSQL被吹捧为最适合Web应用程序的优秀平台。然而他适合大多数数据，特别是web应用程序的数据是相关型。那么，这是否可以给你一个坚持使用RDMS的理由呢？也不一定，即使很困难，我们还是要做出选择。
评估NoSQL是一个很茅盾的理论，一些人认为，应该将所有文档数据存储在一个文档中，做链接代码就是亵渎神明。另外一部分人认为，存储应用文档，
加入代码，才是合理选择。与此同时，不同的数据库，需要在文档中限制嵌套数据数量。有的人会鼓励文档引用。这是NoSQL数据模型的基本部分，也没有一个
明确的共识。
曾经有一篇很热的帖子"Why you should never use
XYZ"，我想，读到这里，一定会有人搜索这篇文章。当然，这种文章各式各样，太过于笼统的标题也没什么帮助。毫无疑问，会有人会搜索这个文章，然后再找
到这个文章，进一步深入，找到该文章的方法远比成功（理解问题）的故事多。很难知道谁提供了一个有效的技术问题，谁又误读了这个问题（或者缺少证据证明其
观点）。
有大量选择，RDBMS的世界，选择就很容易。你有4或5个目标，大家工作方式差不多，来选择环境、预算支持的平台。对于成熟的产品，风险比较小。 NoSQL的世界，有很多数据库引擎功能选择。每一个有自己的独特优势，也有致命弱点。所以选择很难， NoSQL项目生命周期短，尝试新项目或者流行项目也会有风险。上次，我的的项目是在 CouchDB上，而现在似乎停摆了。
做出这个痛苦决定的原因是，这可能是一个案例：你需要做一大堆工作，才能知道，你做出的选择对与错。你可以实体化你的数据模型，了解他与系统的工作
情况，但是，这只有你正真撞到南墙，才可以找到裂缝（答案）。以我为例，我建的应用程序是关系数据库，移动文件存储的主要因素是，需要一个无模式设计来达
到我的目标。使用NoSQL 数据库存储关系型数据库并不是我们所常说的，虽然，这种事常常发生。
现在我在用 Couchbase 和
MongoDB，Mongo对我没多大吸引力，不过鉴于他非常流行，对于引起来说，很有好处。当然，很多都可以以同样的方式流行。PHP很流行，因为他的
易用性，而不是因为他很好。我现在在使用MongoDB和PHP，也在学习Couchbase，如果你有任何NoSQL平台的使用感想，欢迎交流。
非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合，可以是文档或者键值对等。当初我在黑马程序员培训时候就学过。
优点：
1、格式灵活：存储数据的格式可以是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，使用灵活，应用场景广泛，而关系型数据库则只支持基础类型。
2、速度快：nosql可以使用硬盘或者随机存储器作为载体，而关系型数据库只能使用硬盘；
3、高扩展性；
4、成本低：nosql数据库部署简单，基本都是开源软件。
缺点：
1、不提供sql支持，学习和使用成本较高；
2、无事务处理；
3、数据结构相对复杂，复杂查询方面稍欠。
非关系型数据库的分类和比较：
1、文档型
2、key-value型
3、列式数据库
4、图形数据库
NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。