1樓：楊東東
資料分割槽和資料放置是邏輯和物理的關係，邏輯是頂層設計，物理是具體實現，邏輯設計決定物理實現，物理約束反過來影響邏輯設計。
舉個例子，
給你10個桌球，要求放入3個盒子裡。
如何決定哪個球放入哪個盒子？比如
按照編號大小：0-2放入盒子A，3-5放入盒子B，6-9放入盒子C
按照編號特徵：對3取餘==0放入盒子A，取餘==1放入盒子B，取餘==2放入盒子C
...上面的策略就是選擇資料分割槽的過程，既然有這麼多分割槽方法可以選，選哪個最好？有乙個比較重要的考慮因素是，3個盒子到底是什麼特徵？
比如是否一樣大小。比如我告訴你盒子A和B只能放1個，盒子C可以放100個，那麼上面兩種策略都不行。如果我告訴你，盒子ABC都能放100個，那麼上面兩種策略都可以。
具體到乙個盒子裡面，怎麼放也有講究，比如隨便扔，或者用格仔乙個個放。
對比上面說的，資料分割槽就是設計球和盒子對應關係的過程，資料放置就是球在盒子裡面怎麼擺放。分配策略決定了如何利用每個盒子，但是盒子的特性會影響分配的策略，資料分割槽和資料放置也是如此，是互相融合不可分割的，所以有時候放在一起說也不奇怪。
2樓：冷風
按照題主的描述
資料分割槽，是指如何把資料分布到不同的node上去資料放置，是指node上的資料是如何在磁碟上儲存的，在磁碟上可以順序的，也可以是隨機位置的。
建議題主去看一下SATA磁碟的原理
3樓：
按照我的理解試著回答一下。
資料分割槽應該就是你所理解的資料分割槽的概念，就是利用分割槽規則對資料進行分割槽，資料庫的分割槽方案可以叫做Database Partitioning Plan。這裡的分割槽規則可以是hash，range等等。
資料放置應該是指資料的具體物理放置，巨集觀上可以指放置在哪台node上，為了負載均衡等考慮，可以有不同的放置方法；微觀上可以指資料在乙個block裡面是如何進行儲存的。
《Skew-Aware Automatic Database Partitioninig in Shared-Nothing, Parallel OLTP Systems》，這篇文章是說的如何對資料進行分割槽。
《Trojan Data Layouts Right Shoes for a Running Elephant》，這篇文章是從微觀上看如何在乙個block裡面對資料進行組織。
至於巨集觀上的資料放置，我暫時還沒關注此方面的文章，或許Amazon的那篇Dynamo中講的那種一致性hash的方式也算是資料放置吧。
水平不夠，可恥的匿了
分布式資料庫的分布式事務？
NebulaGraph 業務系統往往是通過子系統組合的模式來完成,這些子系統很可能是不同的資料庫,甚至可能是 友商 的,互相直接無法保證事務,還是得業務自身保證。 codingfor 你說的單機事物，我的理解其實是指single threaded excution，而不是指在單台機器上做事物 暗含了...
為什麼分布式資料庫這麼喜歡用kv store？
NebulaGraph 採用鍵值對儲存主要還是出於資料模型和效能角度考慮的。目前比較流行的方案有 Google 開源的 LevelDB 和 FaceBook 開源的 RocksDB。鍵值型儲存模型比較簡單，LSM 模型將隨機寫轉換為順序寫，在隨機讀方面也可以優化，效能比較有保障。分布式系統往往根據 ...
什麼情況下，需要使用分布式資料庫？
NebulaGraph 首先，分布式資料庫的優勢大致上概括為三種 1，資料分布儲存在不同的節點上，解決了單機下資料量的限制問題 2，分布式計算，均衡了計算負載 3，從資料安全性考慮，分布式資料庫一般都有多副本機制，以此保證了某乙個節點資料壞掉後能正常提供服務。基於以上三點，我認為海量資料的高併發業務...