Oracle or MySQL ?
这篇讲的是作者在面对Oracle、MySQL乃至NoSQL等数据库产品时，如何做出选择的个人思考。文章并非聚焦于技术细节的硬核对比，而是从实际项目经验出发，探讨选型背后的决策逻辑。 背景源于现代软件开发中常见的困境：团队在数据库选择上容易陷入参数比拼的循环，却忽略了业务场景
NoSQL漫谈
这篇讲的是数据库世界里一次重要的范式转移。作者从传统关系型数据库面临的扩展性瓶颈出发，点明了NoSQL运动兴起的核心驱动力：为海量数据和高并发访问提供可水平扩展的解决方案。 文章清晰地梳理了理解NoSQL的两大基石理论。它解释了CAP定理如何迫使分布式系统在一致性、可用性和分区容错性之间做出权衡，并指出NoSQL通常优先保障后两者。接着，它阐述了BASE模型作为ACID的反面，如何通过“最终一致性”来换取系统的高可用与柔性，这是很多NoSQL产品设计的核心理念。 作者进一步根据应用场景，将纷繁的NoSQL产品划分为KV缓存、KV存储、列存储、文档存储等类型，并列举了Memcached、Cassandra、MongoDB等代表产品，点明了它们各自的适用场景。例如，Wide columnar store（如Cassandra、HBase）因其灵活的Schema和大规模扩展能力，成为处理结构化数据的重点方向。 文章并未止步于此，还深入讲解了一致性哈希、虚拟节点、Quorum机制和向量时钟等支撑分布式系统的关键技术原理。最后，通过与传统数据库在性能优化思路（存储优化vs内存优化）、Schema灵活性上的对比，再次强调了NoSQL在特定场景下的必要性。它不仅仅是在罗列概念，而是构建了一个从问题、理论到实现与选型的完整知识框架。
Cassandra数据模型
这篇讲的是从DBA视角去理解Cassandra的数据模型。作者指出，面对NoSQL浪潮，传统关系型数据库的管理员也需要了解“非关系型”的建模思路，并以BigTable类的Cassandra为例展开剖析。 文章没有泛泛而谈，而是具体拆解了Cassandra的核心概念：Keyspace（类似Oracle Schema）、Column Family（类似Table），以及Column和Super Column。关键差异在于，Cassandra拥有极灵活的Schema，每一行的列可以不同；且数据在写入时就已按照定义的列名（Column Name）类型（如UTF8Type, TimeUUIDType）排好序，读取时顺序确定，这是一个重要的性能优势。 作者用Twitter的真实Schema作为案例，生动展示了如何用这些概念建模：比如用TimeUUIDType排序的Super Column来存储用户最新的推文和关注关系，这恰好满足了社交场景按时间排序的核心需求。 最后，文章也点出了架构设计的本质是“有所取舍”，Cassandra的模型正是为了高可用和可扩展性而在一致性等方面做出了权衡，为需要处理海量结构化数据的应用提供了一种不同于关系型数据库的思考路径。
我这五年
这篇记录了一位工程师在杭州五年的技术成长轨迹。作者从自己旧博客的文字间，重新梳理了这段时间的心路历程。 文章没有聚焦特定技术问题，而是以时间线串联起个人职业发展的关键节点。从初来乍到的适应期，到项目历练中的技术沉淀，再到对行业与自身定位的思考，文中穿插着具体的技术选型争论、团队协作中的认知转变，以及几次重要的技术方向选择。这些细节让“成长”二字变得具体可感。 这种基于长期实践的第一人称复盘，其价值在于展现了技术能力提升背后更复杂的维度：如何平衡深度与广度、如何处理技术理想与工程现实、怎样在持续学习中保持节奏。对处于类似阶段的读者而言，文中那些未经修饰的纠结与突破，或许比纯粹的技术分享更具参考意义。
一种并行加载的方法
这篇讲的是数据库同步系统中一个常被忽视的环节：如何高效地完成数据加载。 通常，一个完整的同步链路包括抓取、传输和加载三部分。抓取和传输已有成熟方案，但最后的加载环节——即在目标数据库上应用成批的变更SQL——往往会成为性能瓶颈。文章从实际场景出发，聚焦于如何打破这一瓶颈。 作者提出的并行加载思路，核心在于将原本串行执行的变更应用任务，拆分并交由多个处理单元同时进行。这好比把一个长队列拆分成多个并行窗口，能显著提升整体处理吞吐量，减少数据同步的延迟。文中探讨了实现并行的关键设计，比如任务分片、依赖关系处理和并发控制，这些细节决定了方案能否真正落地并保证数据的一致性。 对于需要处理高频率、大批量数据变更的同步场景，这种并行化思路提供了明确的优化方向。它不仅仅是一种技术调整，更是从架构层面提升数据流动效率的一次思考。
Oracle排序算法
这篇讲的是Oracle数据库排序机制的一个有趣问题。作者从Jonathan Lewis在圣诞节发布的技术小测入手，揭示了Oracle在执行ORDER BY操作时，排序算法的选择并非一成不变，而是会受到数据特性、内存设置等多种因素的动态影响。 文章的核心在于剖析了Oracle内部两种主要排序方式——“直接路径排序”与“常规路径排序”——的运作原理与切换逻辑。作者通过具体的测试案例展示，当排序操作涉及的数据量、PGA内存配置达到某个临界点时，优化器会做出不同的选择，进而对查询性能产生显著影响。 一个关键发现是，排序过程中的“中间结果”可能会被以特定的压缩格式存储，这巧妙地平衡了内存消耗与I/O开销。文章的启发在于，理解数据库内核这种“因地制宜”的自适应行为，能帮助DBA更精准地诊断性能瓶颈，并在配置优化时做出更符合实际场景的决策。
用ASM和iSCSI实现的另类HA方案
这篇讲的是如何用常见组件拼出一套低成本HA方案。作者从一个现实痛点出发：普通PC没有共享存储，又不想用Dataguard（因其存在数据丢失风险且难以实现透明切换），该怎么办？ 他提出的方案核心是用iSCSI将本地磁盘共享出去，再借助Oracle ASM的failgroup功能做数据镜像，确保数据在两台机器上各有一份。同时配合Heartbeat进行故障探测，一旦主节点宕机，就在备机上拉起数据库和ASM服务。对于11g R2及以上版本，ASM的Preferred mirror read特性还能保证主库优先读本地盘，避免性能损失。 文章坦诚分析了方案的局限：Heartbeat存在误判或无法切换的可能，但这几乎是所有HA软件的通病，包括IBM HACMP。作者更强调，完善的监控和应急措施比追求完美的切换机制更实际——比如他们通过定时模拟应用来检测数据库是否hang住。 最后，作者也提醒，在11g R2之前，由于Voting Disk和OCR必须放在裸设备上，搭建RAC集群时可能会因投票盘丢失导致集群误判。而11g R2将几乎所有组件都移入ASM后，这个方案才变得真正可行。这算是一个经过验证、适合特定场景的务实选择。
Oracle hash分区的秘密
这篇讲的是Oracle hash分区的一个核心秘密：为何分区数推荐为2的次方，以及它如何在增加分区时避免全量数据迁移。作者从面试常见问题切入，剖析了Oracle的实现技巧。 关键在于，Oracle并非在运行时动态计算哈希，而是预先使用大于等于当前分区数的最小2的N次方作为“桶”的数量。例如，6个分区实际对应8个哈希桶，多余的数据被合并到现有分区中，这就造成了数据分布不均衡。当增加分区时（比如从6增至8），并非重新哈希所有数据，而是对特定分区执行split操作，将原先合并的桶数据拆分出来，其他分区的数据因此保持不变。 理解了这一点，也就明白了减少分区是merge而非drop。作者最后分享了自己项目中的务实方案：直接预分1024个分区分布到8台主机，后续扩展只需移动表和修改映射，思路异曲同工。
数据库HA方案
这篇讲的是数据库高可用（HA）方案的选型对比。作者开门见山地梳理了三种主流方案各自的优劣与适用场景。 第一种是传统的小型机双机热备。它胜在稳定，但问题也很明显：总有一台设备闲置，硬件又必须绑定IBM、HP这类大厂，导致整体利用率低且成本高昂。第二种是Oracle RAC。在Linux环境下，它能提供一整套相对完善的HA方案，被视为一个不错的选择，不过其部署的底线是必须配置一套共享存储设备。第三种是基于Oracle Data Guard的方案。它的核心优势是成本控制得最好，但短板在于无法实现故障时的透明切换。作者团队曾尝试用heartbeat工具配合DG failover来优化，但实测表明，在极端情况下，这种组合依然存在丢失数据或切换失败的可能性。 总的来说，文章清晰地权衡了硬件成本、运维复杂度、切换效率与数据安全性这几个关键维度，为不同的预算和业务要求提供了明确的决策参考。
SSD 想说爱你不容易
这篇讲的是SSD固态硬盘的性能优势与现实顾虑。文章开篇点出，SSD最耀眼的优势是极致的IO性能——单块SLC颗粒的SSD就能轻松达到数万IOPS，几块组合甚至能比肩一个大型存储阵列的吞吐能力。然而，性能光环下藏着几个核心挑战。首当其冲的是写磨损问题，虽然可以通过预留冗余空间和均衡写入算法来缓解，但这依然无法完全打消人们对于电子产品可靠性的天然疑虑，尤其是在与传统的机械硬盘（HDD）对比时。此外，对于数据库这类对稳定性要求近乎苛刻的应用场景，SSD能否经受住长期、高负载的实际考验，文中也指出了这方面的待观察状态。 归根结底，文章剖析了SSD“让人又爱又难爱”的矛盾点：它能以极低成本提供强大性能，但其耐久度和长期稳定性，仍是在关键业务系统中部署前必须审慎评估的课题。
sequential和scattered的含义
数据库性能调优中，“顺序读”和“离散读”这对术语常让人困惑。作者从这个经典矛盾出发，剖析了两个操作在逻辑层面与物理IO层面的不同含义。 在Oracle等数据库中，我们通常说的“sequential read”（顺序读）发生在索引范围扫描等场景，是单块读取；而“scattered read”（离散读）则对应全表扫描，会进行多块读取。然而，若从磁盘IO子系统的实际行为看，结论恰恰相反：单块读在物理磁盘上是离散的、寻道开销大的；而多块读反而能在物理上实现更连续的顺序IO。 这篇文章厘清了术语在上下文中的具体指向，帮助开发者和DBA准确理解监控指标（如`db file sequential read`）背后的真实IO模式，避免在优化策略上南辕北辙。
我对存储的一些认识
这篇讲的是存储系统从底层磁盘到上层配置的实用经验总结。作者从磁盘的物理结构出发，解释了IOPS主要由转速决定（如15000转盘约150 IOPS），而吞吐量则受转速和接口限制。文章特别指出了存储选购中的常见误区，比如厂商的高IOPS数据往往基于超大磁盘数量和高Cache命中率，实际项目中很难达到。 针对数据库应用，作者给出了一系列具体建议：OLTP场景下Cache命中率约20%，磁盘数量需据此估算，且单盘IOPS不宜超过100；对性能要求高的场景应优选RAID10，避免将Redo日志放在RAID5上。关于Stripe条带化，文章澄清了一个常见误解——一个IO不会由所有磁盘同时响应，条带大小建议不小于256K，Oracle ASM默认的1M经实测性能更优。 最后，在存储划分部分，作者通过图示说明了如何结合LVM和Stripe让负载更均匀地分布到所有磁盘。全文贯穿了一个核心观点：理解底层原理才能避免被厂商的营销话术误导，做出真正适合自身应用的设计。对于需要规划或优化存储系统的读者来说，这些源于实践的经验总结很有参考价值。
Oracle ASM存储方式浅析
作者从ASM最小的分配单元AU讲起，解释了它如何将磁盘切分为1M到64M不等的块，并进一步通过“可变大小文件扩展”机制，将多个AU组织成逻辑上的文件容器。这些概念构成了ASM存储管理的基础。 文章的核心在于剖析ASM独特的“先镜像后条带”机制。与传统RAID组固定磁盘的做法不同，ASM在AU级别进行跨磁盘的镜像和条带化，更像高级存储的虚拟化方式。这使得ASM不仅能实现动态负载迁移，其镜像方式也介于RAID 10与01之间——它确保镜像数据不在同一磁盘，但又不完全等同于传统的磁盘组RAID。此外，针对不同文件，ASM还采用了Fine（128K）与Coarse（与AU大小相同）两种条带宽度。 最后，文章指出ASM实质上是一个存储管理软件，它在底层维护着从AU、文件扩展到Oracle逻辑区之间复杂的映射关系，从而将物理存储抽象化，为数据库提供了灵活、高效的存储服务。
Oracle RAC廉价数据仓库解决方案
这篇文章从Oracle RAC的特性出发，探讨了其在数据仓库与OLTP场景下的不同适用性，并提出了一个极具实践价值的低成本架构构想。 作者首先指出，RAC在OLTP系统中因缓存融合（Cache Fusion）开销过大，节点数通常受限，更多是用于高可用（HA）；而数据仓库任务独立、以并行计算为主，能充分发挥RAC多节点并行处理的优势，理论上可实现线性扩展。然而，RAC的性能天花板往往在于共享存储的IO吞吐量。 为此，文章提出一个大胆的解决方案：使用多台廉价的PC服务器作为存储节点，通过iSCSI协议对外提供块存储，再用Oracle ASM将其整合为共享存储池。ASM可以跨节点做条带化（Stripe）和镜像（Mirror），将IO分散到所有存储节点，并通过故障组（Failgroup）保障数据冗余，从而构建一个可随需求扩展、成本可控的存储底层。 作者提到，这套架构虽然未经实际测试，但思路清晰地解决了传统RAC存储扩展成本高的痛点。对于计划搭建大规模数据仓库，同时又对传统存储阵列成本敏感的团队来说，这个“PC服务器堆存储”的构想提供了一个值得评估的备选路径。
Greenplum技术浅析
作者从一次用廉价PC+Greenplum搭建环境、性能却超越昂贵存储和Oracle RAC的亲身体验出发，剖析了Greenplum在数据仓库场景下“神奇”性能的底层逻辑。 其核心在于Shared Nothing的MPP架构：数据通过Hash均匀分布到各节点，查询时所有节点并行计算，Master仅负责调度，从而将吞吐能力与并行计算能力发挥到极致。文章具体解释了数据装载、Join操作（特别是涉及非分布键时的Redistribute过程）如何充分利用这一架构实现高效并行。 然而，作者也冷静指出，Greenplum的“神奇”源于场景匹配，其技术本身并非独有——Oracle RAC通过分区等技术也能实现类似并行。真正的启示在于：没有解决一切问题的万能技术，选型需基于场景，不应被厂商的性能数据遮蔽判断。技术的价值，终究要看它是否恰好落在了最能发挥其长处的土壤里。