Skip to content
Browse files

some tweaks

  • Loading branch information...
1 parent 144460a commit 24b16b0d812479406edcc35572dcfef337773873 Mark Phillips committed Jul 23, 2012
Showing with 27 additions and 10 deletions.
  1. +6 −2 docs/dynamo.html
  2. 0 dr_rockzo.rb
  3. +21 −8 dynamo.js
View
8 docs/dynamo.html
@@ -201,19 +201,23 @@
</ol>
Riak's realistic object size limit is around 5MB. Basho does offer a commercial extenstion to Riak called
-<a href="#">Riak CS</a> that can store objects well into the GB range.</p></td><td class="code"><p>
+<a href="#">Riak CS</a> that can store objects well into the 10s of GB range at the time of this writing.</p></td><td class="code"><p>
</p><p>
Query Model: simple read and write operations to a data item that is uniquely identified by a key.
State is stored as binary objects (i.e., blobs) identified by unique keys. No operations span multiple
data items and there is no need for relational schema. This requirement is based on the observation that
a significant portion of Amazon’s services can work with this simple query model and do not need any
relational schema. Dynamo targets applications that need to store objects that are relatively small
(usually less than 1 MB).
-</p><p></p></td><tr id="section-12"><td class="docs"><div class="pilwrap"><a class="pilcrow" href="#section-12">&#182;</a></div><p><strong>ACID?</strong>
+</p><p></p></td><tr id="section-12"><td class="docs"><div class="pilwrap"><a class="pilcrow" href="#section-12">&#182;</a></div><p><strong>ACID Properties:</strong>
Riak offers no traditional "ACID" semantics around transactions. Instead, it's built to
be "evenutually consistent." We did this because we were of the opinion (and our users proved this)
that most applications don't require heavy transactions. (Even ATMs are eventually consistent.)
+<br/>
+<br/>
+Riak stresses availability and puts the power in the hands of developers and ops professionals to
+tweak and tune the consistency requirements.
</p></td><td class="code"><p>
ACID Properties: ACID (Atomicity, Consistency, Isolation, Durability) is a
set of properties that guarantee that database transactions are processed reliably. In the context of
View
0 dr_rockzo.rb 100644 → 100755
File mode changed.
View
29 dynamo.js
@@ -203,7 +203,7 @@ The storage system for this class of services has the following requirements:
// </ol>
//
// Riak's realistic object size limit is around 5MB. Basho does offer a commercial extenstion to Riak called
-// <a href="#">Riak CS</a> that can store objects well into the GB range.
+// <a href="#">Riak CS</a> that can store objects well into the 10s of GB range at the time of this writing.
Query Model: simple read and write operations to a data item that is uniquely identified by a key.
@@ -213,11 +213,15 @@ a significant portion of Amazon’s services can work with this simple query mod
relational schema. Dynamo targets applications that need to store objects that are relatively small
(usually less than 1 MB).
-// <strong>ACID?</strong>
+// <strong>ACID Properties:</strong>
//
// Riak offers no traditional "ACID" semantics around transactions. Instead, it's built to
// be "evenutually consistent." We did this because we were of the opinion (and our users proved this)
// that most applications don't require heavy transactions. (Even ATMs are eventually consistent.)
+// <br/>
+// <br/>
+// Riak stresses availability and puts the power in the hands of developers and ops professionals to
+// tweak and tune the consistency requirements.
//
ACID Properties: ACID (Atomicity, Consistency, Isolation, Durability) is a
@@ -228,11 +232,11 @@ acknowledged by both the industry and academia [5]. Dynamo targets applications
consistency (the “C” in ACID) if this results in high availability. Dynamo does not provide any isolation
guarantees and permits only single key updates.
-// <strong>Efficiency</strong>
+// <strong>Efficiency:</strong>
//
-// Agreed. Riak is made to (and will!) scale linearly on commodity hardware (often called "pizza boxes").
+// Agreed. Riak is made to scale linearly on commodity hardware (often called "pizza boxes").
//
-// <li><a href="http://wiki.basho.com/display/RIAK/Hosting+and+Server+Configuration#HostingandServerConfiguration-Hardware">More on Hardware</a></li>
+// NOTE ** Add some details and examples of what Riak users deploy for hardware. **
//
Efficiency: The system needs to function on a commodity hardware infrastructure. In Amazon’s platform, services have stringent latency requirements which are
@@ -374,7 +378,7 @@ Incremental scalability: Dynamo should be able to scale out one storage host (he
to as “node”) at a time, with minimal impact on both operators of the system and the system itself.
// Again, we agree. Each storage nope is the same at its neighbor. Any node can coordinate
-// a request and, in the event that a node goes does, its neighbors can cover for it until
+// a request and, in the event that a node goes down, its neighbors can cover for it until
// it's restarted or decommissioned.
Symmetry: Every node in Dynamo should have the same set of responsibilities as its peers;
@@ -396,8 +400,17 @@ runs on. e.g. the work distribution must be proportional to the capabilities of
servers. This is essential in adding new nodes with higher capacity without having to upgrade all
hosts at once.
-// Blurb about how this section is a wonderful study in some technology and how it should be read when
-// you have a moment.
+//
+// Though some would lead you to believe otherwise, Dynamo- and Riak-shaped systems have existed
+// for some time (either as code or as research) and they should be investigated and reviewed
+// (especially if you're planning to write your own distributed storage system).
+// <br/>
+// <br/>
+// Basho doesn't claim to have pioneered many of the concepts that power Riak (like consistent hashing,
+// vector clocks, and hinted handoff), but we do plan to perfect them.
+// <br/>
+// <br/>
+// ** Add some references to other wor
3. Related Work

0 comments on commit 24b16b0

Please sign in to comment.
Something went wrong with that request. Please try again.