NoSql数据库概念
Lindorm
https://www.aliyun.com/product/apsaradb/lindorm
Lindorm面向海量 泛时序、半结构化和非结构化数据 提供低成本存储、在线查询和离线分析等一站式数据服务，针对AI场景支持正排、全文、向量融合检索和AI推理能力；兼容MySQL协议、HBase、ES、Hive、Spark、HDFS等开源标准。提供宽表、时序、向量等数据模型。
是分布式NoSQL数据库。 是云原生多模数据库。
Lindorm vs MySQL 核心区别
| 特性对比 | Lindorm (NoSQL) | MySQL (关系型数据库) |
|---|---|---|
| 数据模型 | 支持宽表、时序、搜索等多种模型，半结构化/非结构化数据友好 | 关系模型，基于固定的表和行列，擅长结构化数据 |
| 扩展方式 | 水平扩展（ Scale-Out ），轻松扩展至数百节点，存储计算分离 | 垂直扩展（ Scale-Up ），通常通过升级单机性能实现 |
| 查询语言 | 兼容SQL（如Phoenix SQL），也支持NoSQL原生API | 标准SQL |
| 一致性保证 | 灵活，支持强一致、最终一致等多种级别 | 严格遵循ACID事务，保证强一致性 |
| 典型应用场景 | 互联网、IoT、风控、日志、广告等海量数据、高并发、低延迟场景 | 金融、电信、ERP等对数据一致性和完整性要求极高的业务系统 |
非结构化数据：它包含了大量的信息，但这些信息没有预定义的模型，机器无法直接理解其内容。
例子：
-
一张猫的图片：你能看出是猫，但计算机需要图像识别技术才能识别出主体是猫。
-
一段会议录音：你能听懂内容，但计算机需要语音转文本技术才能将其转换为结构化或半结构化的文字。
-
一份产品介绍PDF：包含了标题、段落、图片，但计算机需要自然语言处理技术来提取关键信息。
数据类型
（从数据内容角度讲，是数据类型）
三种数据类型的核心差异
| 维度 | 结构化数据 | 半结构化数据 | 非结构化数据 |
|---|---|---|---|
| 核心特征 | 规整的二维表格结构 | 具有自我描述性，无固定模式 | 无固定格式和模型 |
| 数据模型 | 关系模型（行和列） | 树状或图状结构（如JSON、XML） | 无特定模型 |
| 模式（Schema） | 模式先行：先定义表结构，再写入数据 | 模式后行或自描述：结构与数据共存 | 无模式 |
| 可读性 | 对人机都友好，但不够直观 | 对人机都比较友好 | 对人类友好，对机器不友好 |
| 扩展性 | 差，修改表结构复杂 | 好，可以灵活添加字段 | 天然具备 |
| 典型例子 | MySQL/Oracle中的表 | JSON、XML、HTML、电子邮件 | 图片、视频、音频、Word/PDF文档 |
| 查询与分析 | 使用SQL，非常高效 | 使用特定查询语言（如XPath, JSON Path），或转换为SQL查询 | 需要复杂处理（如AI、NLP）才能提取信息 |
| 存储占比 | 约10% | 约10% | 约80% |
数据模型
（从存储的角度讲，是数据模型）
简单来说，你可以把它们想象成不同用途的工具和文件柜：
-
关系模型：一个结构严谨、关系复杂的文件柜。
-
宽表模型：一个能无限扩展抽屉宽度和数量的巨型仓库货架。通过将经常需要一起查询的数据冗余存储在一张巨大的、可水平扩展的表中，来避免复杂的
JOIN操作。 -
时序模型：一个专门为时间序列数据优化的、带时间戳的流水记录仪。这类数据的特点是：按时间顺序到来、几乎只追加写入、近期数据更常被读取。
-
搜索模型：一个专为快速全文检索而建的智能图书索引。
四种数据模型核心差异对比
| 维度 | 关系模型 | 宽表模型 | 时序模型 | 搜索模型 |
|---|---|---|---|---|
| 核心特征 | 表与表之间的关系（主外键） | 面向列，可扩展性极强 | 数据按时间顺序产生和存储 | 倒排索引，全文检索 |
| 数据形态 | 规整的二维表格 | 稀疏的、列可动态扩展的超大表 | 带时间戳的（指标+标签）数据 | 文档（Document） |
| 首要优势 | 复杂的关联查询和数据一致性 | 海量数据的 随机读写 与高扩展性 | 时间窗口的 聚合查询 与 高写入吞吐量，极高的数据压缩率，内置了针对时间范围的聚合函数 | 灵活的全文搜索和模糊查询 |
| 典型查询 | JOIN ... ON ... WHERE ... | SELECT * FROM huge_table WHERE rowkey = ? | SELECT ... FROM ... WHERE time > now() - 1h | GET /index/_search { "query": { "match": { "content": "关键词" } } } |
| 适用场景 | 财务系统、ERP、CRM等核心交易系统 | 用户画像、社交Feed流、物联网大数据平台 | 监控系统、IoT传感器数据、业务指标分析 | 电商商品搜索、日志分析、内容检索 |
| 代表数据库 | MySQL, PostgreSQL | Lindorm, Cassandra, HBase | Lindorm, InfluxDB, Prometheus | Lindorm, Elasticsearch |
云原生
一句话理解云原生
云原生就像“打车” vs 传统方式的“买车”。
-
传统方式（非云原生）：你需要自己购买服务器（买车），自己保养、维修、升级硬件（养车），高峰期可能资源不够，低谷期资源又闲置浪费。
-
云原生方式：你随时随地通过App叫车（按需使用云资源），无需关心车辆维护，平台负责调度和扩容，你只为实际乘坐的里程付费（按量计费）。
云原生特点
云原生是一种构建和运行应用程序的方法论，它充分利用云计算的优势。它的核心可以概括为以下四点，而这四点也正是Lindorm的设计精髓：
| 核心特征 | 传统数据库（如自建MySQL） | 云原生数据库（如Lindorm） |
|---|---|---|
| 1. 弹性伸缩 | Scale-Up（纵向扩展）：需要停机升级CPU、内存、硬盘，有上限。 | Scale-Out（横向扩展）：通过添加或移除节点来无缝扩容/缩容，对业务无感知。 |
| 2. 按需付费 | 固定成本：无论用不用，购买的服务器和软件许可证费用都已产生。 | 可变成本：根据实际使用的计算、存储资源量进行计费，用多少付多少。 |
| 3. 高可用与自愈 | 手动或半自动：需要DBA搭建主从复制，故障时手动切换，恢复时间长。 | 服务化与自动化：内置多副本、自动故障检测与切换，实现自我修复，保障服务SLA。 |
| 4. 微服务与解耦 | 单体架构：计算和存储紧密耦合在同一台服务器中。 | 存储计算分离：计算节点和存储节点分离，可以独立扩展，资源利用率更高。 |
Lindorm云原生特点
-
极致的弹性伸缩
-
存储弹性：采用 存储 计算 分离架构。数据存储在持久可靠的云存储（如阿里云OSS）上，理论上容量无限。你不需要为未来的数据增长预先规划昂贵的硬件。
-
计算弹性：计算节点（负责SQL解析、事务处理等）可以独立地快速扩容或缩容。在“双11”大促时，可以快速增加节点以应对洪峰流量；大促结束后，立即缩减以节省成本。
-
-
透明的按需付费
-
你无需为数据库软件本身支付高昂的许可证费用。
-
费用通常由“计算资源”和“存储资源”两部分组成。计算资源根据你选择的节点规格和数量计费，存储资源根据你的实际数据量计费。这种模式极大地降低了初创企业和业务波动性大的公司的成本。
-
-
服务化的高可用与自愈
-
Lindorm在底层默认采用多副本机制（通常为3副本），将数据分布在不同机架甚至不同可用区的服务器上。
-
当任何一个节点或甚至整个机房发生故障时，系统会自动进行故障转移和流量切换，应用几乎无感知，实现了自我修复。
-
-
面向微服务的设计
-
除了存储计算分离，Lindorm本身也支持多模数据引擎（宽表、时序、搜索、文件）。你可以将其视为一个统一的“数据微服务”平台，用一个数据库服务来满足多种业务的数据需求，简化了架构。
-