| Machi
| HadoopFS (HDFS)
|
| Not POSIX compliant
| Not POSIX compliant
|
| Immutable file store with append-only semantics (simplifying
things a little bit).
| Immutable file store with append-only semantics
|
| File data may be read concurrently while file is being actively
appended to.
| File must be closed before a client can read it.
|
| No concept (yet) of users or authentication (though the initial
supported release will support basic user + password authentication).
Machi will probably never natively support directories or ACLs.
| Has concepts of users, directories, and ACLs.
|
| Machi does not allow clients to name their own files or to specify data
placement/offset within a file.
| While not POSIX compliant, HDFS allows a fairly flexible API for
managing file names and file writing position within a file (during a
file's writable phase).
|
| Does not have any file distribution/partitioning/sharding across
Machi clusters: in a single Machi cluster, all files are replicated by
all servers in the cluster. The "cluster of clusters" concept is used
to distribute/partition/shard files across multiple Machi clusters.
| File distribution/partitioning/sharding is performed
automatically by the HDFS "name node".
|
| Machi requires no central "name node" for single cluster use.
Machi requires no central "name node" for "cluster of clusters" use
| Requires a single "namenode" server to maintain file system contents
and file content mapping. (May be deployed with a "secondary
namenode" to reduce unavailability when the primary namenode fails.)
|
| Machi uses Chain Replication to manage all file replicas.
| The HDFS name node uses an ad hoc mechanism for replicating file
contents. The HDFS file system metadata (file names, file block(s)
locations, ACLs, etc.) is stored by the name node in the local file
system and is replicated to any secondary namenode using snapshots.
|
| Machi replicates files *N* ways where *N* is the length of the
Chain Replication chain. Typically, *N=2*, but this is configurable.
| HDFS typical replicates file contents *N=3* ways, but this is
configurable.
|
| All Machi file data is protected by SHA-1 checksums generated by
the client prior to writing by Machi servers.
| Optional file checksum protection may be implemented on the
server side.
|
| Machi
| Kafka
|
| Append-only, strongly consistent file store only
| Append-only, strongly consistent log file store + additional
services: for example, producer topics & sharding, consumer groups &
failover, etc.
|
| Not yet code complete nor "battle tested" in large production
environments.
| "Battle tested" in large production environments.
|
| All Machi file data is protected by SHA-1 checksums generated by
the client prior to writing by Machi servers.
| Each log entry is protected by a 32 bit CRC checksum.
|
In theory, it should be "quite straightforward" to remove these parts
of Kafka's code base:
* local file system I/O for all topic/partition/log files
* leader/follower file replication, ISR ("In Sync Replica") state
management, and related log file replication logic
... and replace those parts with Machi client API calls. Those parts
of Kafka are what Machi has been designed to do from the very
beginning.
See also:
| Machi
| CORFU
|
| Writes & reads may be on byte boundaries
| Wries & reads must be on page boundaries, e.g. 4 or 8 KBytes, to
align with server storage based on flash NVRAM/solid state disk (SSD).
|
| Provides multiple "logs", where each log has a name and is
appended to & read from like a file. A read operation requires a 3-tuple:
file name, starting byte offset, number of bytes.
| Provides a single "log". A read operation requires only a
1-tuple: the log page number. (A protocol option exists to
request multiple pages in a single read query?)
|
| Offers service in either strongly consistent mode or eventually
consistent mode.
| Offers service in strongly consistent mode.
|
| May be deployed on solid state disk (SSD) or Winchester hard disks.
| Designed for use with solid state disk (SSD) but can also be used
with Winchester hard disks (with a performance penalty if used as
suggested by use cases described by the CORFU papers).
|
| All Machi file data is protected by SHA-1 checksums generated by
the client prior to writing by Machi servers.
| Depending on server & flash device capabilities, each data page
may be protected by a checksum (calculated independently by each
server rather than the client).
|
See also: the "Recommended reading & related work" and "References"
sections of the
[Machi high level design doc](https://github.com/basho/machi/tree/master/doc/high-level-machi.pdf)
for pointers to the MSR papers related to CORFU.
Machi does not implement Tango directly. (Not yet, at least.)
However, there is a prototype implementation included in the Machi
source tree. See
[the prototype/tango source code directory](https://github.com/basho/machi/tree/master/prototype/tango)
for details.
Also, it's worth adding that the original MSR code behind the research
papers is now available at GitHub:
[https://github.com/CorfuDB/CorfuDB](https://github.com/CorfuDB/CorfuDB).