标签：nosql

共 73 篇相关文章

IT 累计浏览 4,411

从淘汰Oracle数据库的事情说起

作者从公司淘汰Oracle数据库的内部实践说起，类比国内“去IOE”浪潮，点明核心动因是高昂的维护成本与扩展性瓶颈。但他指出，这绝非简单地将Oracle换为MySQL或上云，而是一场有计划的架构演进——部分业务数据已迁移至DynamoDB等NoSQL，甚至落盘至S3，计算层则由Hadoop或Spark接管。由此引出一个关键问题：NoSQL的兴起是否意味着SQL将过时？作者的回答是“恰恰相反”。他通过两个实例佐证：一是团队将复杂的Scala逻辑重写为Spark SQL，让更熟悉SQL的数据分析师能直接参与；二是基础设施团队通过Hive等工具，在底层从数据库切换至MapReduce后，依然对上层提供稳定的SQL接口。SQL作为一种数据抽象和思维范式，其生命力反而在增强。文章还反思了关系型数据库自身“被成功到滥用”的问题，例如在不适宜的高并发场景硬用Oracle。最后，作者将话题从技术延伸到人与技能，指出诸如DBA等纯粹依赖维护的岗位将面临挑战，而真正的核心技术价值在于解决那些不易被工具或新平台简单替代的根本问题。整篇文章从一次具体的架构迁移，引发了对技术演进逻辑和工程师核心能力的深层思考。

IT 累计浏览 2,191

Pora2应用中HBase高并发读写性能优化

这篇讲的是淘宝搜索的Pora2实时分析系统在大量使用HBase进行高并发读写时，所遇到的一系列性能“坑”及优化实践。系统上线后出现处理延迟、集群压力大的问题，排查发现根源主要在于HBase的使用方式。文章拆解了几个典型案例：一是HBase默认的Periodic Flusher机制引发了过于频繁的flush与compact，通过调整其超时阈值得到了缓解；二是下游消费消息队列时未控制Scan频率，对Region Server造成了无谓压力；三是在超大并发下，过多的客户端连接耗尽了服务端Handler，作者的解决方案是减少进程数、增加线程数以复用连接。此外，还涉及了因rowkey生成代码bug导致的数据访问热点，以及Bulk Load数据未做Major Compaction引起的读取性能衰减。文章最后总结道，高并发场景下必须合理使用HBase，避免不当操作形成“越慢越压、越压越慢”的恶性循环。这些从实战中沉淀的细节，对同类系统的设计与调优很有参考价值。

IT 累计浏览 1,671

HBase在单Column和多Column情况下批量Put的性能对比分析

这篇讲的是HBase在不同数据模型下批量写入的性能差异。作者从一个实际现象出发：将数据存储在单个列（单列模式）与拆分成多个列（多列模式）时，批量Put的吞吐量存在巨大差距。测试数据显示，单列模式的TPS是多列模式的7倍以上，RPC调用次数也相差9倍。文章核心是从HBase的KeyValue内存模型入手，解释了这种差距的根本原因。在多列模式下，每一列都会携带大约50-60字节的元数据开销（如行键、列族、时间戳等），导致一行数据在客户端缓冲区中占用的内存远大于单列模式，进而触发更频繁的RPC提交，拉低了整体吞吐。作者通过代码计算put.heapSize()和KeyValue对象大小，验证了这一理论估算与测试结果高度吻合。文章最终给出实用建议：如果业务模型必须使用多列存储，在批量写入场景下，可以考虑适当调大客户端的write buffer，以缓解性能下降。

IT 累计浏览 3,142

构建高可用和弹性伸缩的KV存储系统

KV存储系统在现代高并发应用中扮演着关键角色，但经典的Memcached和Redis在运维中常面临容灾困难、数据复制效率低以及在线扩容复杂等挑战。这篇内容从这些实际痛点出发，深入分析了Redis在持久化、主从复制和集群扩展方面的局限，比如主机宕机可能导致数据丢失、全量复制影响性能，以及扩容需要人工干预等。针对这些问题，文章提出了一套新的分布式架构设计。该系统由路由、存储、管理和搬迁四类节点组成，通过一致性哈希与虚拟节点实现数据均匀分布，并利用心跳检测和自动切换机制来保障高可用。新方案不仅兼容现有协议，还实现了自动容错恢复、负载均衡和弹性伸缩，试图在保证内存级性能的同时，让运维变得更加智能和可靠。整体来看，这不仅是对现有技术的梳理，更提供了一个从架构层面系统化解决KV存储可用性与扩展性难题的思路，对从事基础架构或缓存设计的工程师有直接的参考价值。

IT 累计浏览 2,196

TokuMX使用小计

作者面对一个实际痛点：MongoDB存储运行日志时，三个月数据就占用近100G磁盘，急需更高效的存储方案。他最终选择了TokuMX——一款声称能节省90%空间并大幅提升性能的MongoDB分支。迁移过程非常直接，使用标准工具导出再导入即可。实际效果令人惊讶：原先102G的数据迁移到TokuMX后，仅占用2.2G，导入速度提升至少10倍，查询性能保持稳定。文章分析了TokuMX背后的关键技术：一是存储层的高效压缩，二是用分形树索引替代传统的B树，通过在节点内设置缓冲区并批量写入，来大幅提升写入效率。除了分享这次迁移实践与技术原理，作者还附上了官方介绍文档、第三方性能评测等参考资料，为想深入了解或尝试的读者提供了入口。

IT 累计浏览 4,818

Linux大棚版redis入门教程

这篇是面向初者的Redis全景指南，从安装启动讲起，一直深入到核心数据结构、持久化机制和生产配置。文章不止停留在“是什么”，更用大量实际命令演示了如何操作。作者将Redis的五种数据结构——字符串、列表、集合、有序集合与哈希——拆解开来，配合代码示例讲明各自的用法与底层特性。比如，他指出lists在底层是链表，因此头部尾部操作是常数时间，但随机定位较慢，并以此引出其在消息队列等场景的应用优势。在掌握基础后，教程进一步引导读者理解RDB与AOF两种持久化的原理与选择，主从同步的机制，乃至事务处理。最后对redis.conf配置文件的逐项解读，让初学者也能看懂并调整安全、性能与限制相关的参数。整个系列循序渐进，覆盖了从“跑起来”到“用得好”的关键知识点，对于希望快速上手并扎实理解Redis的新手来说，是一份非常友好的实战手册。

IT 累计浏览 4,230

从需求出发来看关系模型与非关系模型–关系模型与非关系模型概述

这篇讲的是关系模型与非关系模型的选择根源。作者从当前对 NoSQL 的盲目追捧现象切入，指出许多项目初创团队都在纠结如何选择 NoSQL，却忽略了模型本身的本质。文章的核心是帮读者理清 RDBMS、NoSQL、CAP、BASE 这些概念的本源，并用一个“车”的例子清晰地对比了层次模型和关系模型的差异。关键在于，关系模型通过集合运算抽象了数据“关系”，让用户无需像层次模型那样关心从“车”到“轮子集合”再到“具体轮子”的存取路径，只需关注查询逻辑本身，这使得它严谨且被广泛接受。然而，随着面向对象编程的普及，关系模型带来了“阻抗失配”问题——将对象中的继承、组合映射到关系表变得非常痛苦。为解决此问题，业界尝试了 ORM 工具、在数据库层支持对象，以及利用脚本语言的动态特性来简化映射。这些方案各有代价，ORM 学习成本高且易导致低效查询，而用 Map 则会破坏封装性。随着互联网发展，对高性能和灵活数据结构的需求，让层次模型的变种——NoSQL 重新受到关注。文章接下来将从具体应用场景出发，剖析关系模型在哪些地方力不从心，以及 NoSQL 为何又能满足新的需求。

IT 累计浏览 1,987

SSDB 配置文件

这篇讲的是如何理解和定制 SSDB 的配置文件。文章开篇就点明，默认附带的配置文件无需修改即可运行，但若需高度定制，了解其配置项就很有必要。配置文件本身是层级 key-value 的静态格式，通过 TAB 缩进来表示结构，一目了然。文章逐一拆解了核心配置段：`work_dir` 指定了存放数据和日志的工作目录；`server` 段控制监听的 IP 与端口，出于安全考虑，可以将 IP 绑定为仅本机访问的 `127.0.0.1`；`replication` 段用于设置主从复制，明确了从服务器如何同步数据；`logger` 段管理日志级别、输出文件以及支持的大小轮转策略。最值得关注的是 `leveldb` 段的配置。文章特别指出，`cache_size` 参数直接影响性能——适当增大缓存能提升读性能，但过大的缓存反而会拖慢写速度。这种基于实际使用场景的调优建议，对管理员来说非常实用。总的来说，这篇文章将看似枯燥的配置文件讲解得清晰明了，不仅解释了“是什么”，还点出了“为什么”和“怎么调”，无论是初次接触 SSDB 的开发者，还是需要优化部署的运维人员，都能从中快速找到自己需要的配置要点。

IT 累计浏览 1,904

数据的游戏：冰与火

这篇讲的是一位在Amazon和淘宝都有过实践的数据挖掘新人，在不到10个月里总结出的“冰与火”心得。作者开篇就点明，数据世界象征着权力与征服，但通往“王座”的道路布满荆棘。文章的核心观点很明确：他从Amazon经验中提炼出数据团队的三大角色——苦累却至关重要的数据清洗员、技术含量最高的研究科学家、以及相对次要的软件开发工程师。作者强调“Garbage In, Garbage Out”，再牛的算法也敌不过一堆垃圾数据。通过两个生动的案例，作者阐明了数据质量的重要性。一是像Amazon那样建立严格的商品ID（ASIN）作为数据标准；二是清洗海量但格式混乱、真假混杂的用户地址数据。他指出，数据不分大小，只分好坏，从80%的准确度提升到90%，所需成本远超过从60%到80%。作者进一步讨论了业务场景对数据挖掘的制约。推荐系统在音乐和电商场景下逻辑截然不同，对书籍和服装的需求预测难度也有天壤之别。他提醒，数据挖掘远非人工智能，在特定业务场景下，资深从业者的经验甚至比机器学习更准。最终，作者认为数据分析结果不能止步于统计呈现，必须能指导下一步行动。他抛出了数据挖掘中质量、场景与结果这三个关键问题，虽未给出标准答案，却为从业者揭示了被算法光环所掩盖的实践本质。

IT 累计浏览 3,176

C Mohan 讨论NoSQL的得与失

这篇文章是资深数据库专家 C Mohan 从历史演进的视角，对 NoSQL 运动兴起背景及其暴露问题的系统性梳理。他首先指出了传统关系数据库在应对 Web 2.0 时代需求时的力不从心，比如难以建模社交图谱、JSON 数据交换不便、扩展性与成本制约，以及 ACID 原则在实际业务中常需妥协等。接着，作者结合自己在 System/38、Lotus Notes 乃至 DB2 等系统上的深刻教训，揭示了数据库内核设计的复杂性，例如锁粒度、崩溃恢复、集群支持等关键环节的挑战，为理解后续问题埋下了伏笔。随后，他犀利地剖析了 NoSQL 方案普遍存在的“先天不足”：对并发控制与原子性等事务核心问题关注不够，索引设计过于简单，数据模型复杂却缺乏标准化工具，以及对分布式下一致性和可靠性的误判。文章并未全盘否定 NoSQL，而是强调无论是 MongoDB 的写锁、CouchBase 的文档复制粒度，还是对 ACID 的简化处理，都在高并发或复杂业务场景下可能遇到瓶颈。最终，这篇讨论的启发在于：技术选型需回归具体场景的本质需求，无论是追求强一致的传统企业核心系统，还是需要灵活扩展的互联网应用，理解关系数据库与 NoSQL 各自的设计哲学和代价，才能避免盲目追随潮流，做出更务实的技术决策。

IT 累计浏览 3,159

思考题：如下场景如何设计mongo collection

这篇探讨的是一个实际场景下的 MongoDB 集合设计问题：如何记录用户每次登录的业务标识、IP 及时间，并高效查询特定用户在特定业务下的某个 IP 是否已存在。作者给出了两种思路并进行了对比。方案一采用扁平结构，为每次登录记录一条独立文档，结构清晰，查询时通过 `findOne` 直接定位。方案二则将同一用户同一业务下的所有登录记录聚合到一个文档中，将 IP 和时间存储为子文档数组，这在查询特定 IP 时语法略显复杂。文章的核心矛盾点在于如何权衡查询的便捷性与应对新需求的灵活性。当需求变更为“每个用户同一业务只保留最新5条记录”时，方案一需要额外的计数与删除操作，而方案二则更利于在应用层（如 PHP）对数组进行裁剪后整体更新。作者最终选择了后者，并通过客户端脚本管理数组元素，再使用 `upsert` 操作同步回数据库。这反映了在 NoSQL 设计中，有时需要结合应用逻辑来弥补数据库层功能的不足。

IT 累计浏览 7,415

Web应用的缓存设计模式

这篇讲的是，作者如何通过一套“反直觉”的缓存设计，让一个日均300万访问的老产品重写后性能飙升。传统思路依赖动态页面静态化和数据库分库分表，但代码复杂度高，维护困难。作者的方案则彻底反转：完全放弃这些，转而深度应用ORM对象缓存。核心在于改变对数据库性能瓶颈的认知——瓶颈往往在磁盘IO，而非SQL条数。因此，ORM缓存的设计哲学是：目标是减少数据库磁盘IO，而非减少SQL。这需要配合细颗粒度的表设计，故意拆分多表关联为多条主键查询（拥抱“n+1”问题），以便高效利用缓存。文章通过一个实际案例（将千万级大表的项目迁移到单台MySQL）证明，这套方案能将数据库服务器的IO Wait降至5%以下，且代码复杂度并未显著增加。作者还具体演示了两种实现模式：利用表关联实现透明缓存，以及按列拆表实现大字段的细粒度缓存，后者本质上是SQL与NoSQL的混合架构。对于追求高性能且希望保持代码可维护性的Web应用，尤其是内容频繁更新的场景，这种以缓存为中心的设计提供了一个极具说服力的替代路径。

IT 累计浏览 3,400

几种常见的NoSQL数据库关键特性列表

这篇文章旨在帮助开发者快速把握主流NoSQL数据库的“脾气”与“专长”。作者从键值、文档、列族、图数据库等主要类型出发，没有停留在泛泛的概念介绍，而是直接列出了它们各自最核心的特性与设计哲学。比如，文章会点明Redis作为键值存储的极速缓存能力、MongoDB文档模型在处理嵌套JSON时的灵活优势，以及Cassandra在分布式架构下如何保证高可用性。对于Neo4j这样的图数据库，则会强调其在关系密集查询中远超传统数据库的性能。这种横向对比，让不同数据库解决何种场景问题变得一目了然。文章以列表形式呈现，方便读者按需查阅和快速比对。这不仅是一份特性清单，更像一张技术选型的“地图”，能帮你根据数据模型、扩展性要求及查询模式，在众多选择中找到最贴合业务需求的那把钥匙。

IT 累计浏览 3,688

一个DBA眼中的HBase

这是一位一线DBA对流行技术的冷静思考。当HBase与NoSQL的光环铺天盖地时，作者从日常运维的视角，剖析了那些光鲜宣传背后的实际挑战。文章没有复述官方特性，而是直指几个核心痛点：比如高并发写入下的性能瓶颈、复杂查询的局限性，以及运维管理的复杂度。作者结合自身经验，点明了在特定业务场景下可能出现的“水土不服”，例如强一致性要求或复杂Join查询时的尴尬。其价值不在于否定技术，而是提供了一份来自“用户现场”的平衡报告。它提醒技术决策者，选型不能只看热度，必须紧扣业务特性与团队运维能力。对于正在评估或已深陷HBase运维的团队来说，这篇来自DBA的真诚复盘，或许能帮你避开一些理想的陷阱。

IT 累计浏览 3,817

弃用NoSQL数据库 CouchDB再见了

这篇讲的是一个技术团队告别 CouchDB 的心路历程。文章从团队原有的业务场景出发，回顾了为何曾选择这款文档数据库，以及在实际生产中，特别是在 Kubernetes 云原生环境下，逐渐遇到了哪些痛点。比如，在需要强事务支持和复杂关联查询的场景下，CouchDB 基于键值存储的设计就显得力不从心，运维复杂度也随着规模增长而提升。作者没有停留在抱怨上，而是清晰地梳理了技术选型的决策过程。他们对比了包括 PostgreSQL 在内的多种方案，最终选择了更适合自身业务混合负载的云原生数据库，并详述了数据迁移与切换过程中，如何保障服务平稳过渡。结尾部分总结了从这次“数据库分手”中学到的宝贵经验，强调技术选型需要与业务发展阶段和基础设施演进紧密结合，对正在面临类似困扰的团队很有参考价值。

IT 累计浏览 2,964

NoSQL 数据建模技术

这篇译文基于"NoSQL Data Modeling Techniques"一文，作者从关系型数据库与NoSQL数据库的对比入手，深入剖析了NoSQL数据建模的核心技术。关系型数据库追求严格的一致性、完整性和高效索引，旨在通过事务保障数据的可靠性；而NoSQL则专注于高可扩展性和性能，往往在一致性方面做出妥协，以换取水平扩展和快速读写能力。关键差异体现在架构和适用场景上：关系型数据库适合复杂事务和关联查询，如金融或ERP系统；NoSQL则提供多种模型，包括键值存储（如Redis）、文档型（如MongoDB）、列族（如Cassandra）和图数据库（如Neo4j），各自针对特定需求优化。例如，键值存储擅长高速缓存和会话管理，文档数据库便于处理半结构化数据，图数据库则在社交网络分析中表现突出。文章详细讲解了每种NoSQL建模技术的实现思路和巧妙之处，比如如何通过数据分区、复制和最终一致性来平衡性能与可靠性。译者在前言中分享了个人见解，认为NoSQL由于其灵活性和低延迟特性，特别适合作为缓存层，以减轻关系型数据库的负载并提升系统响应速度。通过具体案例和对比分析，文章帮助读者

IT 累计浏览 1,473

人肉解析riak_admin join

这篇讲的是 Riak 数据库中一个常用命令 `riak_admin join` 的底层实现解析。作者没有停留在命令行使用层面，而是采用“人肉”的方式，直接追踪源码，一步步揭开这个命令背后发生了什么。他发现 `riak_admin` 本质上只是一个 bash 脚本，当执行 `join` 操作时，脚本会调用 Riak 核心的 Erlang 代码，最终路由到 `riak_kv_console` 模块的 `join` 函数来完成集群节点加入的实际工作。文章清晰地展示了从用户敲下命令到系统执行核心逻辑的完整调用链。这种深挖源码的分析，不仅让读者知其然，更知其所以然。它绕过了官方文档的简略说明，直接展示了 Riak 内部如何优雅地将命令行接口与核心业务逻辑解耦，对于想深入理解分布式数据库管理命令实现原理的工程师来说，提供了非常扎实的技术细节。

IT 累计浏览 2,973

MongoDB快速上手PHP篇

这篇讲的是用PHP操作MongoDB的入门指南，但它没有停留在语法层面，而是先厘清了MongoDB这个“主角”的定位。文章指出，MongoDB是一种介于关系型与非关系型之间的文档数据库，以类似JSON的BSON格式存储数据，这带来了灵活的Schema优势。其查询语言强大，语法接近面向对象，几乎能覆盖单表查询的大部分功能，并支持索引。作者重点对比了MongoDB与传统关系数据库（如MySQL）的核心差异。MongoDB的核心优势在于海量数据下的读取性能：根据官方数据，当数据量超过50GB，其访问速度可达MySQL的10倍以上。但文章也客观指出了它的局限：并发读写效率并非其长项，大约每秒能处理0.5万到1.5万次请求。因此，这篇快速上手文不仅介绍了PHP如何连接与操作MongoDB，更隐含了对选型的思考。它更适合那些数据结构灵活、以海量数据高效读取为主要目标，但对写入并发要求不那么极端的应用场景。

IT 累计浏览 3,310

HBase在数据统计应用中的使用心得

这篇讲的是作者团队在实际项目中使用HBase作为数据统计存储系统后的经验沉淀。他们从项目对高性能写入和灵活查询的具体需求出发，选择HBase作为底层引擎，但在落地过程中遇到了不少挑战。文章重点分享了针对统计应用特点的关键实践。例如，如何设计RowKey和预分区策略来避免热点，提升写入吞吐量；针对高频的聚合查询，如何权衡使用协处理器与客户端扫描来优化性能；以及在面对海量数据持续写入时，如何通过调整Compaction策略来平衡读写压力，保障服务稳定性。作者没有泛泛而谈，而是结合真实场景中的数据量和业务模式，给出了具体的配置思路和参数调整案例。这些心得和解决问题的路径，对于同样面临海量数据统计存储与快速查询挑战的团队，提供了可参考的踩坑记录和调优方向。

IT 累计浏览 1,672

Amazon DynamoDB详解

这篇文章带我们深入了解 Amazon 推出的新服务——DynamoDB。它并非从零开始，而是基于 Amazon 内部久经考验的 Dynamo 技术，将其封装成了一项易于使用的托管型 NoSQL 数据库服务。 DynamoDB 解决的核心问题是：如何在云端轻松构建高性能、高可用的应用程序，而无需费心管理底层基础设施。文章详细拆解了它的设计哲学，突出了其自动无缝扩展的“无上限”容量和 99.99% 的高可用性承诺，这对于需要处理不可预测流量的现代应用至关重要。不同于传统的关系型数据库，DynamoDB 采用键值或文档数据模型，提供了毫秒级的稳定延迟。这意味着，无论你的数据量和访问模式如何变化，应用的响应速度都能保持一致。这对于游戏排行榜、物联网设备日志、实时竞价等对时延敏感的场景来说，是一个非常有针对性的选择。作者不仅介绍了服务本身，也隐含地将其定位为应对海量数据场景的一种关键基础设施演进。它让开发者能更专注于业务逻辑，而将复杂的分布式系统运维难题交给了 AWS，体现了云服务“专注所长”的价值。