非关系型数据库有哪些特点-适配海量数据快速读写存储

刚接手项目那会一直死磕传统数据库，直到业务数据暴涨才真切摸清非关系型数据库有哪些特点，硬扛了半个月卡顿报错，才一点点摸透它和以往用的库完全不是一套逻辑。

数据量级突然往上翻了好几倍，单表关联查询一多，系统响应速度直接断崖式下跌，频繁出现超时等待，常规优化索引、分表都没什么实际效果。按照以前的思路不停调整字段结构、约束关系，折腾了好几天，服务器负载依旧居高不下，稍微并发高一点就直接卡顿瘫痪。

结构不用强行统一规整是很明显的优势。新增业务字段的时候，不用改动整张表的原有架构，不用提前做繁琐的字段约束设计，每条数据都能按照自身格式单独存储。不用纠结表与表之间复杂关联，不用严格遵循固定范式，临时追加属性信息，上线调整都格外轻松，不用大动干戈重构底层存储。

后来才反应过来，这种数据库天生就不擅长复杂联表事务。多表关联、强一致性事务处理远不如关系型数据库稳妥，稍微牵扯多层数据关联，查询效率就变得很差。当初没分清适配场景，混用两种存储方式，夜里频繁出现数据错乱，排查问题耗费了大量时间。

横向扩展格外轻松。业务持续增长，数据源源不断涌入的时候，不用更换高性能服务器，直接新增节点就能分担存储压力。集群扩容几乎不用停机调整，分布式部署灵活度很高，就算单台节点出现故障，整体业务也不会直接中断，容错能力远比老旧架构要好很多。

读写响应速度格外突出。海量零散日志、用户行为这类无序数据，存入之后调取速度极快，简单单条查询几乎瞬间返回结果。不像关系库要层层校验、关联匹配，面对高频写入场景，抗压能力要强上一大截，日常接口并发请求再多，也很少出现排队阻塞的情况。

没办法做到严格的数据事务一致，很多场景只能保证最终一致。金融对账、资金结算这类对数据精准度要求极高的业务，根本不敢单独使用。稍有疏忽就会出现数据同步延迟，前后数据对不上，事后回溯溯源也十分麻烦，这也是很多人踩过却不在意的短板。

存储格式十分灵活多样，文档、键值、时序各类数据都能直接存放。不用死板固定数据类型，不规则、多变的业务数据都能妥善保存，适配短视频、用户标签、实时日志这类杂乱无规律的数据再合适不过。之前一直执着规整所有数据格式，白白浪费了它本身最大的优势。

长时间运行下来也明白，它不是全面优于传统数据库，只是扬长避短适配特定场景。强求它做严谨关联事务，只会无限放大缺陷，单纯用来做海量数据吞吐存储，优势又无可替代。

关掉后台监控的时候，还在懊悔一开始没有分清两者差异，白白浪费了大量调试时间。