NoSQL-Assignment-1

• NoSQL数据库是不遵循RDBMS原则的数据库和数据存储，NoSQL意思是不仅仅是 SQL

• 图数据库:
  • 用于存储数据网络信息，如社交关系。
  • 如：Neo4j
• 文档数据库:
  • 将每个键与称为文档的复杂数据结构配对。
  • 如：MongoDB
• 键值数据库:
  • 是最简单的 NoSQL 数据库。数据库中的每个项目都以属性名称（或 "键"）的形式与其值一起存储。
  • 如：Redis
• 列族数据库：
  • 针对大型数据集的查询进行了优化，将数据列（而不是行）存储在一起。
  • 如：Cassandra

• 关系型数据库
  • 中心化的
  • 处理密集，结构化的数据
  • 满足 ACID 性
  • 遵循 CA 原则
• NoSQL
  • 去中心化的
  • 处理稀疏数据，半/非结构化的数据
  • 主要是查询，很少更新
  • 满足 BASE 性
  • 遵循 AP 或 CP 原则

• CAP 定理（CAP Theorem）
  • 是由计算机科学家 Eric Brewer 提出的一个关于分布式数据存储系统的基本定理。该定理指出，在任何分布式数据存储系统中，无法同时完全满足以下三个特性：
    1. 一致性（Consistency）：每个客户端都有相同的数据视图。
    2. 可用性（Availability）：每个客户端始终可以读写。
    3. 分区容错性（Partition Tolerance）：系统在分布式物理网络中运行良好
• CAP 定理在 NoSQL 数据库中的重要性
  • NoSQL 数据库的设计通常会在 CAP 定理的背景下进行权衡，以满足特定应用场景的需求：
    1. 满足CA原则：系统几乎没有或根本没有分区容错性。一致性和可用性优先
    2. 满足AP原则：一致性受到影响，但系统始终可用，并且在部分分区时也能工作
       • Cassandra, DynamoDB
    3. 满足CP原则：可用性受到影响，但一致性和分区容错性优于可用性
       • MongoDB, HBase, Redis

• a.高可用性 (High Availability)
  • 每个客户端始终可以读写，读写实时更新
• b. 可扩展性 (Scalability)
  • 存储空间可扩展
  • 数据易于扩展
• c. 分布式系统 (Distributed System)
  • 去中心化的系统
  • 可有数千台机器分布在世界各地

• a.键值存储(Key-Value Store)
  • 简洁：数据主要采用Key-Value(KV)形式储存
  • 高速：数据驻留内存，重启时可再次加载进行使用
  • 易扩展：根据系统负载量，灵活添加或删除服务器
  • 对键可设置失效时间
• b. 列存储 (Column Store)
  • 更好的可扩展性
  • 高可用性
  • 适合离线批量数据处理
• c.文档数据库(Document Store)
  • 核心概念是 "文档 "的概念，它与 RDBMS 中的行相对应
  • 以某些标准格式或编码封装和编码数据，如 JSON（BSON）
  • 文档在数据库中通过代表该文档的唯一密钥进行处理
  • 将文档作为一个整体处理，避免将文档拆分为其组成的名称/值对
  • 文档是无模式的，可以是非结构的数据
• d.图形数据库(Graph Store)
  • 面向图形
  • 一切都以边、节点或属性的形式存储
  • 每个节点和边可以有任意数量的属性
  • 节点和边都可以贴标签
  • 标签可用于缩小搜索范围

• a. 实时分析：
  • 键值数据库Redis, 支持极高的读写速度，适合需要快速响应的实时分析应用。
• b. 大数据处理：
  • 列族数据库 Cassandra, 能够轻松地横向扩展，处理大数据量和高吞吐量的需求。
• c. 社交网络：
  • 图数据库 Neo4J，社交网络中的数据天然适合图模型，例如用户、朋友关系、点赞、评论等。Neo4j 通过图形算法和索引，能够高效地进行复杂的关系查询和路径查找，
• d. 物联网 loT:
  • 文档数据库MongoDB，能够处理结构化、半结构化和非结构化数据。物联网数据通常包括各种类型的传感器数据，这些数据具有高度的灵活性和多样性。MongoDB 提供了高效的存储和查询能力，支持时间序列数据的存储和分析，适合物联网应用中大量多变的数据处理需求。

• 实际应用场景：社交媒体评论管理
  • 社交媒体评论具有大量非结构化的数据，且用户在高峰期频繁发布和查看评论，系统需要支持高并发读写操作。
  • NoSQL 数据库具有可扩展性：NoSQL 数据库（如 MongoDB、Cassandra）能够水平扩展，通过增加更多节点来处理大规模数据和高并发请求。
  • 关系型数据库通常难以应对如此大规模的数据增长和高并发需求。

MATCH (v:Vehicle)-[:OWNED_BY]->(p:Person)
WITH p, collect(p.name) as owners
RETURN v, owners
Copy

• A. OPTIONAL MATCH 不是 Cypher 语句。
• B. OPTIONAL MATCH 为 Cypher 查询提供参数占位符。它保存参数化查询，然后根据客户提供的值与图进行可选匹配。
• C. OPTIONAL MATCH 会搜索可能存在也可能不存在的描述模式，并将模式中不存在的标识符赋值为 NULL。
• D. 可选匹配子句将获取一组属性值，并将其与数据库中的所有节点进行可选匹配。

• A. MATCH (a:Thing {id:3563}) DETACH DELETE a
• B. MATCH (a:Thing {id:3563}) OPTIONAL MATCH (a)-[r]-() DELETE a, r
• C. MATCH (a:Thing {id:3563}) DELETE a
• D. MATCH (a:Thing {id:3563})-[r]-(b) DELETE a, r

• A. MATCH (sarah:Person)-[:KNOWS]->(friend:Person) WHERE sarah.name = "Sarah" RETURN friend
• B. MATCH (sarah:Person)-[:KNOWS*1...2]->(friend:Person) WHERE sarah.name = "Sarah" RETURN friend
• C. MATCH (sarah:Person)-[:KNOWS]->(friend:Person) OPTIONAL MATCH (friend)-[:KNOWS]->(fof:Person) WHERE sarah.name = "Sarah" RETURN friend, fof
• D. 所有这些都是正确的。

// 创建 Show 节点
CREATE (got:Show {title: "Game of Thrones"})
	
// 创建 Character 节点
CREATE (jon:Character {name: "Jon Snow"})
CREATE (dany:Character {name: "Daenerys Targaryen"})
CREATE (tyrion:Character {name: "Tyrion Lannister"})
	
// 创建 Actor 节点
CREATE (kit:Actor {name: "Kit Harington"})
CREATE (emilia:Actor {name: "Emilia Clarke"})
CREATE (peter:Actor {name: "Peter Dinklage"})
	
CREATE (kit)-[:ACTED_IN]->(got)
CREATE (emilia)-[:ACTED_IN]->(got)
CREATE (peter)-[:ACTED_IN]->(got)
	
CREATE (jon)-[:HAS_CHARACTER]->(got)
CREATE (dany)-[:HAS_CHARACTER]->(got)
CREATE (tyrion)-[:HAS_CHARACTER]->(got)
	
CREATE (kit)-[:PLAYS]->(jon)
CREATE (emilia)-[:PLAYS]->(dany)
CREATE (peter)-[:PLAYS]->(tyrion)	
Copy

• A. admin数据库
• B. user数据库
• C. config数据库
• D. test 数据库

• A. MongoDB单个文档大小上限为64MB
• B. 文档的值只可以是字符串类型
• C. 文档中可以有重复的键
• D. 不建议自定义_id键

• 易用性：灵活的文档模型。JSON格式简单易学
• 支持高性能访问数据。存储引擎是文档型数据库的核心组件。
• 可扩展性：支持大数据分布式存储，服务能力水平可横向弹性扩展