HBase, MapR, sharding, NoSQL databases and Amazon S3.
This chapter completes the frameworks part of Unit V. It covers HBase for real-time access to big tables, the MapR distribution, sharding as the main way databases scale out, the families of NoSQL databases, and Amazon S3 cloud object storage. Each topic has a worked numerical example.
12.1 HBase
Apache HBase is a distributed, scalable, column-family-oriented NoSQL database that runs on top of HDFS and is modelled on Google's Bigtable. Where HDFS and MapReduce are designed for batch processing of whole files, HBase provides random, real-time read and write access to individual rows in tables with billions of rows and millions of columns. Its data model is a sparse, sorted, multi-dimensional map. A table contains rows, each identified by a unique row key; rows are stored in sorted order of their keys. Columns are grouped into column families declared when the table is created (for example info and orders), and within a family any number of column qualifiers can be added on the fly. Each cell, identified by (row key, family:qualifier, timestamp), stores a value, and several timestamped versions can be kept. Empty cells take no space, so the table can be very sparse. Architecturally, a table is split by row-key range into regions, which are served by RegionServers; the HMaster assigns regions and handles administration; and ZooKeeper coordinates the cluster. On a write, the change is first recorded in a write-ahead log (WAL) for recovery and then in an in-memory MemStore, which is flushed to immutable HFiles in HDFS when full. HBase offers strong consistency for single-row operations and is used for time-series data, messaging, user profiles and online lookups.
Example rows in a customers table:
| Row key | info:name | info:city | orders:2026-03-01 | orders:2026-03-15 |
|---|---|---|---|---|
| C1045 | Asha | Lucknow | ₹1,200 | ₹850 |
| C1046 | Ravi | Kanpur | — | ₹2,300 |
C1046 has no value for orders:2026-03-01, and that empty cell occupies no storage.
Worked example – regions and row-key design.
- A 1 TB table with a maximum region size of 10 GB is split into 1,000 / 10 = 100 regions; on 10 RegionServers each serves about 10 regions.
- If row keys are timestamps, all new writes go to the last region, so one RegionServer is overloaded (hot-spotting).
- Salting fixes this: prefix each key with hash(key) mod 10, e.g. "7_20260315120000", so writes spread over 10 key ranges and therefore across up to 10 RegionServers — roughly a 10× increase in write throughput.
12.2 MapR
MapR was a commercial distribution of Hadoop and related tools, developed by MapR Technologies, which re-engineered the storage layer for higher performance and easier use. Its key component was MapR-FS (later MapR XD), a file system that replaced HDFS while remaining compatible with the HDFS API. Unlike HDFS, MapR-FS supports random read and write (not only append), can be mounted through standard NFS and POSIX interfaces so ordinary tools can use it, and distributes its metadata across the cluster instead of keeping it all in a single NameNode, which removes the NameNode as a bottleneck and single point of failure. MapR also offered consistent snapshots, mirroring between clusters, MapR-DB (a NoSQL database with an HBase-compatible API and JSON document support) and MapR Event Streams (a messaging system with the Kafka API) in one converged platform. Hewlett Packard Enterprise acquired MapR's business in 2019, and the technology continues as the HPE Ezmeral Data Fabric.
| Basis | Apache Hadoop (HDFS) | MapR (MapR-FS) |
|---|---|---|
| Metadata | Central NameNode | Distributed across nodes |
| File writes | Write-once, append only | Random read and write |
| Access | HDFS API | HDFS API, NFS, POSIX |
| Extras | Separate projects (HBase, Kafka) | Built-in database and streams |
| Licence | Open source | Commercial (free community edition) |
Worked example – the NameNode memory limit that MapR avoids. A common rule of thumb is that each file, directory and block object uses about 150 bytes of NameNode memory.
- 100 million small files, each one block: 2 objects per file → 200 million × 150 bytes = 30 GB of NameNode heap — large but possible.
- 1 billion such files → 2 billion × 150 bytes = 300 GB of heap on one machine — impractical, and all of it is at risk if that machine fails without a standby.
- MapR spreads this metadata across all nodes; with 50 nodes each holds roughly 300 / 50 = 6 GB, so the number of files can grow with the cluster.
12.3 Sharding
Sharding is horizontal partitioning of a database: the rows of a large table are divided among several independent servers called shards, each holding a subset of the rows and all of their columns. It is the main way databases scale out, because both storage and query load are spread over many machines. The column used to decide where a row goes is the shard key, and choosing it well is critical. Range sharding assigns contiguous key ranges to each shard (customers A–H on shard 1, I–P on shard 2, and so on); range queries are efficient, but popular ranges can become hotspots. Hash sharding assigns each row to shard hash(key) mod N, which spreads data evenly but makes range queries touch every shard. Directory-based (lookup-table) and geographic sharding place rows according to an explicit map or the user's region. Sharding brings challenges: queries and joins across shards are slow, transactions across shards are hard, and rebalancing is needed when shards are added. Consistent hashing reduces rebalancing by placing both shards and keys on a hash ring and assigning each key to the next shard clockwise, so adding a shard moves only about 1/N of the keys. Sharding is built into MongoDB (with mongos routers, config servers and shards that hold chunks), Cassandra, HBase (regions), Elasticsearch and many cloud databases.
Worked example – why plain modulo hashing makes rebalancing expensive. Keys 1 to 20 are spread over 4 shards by key mod 4. A fifth shard is added, and keys are re-placed by key mod 5.
- A key stays on the same shard only if key mod 4 = key mod 5. Among 1–20 this holds only for keys 1, 2, 3 and 20.
- Keys that stay = 4 of 20 = 20%; keys that must move = 16 of 20 = 80%.
- With consistent hashing, the new shard takes over only part of the ring — about 1/5 of the keys, so about 4 keys (20%) move and 80% stay. On a database of a billion rows, that is the difference between moving 800 million rows and 200 million.
12.4 NoSQL databases
NoSQL ("not only SQL") databases are non-relational databases designed for very large, fast-changing and varied data and for horizontal scaling across many servers. Relational databases use fixed schemas, joins and strict ACID transactions, which become hard to scale across many machines. NoSQL databases relax some of these features in exchange for scalability, availability and flexible schemas. They fall into four main types. Key–value stores (Redis, Amazon DynamoDB, Riak) store each value under a unique key and are extremely fast for lookups — ideal for caches and sessions. Document stores (MongoDB, CouchDB) store semi-structured documents such as JSON, which can vary from one record to the next and can be queried by their fields — ideal for content and catalogues. Column-family stores (Cassandra, HBase) store data in rows with flexible column families, optimised for very large write-heavy and time-series workloads. Graph databases (Neo4j, Amazon Neptune) store nodes and relationships directly and are ideal for social networks, recommendations and fraud rings. Distributed NoSQL design is governed by the CAP theorem: when a network Partition occurs, a distributed system must choose between Consistency (every read sees the latest write) and Availability (every request gets a response). Many NoSQL systems follow BASE — Basically Available, Soft state, Eventually consistent — rather than the relational ACID properties (Atomicity, Consistency, Isolation, Durability). Systems such as Cassandra and DynamoDB let the user tune consistency with quorums: with N replicas, a write waits for W acknowledgements and a read queries R replicas, and if R + W > N every read overlaps the latest write.
| Type | Data model | Examples | Typical use |
|---|---|---|---|
| Key–value | Key → opaque value | Redis, DynamoDB | Caching, sessions, shopping carts |
| Document | JSON/BSON documents | MongoDB, CouchDB | Catalogues, content, user profiles |
| Column-family | Rows with column families | Cassandra, HBase | Time series, logs, IoT, messaging |
| Graph | Nodes and edges | Neo4j, Neptune | Social networks, recommendations |
Worked example – tuning consistency with quorums. Each data item is stored on N = 3 replicas.
- W = 2, R = 2: R + W = 4 > 3, so every read set overlaps every write set in at least one replica — strongly consistent reads, and the system tolerates one replica being down for both reads and writes.
- W = 1, R = 1: R + W = 2 ≤ 3, so a read may hit a replica that has not yet received the latest write — eventually consistent, but fastest.
- W = 3, R = 1: R + W = 4 > 3 — consistent reads at the cost of writes failing if any one replica is down. Choosing W and R lets each application pick its own point on the consistency–availability trade-off.
12.5 Amazon S3
Amazon S3 (Simple Storage Service) is a cloud object storage service from Amazon Web Services. Instead of files in a directory tree or blocks on a disk, S3 stores objects — the data plus its metadata — inside buckets, and each object is identified by a unique key (for example sales/2026/03/15/part-0001.parquet), which looks like a path but is really just a name. A single object can be up to 5 TB in size, and large uploads are split into parts with multipart upload. S3 is designed for 99.999999999% ("eleven nines") durability, achieved by storing data redundantly across multiple devices and facilities, and since December 2020 it provides strong read-after-write consistency. Data can be kept in different storage classes to balance cost and access speed — S3 Standard for frequently accessed data, Intelligent-Tiering, Standard-Infrequent Access, One Zone-IA, and the Glacier classes for archives — and lifecycle rules move objects between classes automatically. S3 also provides versioning, encryption, fine-grained access policies and event notifications. Because storage is separated from computing, S3 has become the standard foundation of cloud data lakes: Spark, Hadoop (through the s3a:// connector), Amazon EMR and Amazon Athena can all process data in S3 directly, and clusters can be started and stopped without losing data.
| Basis | HDFS | Amazon S3 |
|---|---|---|
| Type | Distributed file system | Object storage service |
| Managed by | Your own cluster | AWS (fully managed) |
| Storage and compute | Coupled on the same nodes | Separate; scale independently |
| Durability | 3 replicas within the cluster | Designed for 11 nines across facilities |
| Data locality | Yes — compute runs where data is | No — data is read over the network |
| Cost model | Buy and run hardware | Pay per GB stored and per request |
Worked example 1 – what eleven nines means. Durability of 99.999999999% means an expected annual loss rate of 0.000000001% = 10⁻¹¹ per object.
- Storing 10,000,000 objects: expected objects lost per year = 10,000,000 × 10⁻¹¹ = 0.0001.
- So on average one object would be lost every 1 / 0.0001 = 10,000 years.
Worked example 2 – multipart upload. A 5 GB file is uploaded in 100 MB parts.
- Number of parts = 5,000 MB / 100 MB = 50 parts.
- Uploading 4 parts in parallel at 10 MB/s each gives 40 MB/s, so the upload takes 5,000 / 40 = 125 s instead of 500 s on a single stream.
- If one part fails, only that 100 MB part is re-sent, not the whole 5 GB file.
Independent study notes written in my own words, for learning purposes. Not affiliated with any university or course provider. R, RStudio, Hadoop, Amazon S3, Tableau, Power BI and other product names are trademarks of their respective owners.