Databases Reference
In-Depth Information
Membase —
As far as key/value in-memory, with the option to persist to disk data stores
go, Redis has been the example of choice so far. Many Redis features and internals have
been illustrated through multiple chapters. This chapter steps out of the Redis umbrella
to cover a competing product, Membase. Membase has gained popularity because its
performance characteristics are notable and adoption of the Memcached protocol makes it a
drop-in replacement for Memcached.
Hypertable —
As far as sorted ordered column-family stores go, much has been covered
with HBase in mind. Although HBase is a popular Google Bigtable clone, a couple of
alternatives are built on the same model. The alternatives are Hypertable and Cloudata.
Cloudata is the newest of the open-source options but Hypertable is a well-established
player. Hypertable is deployed as a scalable data store for many large Internet applications
and services. Hypertable is written in C++ and provides superior performance metrics as
compared to HBase. So I cover a few aspects of Hypertable in this chapter.
➤
➤
Apache Cassandra
— Google Bigtable and Amazon Dynamo are the two popular blueprints
for architecting large-scale NoSQL stores. Apache Cassandra tries to bring together
the ideas from both products. Apache Cassandra has been much talked about and its fast
writes have created enough excitement. The chapter covers some bits of what Cassandra is
made up of.
Berkeley DB —
Berkeley DB is a powerful key/value store that forms the underlying
storage of leading NoSQL products like Amazon Dynamo, LinkedIn, Voldemort, and
GenieDB.
➤
➤
The coverage of the topics in this chapter is by no means exhaustive or uniform across
products. However, the chapter provides enough information to pique your curiosity to explore
the internals further, to unwrap the underlying code of these products, to use these products
gainfully, and to possibly contribute to making these products better. In addition, the chapter may
also inspire you to explore the internals of other NoSQL products. Some of these other NoSQL
products may have been mentioned only in passing in this topic. Even others may not even have
been mentioned.
MONGODB INTERNALS
Many MongoDB commands and usage patterns have been covered in the topic so far. Storage
and querying mechanisms have been explored and the topic of replication has been touched upon.
A few details about the wire format, BSON, have also been introduced. This section illustrates
a few important additional aspects of MongoDB. The illustration builds on top of what you
already know.
MongoDB follows client-server architecture, commonly found in traditional RDBMSs.
Client-server architecture involves a single server and multiple clients connecting to the server. In
a sharded and replicated scenario, multiple servers — instead of only one — form the topology.
In a standalone mode or in a clustered and sharded topology, data is transported from client to
server and back, and among the nodes.
