云计算与大数据 第一部分：云计算相关考点核心概念云计算定义与特征：按需自助服务、广泛的网络访问、资源池化、快速弹性、可计量的服务。服务模式：这是重中之重。· IaaS：基础设施即服务。理解提供计算、存储、网络等基础资源。考点常涉及：云服务器、云存储（如对象存储、块存储）、虚拟网络。· PaaS：平台即服务。提供应用程序开发、运行和管理的环境。考点重点：云数据库服务（如RDS）、大数据平台、中间件服务。这是与数据库工程师最相关的部分。· SaaS：软件即服务。直接提供应用软件。部署模式：· 公有云：第三方面向公众提供。· 私有云：为单一组织构建。· 社区云：特定社区共享。· 混合云：混合两种或以上模式，关注数据和应用的可移植性。与数据库技术的结合（重点！）云数据库：· 概念：部署和虚拟化在云计算环境中的数据库。· 特性：高可扩展性、高可用性、多租户、按使用付费。· 服务类型： · 关系型云数据库：如AWS RDS/Aurora，阿里云RDS/PolarDB。考点：读写分离、自动备份、一键扩展、高可用架构。 · NoSQL云数据库：如键值型（Redis云服务）、文档型（MongoDB云服务）、列族型（HBase云服务）、图数据库云服务。数据库上云策略：· 迁移评估：兼容性、性能、成本、安全性评估。· 迁移流程：结构迁移、数据迁移（全量+增量）、应用迁移、验证与切换。· 云上数据库运维：监控、备份恢复、性能优化、安全策略（IAM、加密、网络隔离）与传统运维的区别。虚拟化与容器技术：· 虚拟化：是云计算的基石，实现资源隔离与池化。· 容器化：Docker、Kubernetes。考点：数据库的容器化部署、有状态应用管理、持久化存储。第二部分：大数据相关考点核心概念大数据5V特征：Volume、Velocity、Variety、Value、Veracity。大数据处理流程：· 数据采集 → 数据存储 → 数据处理与分析 → 数据可视化/应用。大数据技术生态：以Hadoop/Spark为核心的生态圈。核心技术（重点！）分布式存储：· HDFS：架构（NameNode, DataNode）、容错机制、数据块、写入/读取流程。分布式计算：· MapReduce：编程模型（Map, Shuffle, Reduce阶段）、优缺点。· Spark：核心概念（RDD弹性分布式数据集）、比MapReduce快的原理（内存计算、DAG执行引擎）。了解Spark SQL。NoSQL数据库：为什么会出现？CAP/BASE理论。· 键值数据库：Redis，适用场景（缓存、会话存储）。· 文档数据库：MongoDB，数据结构（BSON），适用场景（内容管理、用户画像）。· 列族数据库：HBase，与HDFS关系， RowKey设计原则，适用场景（海量明细查询、时序数据）。· 图数据库：Neo4j，适用场景（社交关系、推荐、风控）。与数据库技术的结合（重点！）数据仓库与大数据平台：· 传统数据仓库 vs. 大数据平台（Hive、HBase、Spark SQL）。· Hive：本质是将SQL转换为MapReduce/Spark任务。理解其数据模型、表类型（内部表、外部表）、分区与分桶。· 数据湖概念：存储原始格式数据的存储库，支持结构化、半结构化、非结构化数据。数据集成与ETL：· 如何将传统关系型数据库（Oracle, MySQL）中的数据同步到大数据平台（使用Sqoop, Flume, Kafka等工具）。大数据环境下的数据库设计考量：· 数据模型从“以事务为中心”转向“以分析为中心”。· 关注数据冗余、反范式化设计以提高查询性能。· 数据分区策略（时间分区、范围分区等）对查询效率的影响。第三部分：常考题型与重点关联选择题/填空题：· 云服务模式的区分。· 大数据5V特征。· CAP/BASE理论。· 常见NoSQL数据库与其适用场景的匹配。· Hadoop核心组件（HDFS, YARN, MapReduce）的功能。简答题/案例分析题：· 场景设计：给定一个高并发、海量数据的业务场景（如电商大促、物联网日志分析），要求设计技术架构。回答中需包含： · 是否采用云计算？用哪种服务模式（PaaS/IaaS）和部署模式？ · 数据存储选型：关系型数据库用于核心交易，NoSQL（如Redis）用于缓存，HBase/HDFS用于海量日志。 · 数据处理：使用Spark进行实时/离线分析。 · 数据库高可用与扩展方案：云数据库的读写分离、分库分表策略。· 新旧技术对比：比较传统Oracle RAC架构与基于云数据库（如PolarDB）实现高可用的优劣。· 迁移方案：设计一个将本地MySQL数据库迁移到云RDS的方案，并说明关键步骤和风险点。备考建议抓大放小：重点理解 “概念”、“区别”、“适用场景”。建立关联：将云/大数据技术与传统数据库知识（如事务、索引、范式）关联思考。例如，在分布式环境下，传统的事务（ACID）如何演变？索引设计有何不同？关注案例：多研究阿里云、AWS、腾讯云等主流厂商的数据库产品文档和解决方案，这些常是考题的素材来源。结合考纲：务必以最新的官方指定教程和考试大纲为最终依据，本整理是核心考点的提炼。总结：对于数据库系统工程师，云计算和大数据的核心是 “数据库技术如何在新的计算和存储范式下演进与应用”。务必掌握 云数据库服务、NoSQL数据库选型 和 Hadoop/Spark生态的基本原理。

nosql知识点 NoSQL是考试的重点和热点，通常会与传统的SQL关系型数据库进行对比考察。一、NoSQL概述与核心理念定义：Not Only SQL，泛指非关系型的、分布式的数据库系统。不保证ACID特性{tabs}{tabs-pane label="ACID"}Atomicity直译：原子性含义：事务中的所有操作要么全部成功提交（Commit），要么全部失败回滚（Rollback），不可分割（类似原子的不可分割性）。Consistency直译：一致性含义：事务执行前后，数据库都必须处于一致的状态（如转账前后总金额不变）。Isolation直译：隔离性含义：多个并发事务执行时，彼此之间相互隔离，互不干扰（如避免脏读、不可重复读）。Durability直译：持久性含义：事务一旦提交，其对数据库的修改必须是永久性的（即使系统崩溃也不会丢失）。{/tabs-pane}{/tabs}，旨在解决大规模数据集合、多数据种类带来的挑战，尤其是大数据应用难题。产生背景：· 大数据时代的3V挑战：Volume（海量）、Velocity（高速）、Variety（多样）。· 关系型数据库的局限：在高并发、海量数据场景下，扩展性差（难以水平扩展）、读写性能瓶颈、僵化的表结构难以应对半结构/非结构化数据。核心特点（与RDBMS对比）：· 模式灵活：无需预定义固定表结构，支持动态添加字段（Schema-less）。· 高可扩展性：易于通过增加节点实现水平扩展。· 高性能：针对特定数据模型和访问模式优化，读写速度快。· 高可用性：通过分布式、副本机制保障。· 弱一致性（最终一致性）：遵循BASE理论，而非ACID。 · BASE：Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致）。CAP定理（核心考点！）：· 在分布式系统中，一致性（Consistency）、可用性（Availability） 和 分区容忍性（Partition Tolerance） 三者不可兼得，最多只能同时满足其中两项。· CP系统：保证一致性和分区容忍性（如：HBase， MongoDB的早期版本）。在发生分区时，可能牺牲可用性。· AP系统：保证可用性和分区容忍性（如：Cassandra， DynamoDB）。在发生分区时，可能返回旧数据，牺牲强一致性。· CA系统：单点关系型数据库，难以在分布式环境中实现。二、NoSQL主要数据模型与代表产品（重点！）这是分类考察的核心，必须掌握每种类型的特点、适用场景和典型产品。数据模型 核心概念 典型产品 优点 适用场景 不适用场景键值数据库 简单的“键-值”对存储，值可以是任意数据块。 Redis（内存型）、Memcached、DynamoDB 性能极高，结构简单，扩展容易。 会话存储、缓存、排行榜、实时配置。 复杂查询、多键事务、关系数据。文档数据库 以文档（如JSON/BSON）为基本单位，文档内可嵌套。 MongoDB、CouchDB 模式灵活，数据结构自然，支持复杂查询（二级索引）。 内容管理、用户档案、日志数据、电商产品目录。 需要多文档事务或复杂Join的场景。列族数据库 按“列族”存储数据，适合存储半结构化的海量数据。 HBase、Cassandra 可扩展性极好，适合海量数据存储和批量读取。 大数据分析（如Hadoop生态）、日志聚合、时间序列数据。 需要复杂事务或实时强一致性读写的场景。图数据库 以“图”结构存储实体（节点） 和关系（边）。 Neo4j、TigerGraph 高效处理复杂关系，路径查询性能远超关系型数据库。 社交网络、推荐引擎、欺诈检测、知识图谱。 大规模数据但关系简单的场景，或需要频繁全表扫描的场景。三、关键技术概念分片：将数据水平拆分到多个物理节点上的技术，是实现水平扩展的基础。复制：将数据副本存储在多台服务器上，以提高可用性和读性能。· 主从复制：写主，读可从。· 多主/对等复制：任何节点都可写，更复杂。一致性协议：· 最终一致性：数据副本经过一段时间后最终达成一致。· 读写一致性：写后读保证读到最新数据。· 仲裁机制：如R + W > N（N为副本总数，R为读副本数，W为写副本数）来平衡一致性与可用性。索引：如MongoDB的B树索引、Redis的Sorted Set等，用于加速查询。四、应用场景与选择原则· 何时选择NoSQL？数据量巨大且增长迅速，需要水平扩展。数据结构不固定，变化频繁。应用对高性能、高并发读写有严格要求。数据模型简单（KV）或高度关联（图），关系型数据库不擅长。业务可以接受最终一致性。· 何时仍选择关系型数据库？需要复杂的事务（如银行转账）。数据结构稳定，业务逻辑基于严格的实体关系。需要复杂的多表关联查询和报告。数据一致性是首要要求。五、挑战与趋势挑战：· 缺乏统一的查询语言（SQL是标准）。· 事务支持相对较弱（虽然MongoDB等已支持多文档事务）。· 技术生态和工具链不如关系型数据库成熟。· 对开发人员的架构设计能力要求更高。趋势：· 多模数据库：一个数据库支持多种数据模型（如文档+图）。· NewSQL：尝试兼具NoSQL的扩展性和SQL的ACID特性（如：Google Spanner， TiDB）。· 云原生数据库：与云计算深度集成，按需伸缩（如：AWS DynamoDB， Azure Cosmos DB）。备考建议重点掌握：CAP定理、四种数据模型的对比（用表格形式记忆）、典型产品的归类与应用场景。理解区别：深刻理解NoSQL与SQL在扩展方式（水平 vs 垂直）、一致性模型（BASE vs ACID）、模式（灵活 vs 固定）上的根本区别。关注真题：多做历年真题中关于NoSQL的选择题和案例分析题，熟悉出题角度。结合实际：将知识点与常见的互联网应用（如电商、社交、日志系统）联系起来，理解技术选型的逻辑。

SQL中通配符%和*的区别 标准SQL中的通配符‌：%是标准SQL中LIKE操作符使用的通配符，表示匹配任意数量的字符(包括零个字符)例如：LIKE 'abc%'匹配以"abc"开头的所有字符串特定系统中的通配符‌：*是某些特定系统(如Windows命令行、Unix shell)中使用的通配符在一些数据库工具(如MySQL命令行客户端)的简单模式匹配中也支持*主要区别‌：在标准SQL查询中必须使用%*通常只在特定工具或非标准扩展中使用例如在MySQL中，*可用于命令行简单查询，但在SQL语句中仍需用%何时用哪个‌：编写SQL语句时：总是用%使用数据库工具的非SQL模式匹配时：可能用*(取决于工具)在正则表达式中：两者都不是通配符，有完全不同的含义当编写标准SQL时，LIKE操作符总是使用%作为通配符。

group by重复聚合问题 今天测试时发现有个数据汇总的很有问题，查了下发现出现重复聚合的问题JOIN 关联导致数据膨胀（核心原因）问题本质：LEFT JOIN complete c ON o.part_number = c.nbbh 导致 ‌orders 表数据被重复关联‌。若 complete 表中存在 ‌多个 nbbh 与同一个 part_number 匹配‌，则 orders 表的单条记录会被扩展为多条，进而触发 SUM 函数重复累加 quantity 值验证方法‌：sqlCopy Code-- 检查关联后的总行数是否膨胀SELECT o.part_number, COUNT(*) FROM orders o LEFT JOIN complete c ON o.part_number = c.nbbh WHERE o.zt = '安全库存' GROUP BY o.part_number;若结果中 COUNT(*) 大于 1，则说明存在重复关联‌36。二、修正方案方案 1：先聚合再关联（推荐）在关联 complete 表前，先对 orders 表按 part_number 完成聚合：sqlCopy CodeSELECTo.part_number, o.urgent_order_quantity -- 直接使用子查询的聚合结果FROM (SELECT part_number, SUM(CASE WHEN zt = '安全库存' THEN quantity ELSE 0 END) AS urgent_order_quantity FROM orders GROUP BY part_number) o LEFT JOIN complete c ON o.part_number = c.nbbh;方案 2：移除冗余关联若 complete 表数据未被实际使用，直接删除关联逻辑：sqlCopy CodeSELECTpart_number, SUM(CASE WHEN zt = '安全库存' THEN quantity ELSE 0 END) AS urgent_order_quantityFROM ordersGROUP BY part_number;三、其他潜在问题排查‌字段值匹配问题‌执行以下查询确认 zt 字段实际值是否严格为 安全库存：sqlCopy CodeSELECT DISTINCT zt FROM orders WHERE part_number = '具体零件编号';若存在空格或特殊字符（如 安全库存 ），需修正条件判断‌12。‌数据重复问题‌检查 orders 表中同一 part_number 是否存在多条 zt = '安全库存' 的记录：sqlCopy CodeSELECT part_number, COUNT(*) FROM orders WHERE zt = '安全库存' GROUP BY part_number;四、总结‌核心问题‌：LEFT JOIN 导致数据重复，引发 SUM 计算错误‌36。‌推荐操作‌：优先采用 ‌先聚合再关联‌ 的方案，避免关联表引发数据膨胀‌36。‌补充验证‌：同步检查字段值匹配性和数据重复性‌14。确实存在重复关联问题DeepSeek-R1满血版 回答完成深度思考完成 用时23秒，搜索全网23篇资料针对多表关联导致的数据重复问题，以下是系统性解决方案及实施步骤：一、重复关联根因分析‌关联条件非唯一性‌LEFT JOIN 关联的右表（如 complete 表）中存在 ‌多个记录匹配左表同一主键‌，导致左表单条数据被重复扩展‌17。‌验证方法‌：sqlCopy Code-- 检查 complete 表中 nbbh 的重复性SELECT nbbh, COUNT(*) FROM complete GROUP BY nbbh HAVING COUNT(*) > 1;‌一对多关系未处理‌若 orders.part_number 与 complete.nbbh 是 ‌一对多关系‌，直接关联会导致 orders 数据膨胀‌67。二、解决方案（按优先级排序）方案 1：先聚合右表再关联（推荐）在关联前对右表按关联字段聚合，确保左表每条记录仅匹配右表一条数据‌16：sqlCopy CodeSELECTo.part_number, SUM(CASE WHEN o.zt = '安全库存' THEN o.quantity ELSE 0 END) AS safety_stock_quantityFROM orders oLEFT JOIN (SELECT nbbh, SUM(sl) AS total_sl -- 对右表聚合 FROM complete GROUP BY nbbh) c ON o.part_number = c.nbbhGROUP BY o.part_number;方案 2：增加唯一性关联条件若右表存在其他唯一字段（如时间、状态），通过复合条件强制一对一关联‌17：sqlCopy CodeSELECTo.part_number, SUM(CASE WHEN o.zt = '安全库存' THEN o.quantity ELSE 0 END) AS safety_stock_quantityFROM orders oLEFT JOIN complete c ON o.part_number = c.nbbhAND c.date = '2025-04-15' -- 补充唯一条件（需按业务调整）GROUP BY o.part_number;方案 3：使用 DISTINCT 去重对关联结果强制去重（适用于小数据量场景，性能敏感场景慎用）‌34：sqlCopy CodeSELECT DISTINCTo.part_number, SUM(CASE WHEN o.zt = '安全库存' THEN o.quantity ELSE 0 END) OVER (PARTITION BY o.part_number) AS safety_stock_quantityFROM orders oLEFT JOIN complete c ON o.part_number = c.nbbh;三、附加验证与优化‌数据类型一致性验证‌检查 orders.part_number 与 complete.nbbh 的数据类型是否严格一致（如 VARCHAR vs BIGINT），避免隐式转换导致关联失效‌2。‌空值处理优化‌在聚合函数中显式处理空值，避免统计失真‌56：sqlCopy CodeSUM(CASE WHEN o.zt = '安全库存' THEN COALESCE(o.quantity, 0) ELSE 0 END)四、典型场景对比场景 推荐方案 优势 局限性右表数据量大 方案1（先聚合） 减少关联数据量，提升性能 需修改SQL结构右表有唯一辅助字段 方案2（复合条件） 保留明细数据 依赖额外唯一字段快速临时修复 方案3（DISTINCT） 改动最小 性能差，不适用大数据量一、重复统计根因分析 ‌complete 表多值关联引发数据膨胀‌ LEFT JOIN complete c ON o.part_number = c.nbbh 导致 orders 表每条记录可能关联到 complete 表多条数据，进而使 SUM 函数对 quantity 重复累加‌16。 ‌关联表未预聚合‌ complete 表的 sl 字段未按 nbbh 预先聚合，直接关联导致统计值翻倍‌68。 二、优化方案（分两步修正） 1. 修正 complete 表关联逻辑 对右表 complete 先按 nbbh 聚合，消除重复关联影响： sql Copy Code SELECT o.part_number, SUM(CASE WHEN o.zt = '安全库存' THEN o.quantity ELSE 0 END) AS urgent_order_quantity, SUM(CASE WHEN o.zt = '周计划' THEN o.quantity ELSE 0 END) AS weekly_plan_quantity, SUM(CASE WHEN o.zt = '外围' THEN o.quantity ELSE 0 END) AS external_plan_quantity, COALESCE(c.total_sl, 0) AS completed_quantity -- 直接引用预聚合结果 FROM orders o LEFT JOIN ( SELECT nbbh, SUM(sl) AS total_sl -- 预先聚合右表 FROM complete GROUP BY nbbh ) c ON o.part_number = c.nbbh GROUP BY o.part_number; 2. 验证字段值匹配性 检查 orders.zt 字段的实际值是否包含 安全库存、周计划、外围 等精确匹配值： sql Copy Code SELECT DISTINCT zt FROM orders; 若存在空格或大小写问题，需调整 CASE WHEN 条件中的匹配规则‌14。 三、关键优化点说明 优化项 原查询问题 修正后效果 complete 表关联方式 直接关联导致 SUM 重复计算‌68 预聚合后消除重复关联风险‌68 字段值匹配 模糊匹配导致统计遗漏‌14 精确匹配目标状态值‌14 空值处理 未显式处理 NULL 值‌48 COALESCE 确保数值稳定性‌48 四、附加验证建议 ‌关联字段一致性验证‌ 检查 orders.part_number 和 complete.nbbh 的编码规则是否一致（如数据类型、分隔符等），避免关联失效‌57： sql Copy Code SELECT part_number FROM orders LIMIT 10; SELECT nbbh FROM complete LIMIT 10; ‌数据重复性排查‌ 确认 orders 表中同一 part_number 是否存在多条相同 zt 的记录： sql Copy Code SELECT part_number, zt, COUNT(*) FROM orders GROUP BY part_number, zt HAVING COUNT(*) > 1;

JSON和SQL在数据库查询中的具体区别 JSON和SQL在数据库查询中的具体区别‌数据表示方式‌：‌JSON‌：JSON数据以键值对的形式存储，是一种半结构化数据格式。它不需要预先定义的数据模式，适合存储复杂和多变的数据结构‌3。‌SQL‌：SQL数据存储在预定义的表格中，每行代表一条记录，每列代表一个字段，数据结构固定‌3。‌查询方式‌：‌JSON‌：查询JSON数据通常需要使用特定的函数或工具，如MySQL中的JSON_TABLE函数，将JSON文档转换为关系型表格数据进行查询。这种方式适合需要频繁操作JSON数据的应用场景‌4。‌SQL‌：SQL通过标准的SQL语句进行查询，支持复杂的查询语句和函数，能够进行高效的数据检索和分析‌14。‌性能和优化‌：‌JSON‌：查询JSON数据可能需要额外的转换步骤，这可能会影响查询性能。此外，JSON数据的模式灵活性也意味着索引和优化相对复杂‌