按分布式系統常用的哈希算法切分數據，分放在不同的node上。Read操作時，也是根據key的哈希值尋找對應的node。Dynamo使用了Consistent Hashing算法，node對應的不再是壹個確定的hash值，而是壹個hash值範圍，key的hash值落在這個範圍內，則順時針沿ring找，碰到的第壹個node即為所需。
Dynamo對Consistent Hashing算法的改進在於：它放在環上作為壹個node的是壹組機器（而不是memcached把壹臺機器作為node），這壹組機器是通過同步機制保證數據壹致的。
以上圖為例，node1其實包含了多臺機器，在壹個node裏宕了壹臺機或增加壹臺機，並不影響整個Dynamo對key的尋找。
如果壹個ring內的訪問量大了，則可以在兩個node間加入壹個新node以緩解壓力，這時會影響到其後繼node的hash範圍，需要調整數據。假設壹個ring中原本只有node2、node3、node4，在加入新的node1之後，原先從node2查詢的部分key將改為從node1查詢，node1和node2中的數據就需要調整，主要是node1從node2中提取出屬於它的數據，這樣做需要選取性能壓力不高的時候。 Dynamo的壹個node中的同步是由client端來“解決”的，使用所謂的（N, R, W）模型，其中，N表示node中機器的總數，R表示壹個讀請求需要的機器參與總數，W代表壹個寫請求需要的機器參與總數，這些值由client端配置。
例如，壹個node有5臺機器（N=5），client發出寫請求——廣播到5臺機，如果收到3個“寫完成”的返回消息，即認為寫成功（W=3）；client發出讀請求——還是廣播到5臺機，如果收到2個“讀完成”的返回消息，即認為讀成功（R=2）。對於數據十分重要的應用（如金融），配置可以為(5, 5, 5)，即要求node中所有機器的寫都成功；而對於數據讀寫訪問量極高的應用，配置可以為（5, 1, 1）。
通常W不等於N，於是，在某些情況下壹個node內的機器上的數據可能會有不壹致，這時Dynamo是通過將多個Read的返回結果“合並”來得出最終結果的，使用了所謂Object Version和Vector clock的技術，即跟蹤壹個Object在不同機器上的版本變化，以確保當多個Read請求結果返回不壹致時，能夠根據其版本信息得出正確的結果。 Dynamo的這種做法是壹種折衷，即為了同時保證讀和寫的效率，寫操作不要求絕對同步，而把不同步可能產生的後果推給了讀操作。 Dynamo的壹個node中壹臺機器建有壹個Merkle Tree，當兩臺機器不壹致時（如壹臺機器宕機壹段時間），通過這個tree結構，可以快速定位不壹致的Object來恢復數據。Merkle Tree又叫Hash Tree，它把key分成幾個range，每個range算出壹個hash值，作為葉子，再壹層層合並計算上去，這樣，從root開始比較hash值，就可以快速找到哪幾段range中的hash值變化了。