实际上为了更好的描述实体之间的关系，我们要是再继续使用Redis的话，是不是感觉实体之间的关系不够那么的明显，虽然也是属于NoSQL的一种，但是相对来说，Redis，表现实体之间的关系就没有那么清晰了，为了更好的描述实体之间的关系，就会使用图形数据库来进行了，那么今天阿粉介绍的，就是一个图形化的数据可，Neo4J。
创新互联建站是一家专注于网站设计、做网站与策划设计,乐陵网站建设哪家好?创新互联建站做网站,专注于网站建设十载,网设计领域的专业建站公司;建站业务涵盖:乐陵等地区。乐陵做网站价格咨询:028-86922220
Neo4j是一个世界领先的开源的基于图的数据库。 它是使用Java语言完全开发的。那么什么是图数据库呢？图数据库是以图结构的形式存储数据的数据库。 它以节点，关系和属性的形式存储应用程序的数据。正如RDBMS以表的“行，列”的形式存储数据，GDBMS以图的形式存储数据。
RDBMS与图数据库的区别
1.Tables 表Graphs 图表
2.Rows 行Nodes 节点
3.Columns and Data 列和数据 Properties and its values属性及其值
4.Constraints 约束Relationships 关系
5.Joins 加入Traversal 遍历
说完了图形数据库，我们就来看看这个 Neo4J 数据库吧
neo4j是用Java语言编写的图形数据库，运行时需要启动JVM进程，因此，需安装JAVA SE的JDK。关于 Java 怎么安装，我就不用再多废话了吧，到时候别忘了检测一下 Java 的版本就好了， java -version
接下来我们就是要进行一个安装了，我们先去官网，下载社区版，企业版要收费的，注意哈。
官网地址
下载完成，直接开始安装，傻瓜式操作即可。
Neo4j应用程序有如下主要的目录结构：
注意，如果你使用的是Zip的压缩包来进行的使用的话，那么你就需要注意一些地方，比如你如果是用 Zip 的包解压之后，并且想要通过 bat 的命令启动，直接在目录下进行 cmd ，然后 neo4j.bat ,这时候可能会出现一个问题，就是版本可能会出现问题，你如果下载使用的是最新版的 Neo4J ,那么就可能会让你使用 JDK 11 ，而阿粉就是踩过了这个大坑之后，才发现，bat 闪退的原因。
这样就是说明我们的 JDk 的版本对应的和 Neo4J 需要的 JDK 是不匹配的，我们就需要换一下我们的 JDK 了。把他换成 JDK 11 就好了，再次启动。
这时候，我们就直接访问 localhost：7474 的端口，直接就能看到如下的画面， 1.jpg
刚进入的时候可能需要大家输入帐号密码，默认的帐号密码就是，neo4j 修改成你想要的就行了。
这样登录进去我们就能开始正式学习 Neo4J 的所有内容了。
Neo4j - CQL语法
我们在讲语法之前首先我们先得看看 Neo4J 的构建模块，不然之后的查询都是无意义的。
Neo4j图数据库主要有以下构建块 -
节点是图表的基本单位。 它包含具有键值对的属性，如下所示
属性是用于描述图节点和关系的键值对
关系是图形数据库的另一个主要构建块。 它连接两个节点，如下所示。
Label将一个公共名称与一组节点或关系相关联。 节点或关系可以包含一个或多个标签。 我们可以为现有节点或关系创建新标签。 我们可以从现有节点或关系中删除现有标签。
Neo4j数据浏览器 一旦我们安装Neo4j，我们可以访问Neo4j数据浏览器使用以下URL
http：// localhost：7474 / browser /
CREATE 语法
CREATE ( : )
它是我们要创建的节点名称。
它是一个节点标签名称
我们可以创建一个节点，然后给他安排上一个标签
CREATE (emp:Employee)
当我们看到
Added 1 label, created 1 node, completed after 74 ms.
这就创建成功了，
那么怎么查看呢？
MATCH语法
MATCH ( : ) return xxx
是这个样子的
但是看到里面竟然没有东西，就相当于是一个空的对象，那是不是就应该给里面放入属性的操作呢？没错，肯定有
CREATE (emp:Employee{ id : 1001 ,name :"lucy", age : 10})
Added 1 label, created 1 node, set 3 properties, completed after 163 ms. 创建成功。
我们再次查看就能看到
如果我们想只要其中的一些对象的属性，而不是全部属性，那应该怎么操作呢？
RETURN语法
RETURN 可以返回的是一个对象，也可以是对象中的属性，比如：
结果就是下面这个样子的，大家看一下，是不是感觉还是挺好用的。
** WHERE语法**
WHERE
为什么在前面的位置阿粉说，CQL 是和 SQL 类型的，这完全是因为很多东西和 SQL 是类似的。
结果如下：
相同的还有
布尔运算符 描述 AND 和 OR 或者 NOT 非 XOR 异或
比较运算符 描述 = “等于”运算符 “不等于”运算符 “小于”运算符 “大于”运算符 = “小于或等于”运算符。 = “大于或等于”运算符。
DELETE语法
删除语法必然是有的，因为有创建，肯定有删除。
DELETE
但是这个命令也不是单独使用的哈，
MATCH (e: Employee) DELETE e
直接删除成功。
基础的东西讲完了，阿粉就得说说这个比较重要的内容了，关系，
我们之前创建节点的时候，那叫一个简单舒适加愉快，但是创建关系就比较复杂了，因为需要考虑如何匹配到有关系的两个节点，以及关系本身的属性如何设置。这里我们就简单学一下如何建立节点之间的关系。
由于Neo4j CQL语法是以人类可读的格式。 Neo4j CQL也使用类似的箭头标记来创建两个节点之间的关系。
每个关系（ ）包含两个节点
在Neo4j中，两个节点之间的关系是有方向性的。 它们是单向或双向的。
如果我们尝试创建一个没有任何方向的关系，那么就会报错。
关系创建语法
CREATE ( )-[ ]-( )
我们这里直接使用创建新的节点来创建关系。
提示创建成功
这里关系名称是“CONTAINS”
关系标签是“contains”。
这么看是看不出有啥关系的，但是，我们可以从另外的一个位置
这样看下来，这个 Neo4J 简单操作是不是就学会了，阿粉接下来的文章中讲怎么使用 Java 来操作 Neo4J 数据库。欢迎大家来观看。
Apache Cassandra数据库的优缺点有哪些？
TAG标签： 数据库 Apache 优缺点 Cassandra
本文将超越众所周知的一些细节，探讨与 Cassandra 相关的不太明显的细节。您将检查 Cassandra 数据模型、存储模式设计、架构，以及与 Cassandra 相关的潜在惊喜。
在数据库历史文章 “What Goes Around Comes Around”中，Michal Stonebraker 详细描述了存储技术是如何随着时间的推移而发展的。实现关系模型之前，开发人员曾尝试过其他模型，比如层次图和有向图。值得注意的是，基于 SQL 的关系模型（即使到现在也仍然是事实上的标准）已经盛行了大约 30 年。鉴于计算机科学的短暂历史及其快速发展的步伐，这是一项非凡的成就。关系模型建立已久，以至于许多年来，解决方案架构师很容易为应用程序选择数据存储。他们的选择总是关系数据库。
诸如增加系统、移动设备、扩展的用户在线状态、云计算和多核系统的用户群之类的开发已经导致产生越来越多的大型系统。Google 和 Amazon 之类的高科技公司都是首批触及规模问题的公司。他们很快就发现关系数据库并不足以支持大型系统。
为了避免这些挑战，Google 和 Amazon 提出了两个可供选择的解决方案：Big Table 和 Dynamo，他们可以由此放松关系数据模型提供的保证，从而实现更高的可扩展性。Eric Brewer 的 “CAP Theorem”后来官方化了这些观察结果。它宣称，对于可扩展性系统，一致性、可用性和分区容错性都是权衡因素，因为根本不可能构建包含所有这些属性的系统。不久之后，根据 Google 和 Amazon 早期的工作，以及所获得的对可扩展性系统的理解，计划创建一种新的存储系统。这些系统被命名为 “NoSQL” 系统。该名称最初的意思是 “如果想缩放就不要使用 SQL”，后来被重新定义为 “不只是 SQL”，意思是说，除了基于 SQL 的解决方案外，还有其他的解决方案。
有许多 NoSQL 系统，而且每一个系统都缓和或改变了关系模型的某些方面。值得注意的是，没有一个 NoSQL 解决方案适用于所有的场景。每一个解决方案都优于关系模型，且针对一些用例子集进行了缩放。我的早期文章 “在 Data Storage Haystack 中为您的应用程序寻找正确的数据解决方案” 讨论了如何使应用程序需求和 NoSQL 解决方案相匹配。
Apache Cassandra是其中一个最早也是最广泛使用的 NoSQL 解决方案。本文详细介绍了 Cassandra，并指出了一些首次使用 Cassandra 时不容易发现的细节和复杂之处。
Apache Cassandra
Cassandra 是一个 NoSQL 列族 (column family) 实现，使用由 Amazon Dynamo 引入的架构方面的特性来支持 Big Table 数据模型。Cassandra 的一些优势如下所示：
高度可扩展性和高度可用性，没有单点故障
NoSQL 列族实现
非常高的写入吞吐量和良好的读取吞吐量
类似 SQL 的查询语言（从 0.8 起），并通过二级索引支持搜索
可调节的一致性和对复制的支持
灵活的模式
这些优点很容易让人们推荐使用 Cassandra，但是，对于开发人员来说，至关重要的一点是要深入探究 Cassandra 的细节和复杂之处，从而掌握该程序的复杂性。
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如是说。
No SQL DB是一种和关系型数据库相对应的对象数据库。按照数据模型保存性质将当前NoSQL分为四种：
1.Key-value stores键值存储, 保存keys+BLOBs
2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra.
3.Document-oriented面向文本, 文本是一种类似XML文档，MongoDB 和 CouchDB
4.Graph-oriented 面向图论. 如Neo4J.
关系型数据库的弊端：
关系型数据库的历史已经有30余年了，因此，在某些情况下，关系型数据库的弱点就会暴露出来：
1. “对象-关系 阻抗不匹配”。关系模型和面向对象模型在概念上存在天然的不匹配的地方，比如对象模型当中特有的“继承”，“组合”，“聚合”，“依赖”的概念在关系模型当中是不存在的。
2. “模式演进”。即随着时间的推移，需要对数据库模式进行调整以便适应新的需求，然而，对数据库模式的调整是的成本很高的动作，因此很多设计师在系统设计之初会设计一个兼容性很强的数据库模式，以应对将来可能出现的需求，然而在现在的web系统开发过程中，系统的变更更加频繁，几乎无法预先设计出一种“万能”的数据库模式以满足所有的需求，因此 模式演进的弊端就愈发凸显。
3. 关系型数据库处理 稀疏表时的性能非常差。
4. networkoriented data 很适合处理 人工智能、社交网络中的一些需求。
所以，各种各样的No SQL DB 出现了，这里只简单介绍下Neo4J 的基本知识。
Neo 数据模型
Neo4J 是一个基于图实现的No SQL DB, 其基本的数据类型有如下几种：
Node, Relationship, Property.
Node 对应于图中的 节点，Relationship 对应图中的边，Node 和 Relationship 都可以拥有Property，
Property 的数据结构为。
数据遍历
Neo 提供了Traverser对数据中的数据进行遍历。
关系数据库经过几十年的发展，已经非常成熟，但同时也存在不足：
表结构是强约束的，业务变更时扩充很麻烦。
如果对大数据量的表进行统计运算，I/O会很高，因为即使只针对某列进行运算，也需要将整行数据读入内存。
全文搜索只能使用 Like 进行整表扫描，性能非常低。
针对这些不足，产生了不同的 NoSQL 解决方案，在某些场景下比关系数据库更有优势，但同时也牺牲了某些特性，所以不能片面的迷信某种方案，应将其作为 SQL 的有利补充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分为4类：
Redis 是典型，其 value 是具体的数据结构，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被称为数据结构服务器。
以 list 为例：
LPOP key 是移除并返回队列左边的第一个元素。
如果用关系数据库就比较麻烦了，需要操作：
Redis 的缺点主要体现在不支持完成的ACID事务，只能保证隔离性和一致性，无法保证原子性和持久性。
最大的特点是 no-schema，无需在使用前定义字段，读取一个不存在的字段也不会导致语法错误。
特点：
以电商为例，不同商品的属性差异很大，如冰箱和电脑，这种差异性在关系数据库中会有很大的麻烦，而使用文档数据库则非常方便。
文档数据库的主要缺点：
关系数据库是按行来存储的，列式数据库是按照列来存储数据。
按行存储的优势：
在某些场景下，这些优势就成为劣势了，例如，计算超重人员的数据，只需要读取体重这一列进行统计即可，但行式存储会将整行数据读取到内存中，很浪费。
而列式存储中，只需要读取体重这列的数据即可，I/O 将大大减少。
除了节省I/O，列式存储还有更高的压缩比，可以节省存储空间。普通行式数据库的压缩比在 3:1 到 5:1 左右，列式数据库在 8:1 到 30:1，因为单个列的数据相似度更高。
列式存储的随机写效率远低于行式存储，因为行式存储时同一行多个列都存储在连续空间中，而列式存储将不同列存储在不连续的空间。
一般将列式存储应用在离线大数据分析统计场景，因为这时主要针对部分列进行操作，而且数据写入后无须更新。
关系数据库通过索引进行快速查询，但在全文搜索的情景下，索引就不够了，因为：
假设有一个交友网站，信息表如下：
需要匹配性别、地点、语言列。
需要匹配性别、地点、爱好列。
实际搜索中，各种排列组合非常多，关系数据库很难支持。
全文搜索引擎是使用 倒排索引 技术，建立单词到文档的索引，例如上面的表信息建立倒排索引：
所以特别适合根据关键词来查询文档内容。
上面介绍了几种典型的NoSQL方案，及各自的适用场景和特点，您可以根据实际需求进行选择。