Data-Structures on IT Comparison

B-Tree vs LSM Tree: In-Place Updates vs Log-Structured Merges

Sun, 06 Sep 2026 09:42:56 +0900

Overview

B-Trees and LSM Trees are the two dominant on-disk index structures used by databases, and they diverge on how they handle writes. A B-Tree performs in-place updates on a balanced page structure to keep reads fast, while an LSM Tree buffers writes in memory and reconciles them later through background compaction, trading read simplicity for write throughput.

Comparison Diagram

Comparison Table

Aspect	B-Tree	LSM Tree
Write path	Traverses the tree to locate the target page and updates it in place, splitting nodes as needed	Appends the entry to an in-memory memtable plus a write-ahead log; no seek to the record’s final location
Read path	Single root-to-leaf traversal, O(log n) page reads from one location	Checks the memtable then potentially multiple SSTables across levels, often aided by bloom filters
Update/Delete handling	Overwrites the existing value directly at its page	Writes a new version or a tombstone; the old entry is only removed later during compaction
On-disk structure	One mutable, balanced tree of fixed-size pages, always sorted	Immutable sorted SSTable files organized into levels of increasing size
Background maintenance	Node splits and merges happen incrementally as part of each write	Periodic compaction merges SSTables across levels and drops stale versions
Write amplification	Low to moderate; occasional page rewrites and splits	Higher; the same record can be rewritten multiple times as it moves through levels
Read amplification & space reclaim	Minimal read amplification; deleted space is reclaimed immediately	Higher read amplification from scanning multiple levels; space reclaimed only after compaction
Range scans	Efficient via sorted leaf pages linked in order	Efficient within a level but requires merging sorted runs across levels

Key Differences

A B-Tree updates data in place, while an LSM Tree defers changes through append-only writes to a memtable
LSM Trees gain higher write throughput by avoiding random disk seeks, at the cost of ongoing compaction
B-Trees give more predictable read latency since each key lives in exactly one place
LSM read and space overhead comes from having to consult multiple SSTable levels
Deletes in an LSM Tree are recorded as tombstones rather than removed immediately

When to Use Each

B-Tree

Recursion vs Iteration: Two Ways to Repeat Work

Sun, 02 Aug 2026 23:45:29 +0900

Overview

Both techniques repeat a computation until some condition is met, but they do it through fundamentally different mechanisms. Recursion repeats by having a function call itself on the call stack, while iteration repeats by looping over the same stack frame. The choice affects memory usage, readability, and how deep a computation can safely go.

Comparison Diagram

Comparison Table

Aspect	Recursion	Iteration
Core mechanism	Function calls itself with a smaller subproblem	Explicit loop (for/while) repeats a block of code
Termination condition	A base case stops further calls	A loop condition evaluates to false
State storage	Held implicitly in parameters and locals of each stack frame	Held explicitly in variables updated each pass
Memory usage	O(n) call stack space, one new frame per call	O(1) auxiliary space, the same frame is reused
Failure mode	Stack overflow on deep or unbounded recursion	Infinite loop if the condition never turns false
Performance overhead	Function-call overhead per level unless tail-call optimized	No call overhead, just a branch/jump back
Best-fit problems	Tree/graph traversal, divide-and-conquer, backtracking	Linear, bounded repetition like counting or array scans

Key Differences

Recursion breaks a problem into self-similar subcalls; iteration repeats a block via an explicit loop.
Recursion grows the call stack by one frame per call; iteration reuses a single frame.
Deep recursion risks stack overflow, while iteration’s main failure mode is an infinite loop.
Some languages apply tail-call optimization to turn tail recursion into iteration under the hood.
Recursion maps naturally onto trees and graphs; iteration suits flat, bounded repetition.

When to Use Each

Recursion

BFS vs DFS: Traversal Order and Data Structure

Sun, 02 Aug 2026 23:44:09 +0900

Overview

Both are algorithms for visiting every node in a tree or graph, but they differ in which node they explore next. BFS spreads outward level by level using a queue, while DFS plunges down one path as far as possible before backtracking, using a stack.

Comparison Diagram

Comparison Table

Aspect	BFS	DFS
Underlying structure	Queue (FIFO)	Stack (FILO), often via recursion
Traversal pattern	Explores all neighbors at current depth before going deeper	Follows one branch to its end before backtracking
Order nodes are visited	Level by level (breadth-first)	Branch by branch (depth-first)
Memory usage	O(width) — can be large for wide/bushy graphs	O(depth) — can be large for deep graphs
Shortest path guarantee	Yes, on unweighted graphs (first visit = shortest path)	No, may find a longer path first
Implementation style	Iterative with explicit queue	Recursive, or iterative with explicit stack
Risk of infinite loop	Low with visited-set on cyclic graphs	Higher on cyclic graphs without visited-set, or infinite depth
Typical use cases	Shortest path, level-order processing, web crawling by hops	Topological sort, cycle detection, maze/backtracking problems

Key Differences

BFS uses a queue and expands outward level by level, while DFS uses a stack (or recursion) and dives deep before backtracking.
BFS guarantees the shortest path on unweighted graphs; DFS does not.
BFS memory cost scales with graph width, while DFS memory cost scales with graph depth.
DFS naturally supports backtracking algorithms like maze solving and topological sort.
Both require a visited set to avoid infinite loops on cyclic graphs.

When to Use Each

BFS

Two Pointers vs Sliding Window: Choosing the Right Array Scanning Technique

Sun, 02 Aug 2026 23:43:16 +0900

Overview

Two Pointers and Sliding Window are both O(n) techniques for scanning arrays or strings, but they solve different shapes of problems: Two Pointers tracks two independent indices that move toward, away from, or alongside each other, while Sliding Window maintains a contiguous subrange that expands and contracts as it scans. Picking the wrong one usually means either overcomplicating a pair-search problem or missing the running aggregate a window naturally provides.

Comparison Diagram

Comparison Table

Aspect	Two Pointers	Sliding Window
Core mechanism	Two independent indices scan or converge across the data	Two indices (left/right) define a contiguous range that grows and shrinks
Pointer movement	Move toward each other, away, or in lockstep at a fixed offset	Right pointer expands the range forward, left pointer contracts it
Input requirement	Usually needs sorted data or a paired structure	Works on any unsorted array or string
State tracked	Just the two positions and the values being compared	A running aggregate of window contents (sum, count, frequency map)
Problem signature	Pair-sum, palindrome check, merging two sorted arrays	Longest/shortest substring or max/min sum under a constraint
Relationship between pointers	No notion of a range between them, only the two positions matter	The range between the pointers IS the answer candidate
Time and space complexity	O(n) time, O(1) space	O(n) time, O(1) to O(k) space for the aggregate
Failure mode	Breaks if data isn’t sorted or orderable for the comparison	Breaks if the target condition isn’t monotonic, so the window can’t shrink safely

Key Differences

Two Pointers tracks two independent indices; Sliding Window tracks a contiguous range between them.
Two Pointers typically requires sorted input; Sliding Window works fine on unsorted sequences.
Sliding Window maintains a running aggregate as it moves; Two Pointers usually just compares individual values.
Sliding Window breaks down when the target condition isn’t monotonic, since the window can’t be safely shrunk.

When to Use Each

Two Pointers