Why architecture matters here
MOB matters because it solves the specific, serious problem of medium objects wrecking HBase's LSM compaction -- enabling HBase to store medium objects (images, documents) efficiently without the crippling write amplification they'd otherwise cause. HBase is great for small cells but struggles with medium objects (100KB-10MB) in the normal path: they bloat the store files and cause severe write amplification (every compaction rewriting the medium objects -- so they're rewritten many times, wasting I/O -- a serious performance problem, since compaction I/O is already a concern, and medium objects multiply it). For workloads that need to store medium objects in HBase (images, thumbnails, documents alongside other data), this write amplification would make it impractical. MOB solves it (separating the medium objects from the main compaction -- so they're not repeatedly rewritten) -- enabling HBase to store medium objects efficiently (without the write amplification). For HBase workloads involving medium objects (a real use case -- e.g., storing product images with product data), MOB is the feature that makes it practical, and understanding it (the problem it solves, its niche) is understanding how to store objects in HBase well.
The separate-from-main-compaction insight is the architectural crux, and it's what avoids the write amplification. The core problem with medium objects in the normal LSM path is compaction: HBase's compaction (merging store files -- necessary for read performance and reclamation) rewrites all the data it merges -- and if medium objects are in the store files, each compaction rewrites them (along with the small cells). Since compaction happens repeatedly (to manage the LSM), a medium object gets rewritten many times over its life (write amplification -- proportional to the number of compactions it goes through) -- and medium objects are large, so rewriting them repeatedly wastes enormous I/O. MOB's insight is to keep the medium objects out of the main compaction: store them in separate MOB files (not the normal store files -- so the normal compaction doesn't touch them), and give the MOB files their own compaction lifecycle (MOB compaction -- much less frequent, since MOB files don't need the frequent compaction the small-cell store files do). So the medium objects are written once to a MOB file (and only occasionally rewritten by the infrequent MOB compaction) -- not repeatedly rewritten by every normal compaction (the write amplification avoided). This separation (medium objects in MOB files with a decoupled, infrequent compaction -- not in the main frequent compaction) is the crux of MOB (avoiding the write amplification by keeping medium objects out of the frequent compaction path). Understanding the separate-from-main-compaction design (decoupling the medium objects' storage and compaction from the main LSM) is understanding how MOB avoids the write amplification.
And the medium-object-niche reality is crucial to using MOB correctly, because MOB is for a specific size range, not a general blob solution. MOB is specifically for medium objects -- roughly 100KB to 10MB. This niche matters at both ends. Below the range (small cells -- under ~100KB), HBase handles them natively (the normal path -- small cells don't cause the write-amplification problem, so they don't need MOB; using MOB for small cells adds unnecessary overhead). Above the range (large/huge objects -- tens of MB and up), MOB isn't the right tool either (huge objects belong in a dedicated blob store -- S3/object storage -- or HDFS directly, with a reference in HBase; MOB is designed for medium, not huge, objects -- huge objects would strain even the MOB machinery). So MOB fills a specific niche: medium objects (too big for the normal HBase path -- write amplification -- but not so big they belong in a dedicated blob store). Using MOB correctly means using it for this niche (medium objects) and using the right tool for other sizes (native HBase for small cells, external blob store/HDFS for huge objects). This niche awareness (MOB for medium objects, not small or huge) is crucial to using MOB correctly (applying it where it fits, not misusing it for the wrong sizes). Understanding the medium-object niche (MOB's specific size range, with other tools for small and huge) is understanding how to use MOB appropriately.
The architecture: every piece explained
Top row: the problem and mechanism. The problem: medium objects (100KB-10MB) hurt the LSM -- bloating store files and causing severe write amplification in compaction (repeatedly rewritten). MOB storage: medium objects stored in separate MOB files (not the normal store files) -- separating them from the main path. Decoupled compaction: the MOB files have their own, infrequent compaction lifecycle (not the main frequent compaction) -- so the medium objects aren't repeatedly rewritten (avoiding the write amplification). Reference in cells: the cell holds a reference (a pointer to the MOB file) instead of the value -- so the normal store files hold small references, not the large objects.
Middle row: mechanics and comparison. Size threshold: the threshold determining when a value is treated as MOB (values above the threshold -- e.g., 100KB -- go to MOB storage; smaller values stay in the normal path) -- configurable. MOB compaction: the separate compaction of MOB files (infrequent -- managing the MOB files, e.g., merging small MOB files -- but far less often than the main compaction) -- the decoupled lifecycle. Read path: resolving the reference (a read of a MOB cell gets the reference from the normal path, then follows it to fetch the object from the MOB file) -- a slight indirection. vs external store + HDFS: alternatives to MOB -- storing the objects in an external blob store (S3) with a reference in HBase, or directly in HDFS -- vs MOB (keeping the objects in HBase -- integrated access/consistency/security, at the cost of the MOB machinery) -- trade-offs (MOB for integration, external for huge objects/decoupling).
Bottom rows: application and limits. Use cases: MOB's use cases -- storing medium objects alongside other data in HBase (images, thumbnails, small documents, PDFs -- e.g., product images with product data) -- the object-bearing HBase workloads MOB enables. Size limits: MOB is for medium objects (not small cells -- native HBase; not huge objects -- blob store/HDFS) -- the size niche. The ops strip: threshold (configuring the MOB size threshold -- when a value becomes MOB -- set to capture the medium objects that would cause write amplification, while keeping small cells in the normal path), MOB compaction (managing the MOB compaction -- the separate, infrequent compaction of MOB files -- and its scheduling), and monitoring (monitoring the MOB storage -- MOB file counts/sizes, MOB compaction, and the read path -- for health and performance).
End-to-end flow
Trace storing and reading a medium object with MOB. A table stores product data, including product images (say 500KB each -- medium objects). Without MOB, the images would be in the normal store files -- causing severe write amplification (every compaction rewriting the 500KB images along with the small product-data cells -- the images rewritten many times, wasting I/O). With MOB (the size threshold set to, say, 100KB -- so the 500KB images are MOB): when an image is written, it's stored in a separate MOB file (not the normal store files), and the cell holds a reference (a pointer to the MOB file). The normal store files hold only the small references (and the small product-data cells) -- not the large images. So the normal compaction (frequent) rewrites only the small references and cells (not the large images -- they're in the MOB files, with their own infrequent compaction) -- avoiding the write amplification (the images not repeatedly rewritten). A read of the image: the read gets the reference from the normal path, then follows it to fetch the image from the MOB file (a slight indirection) -- returning the image. The MOB storage (images in MOB files, references in cells, decoupled compaction) stored the medium images efficiently (without the write amplification) -- enabling the image-bearing HBase workload.
The write-amplification and niche vignettes show the value and boundaries. A write-amplification case: the team measures the impact -- without MOB, the compaction I/O was enormous (dominated by rewriting the images repeatedly -- the write amplification); with MOB, the compaction I/O dropped dramatically (the normal compaction now handling only the small references/cells -- the images out of the frequent compaction) -- the MOB avoiding the write amplification, dramatically reducing the compaction I/O. The MOB solved the write-amplification problem. A niche case: the team correctly scopes MOB -- using it for the medium images (500KB -- the write-amplification niche), keeping small cells (the product data -- under the threshold) in the normal path (no MOB overhead for them), and for a different use case with huge objects (say, large videos -- tens of MB or more), using an external blob store (S3 with a reference in HBase -- not MOB, since MOB is for medium, not huge, objects) -- applying MOB to its niche and the right tools elsewhere.
The threshold and comparison vignettes complete it. A threshold case: the team tunes the MOB size threshold -- set to capture the medium objects causing write amplification (the images -- above 100KB become MOB) while keeping the small cells in the normal path (below 100KB -- no MOB overhead) -- the threshold balancing (capturing the problematic medium objects without MOB-ifying small cells unnecessarily). A comparison case: the team chose MOB (keeping the medium images in HBase -- integrated with the product data -- same access, consistency, security) over an external store (which would decouple the images from HBase -- separate access/consistency) -- because the integration (images in HBase with the data) was valuable for their use case; for huge objects, they'd use the external store (MOB not fitting huge objects). The consolidated discipline the team documents: use MOB for medium objects (100KB-10MB -- images, documents) in HBase (avoiding the write amplification they'd cause in the normal LSM path), understand the mechanism (medium objects in separate MOB files with decoupled infrequent compaction, references in cells -- keeping them out of the frequent main compaction), scope MOB to its niche (medium objects -- native HBase for small cells, external blob store/HDFS for huge objects), tune the size threshold (capturing the problematic medium objects without MOB-ifying small cells), manage the MOB compaction (the separate infrequent lifecycle), consider the alternatives (external store/HDFS for huge objects or when decoupling is preferred), and monitor the MOB storage -- because MOB solves the specific problem of medium objects wrecking HBase's compaction (write amplification), enabling HBase to store medium objects efficiently by separating them from the main LSM path, within its specific medium-object size niche.