[閒聊] 分散式儲存

[laechan (小太保)]

做法不只一種，這裡只是舉例。

比較直覺的想法是，一個 .c 檔，其內存的資料透過像是
save_object 函數的處理後，會產生一個 .o 檔。

那假設以家族系統為例，經年累月下來，必定會產生很多
的家族，以及很多的家族成員資料，那如果這些資料都儲
存在同一個 .o 檔裡頭，就會使得 .o 檔過於肥大。

.o 檔肥大有時會產生兩個問題

一、.o 檔的載入 loading 過重

二、.o 檔的意外損毀(比方早期大於 198K 時)

那麼，就「家族資料」來說，因為儲存的資料主體多半是
玩家ID，則以玩家ID開頭做分流就變成直覺的想法:

  laechan 這個玩家的家族資料，儲存在 group_l.o 裡

  => 設計一個 group_l.c，使它在做 save_object 時會
     產生 group_l.o

  => 即 laechan 的家族資料是 set 在 group_l.c 裡的

則 group_l.c 的檔案內容如下

group_l.c
==================================================
mapping group_data=([]);

void create()
{
 ::create();
 seteuid(getuid(this_object()));
 if(file_exists(base_name(this_object())+".o"))
  restore_object(base_name(this_object()));
}

// 呼叫這個函數時會做儲存
int save_room()
{
 save_object(base_name(this_object()));
 return 1;
}

mapping query_group_data(string names)
{
 return group_data[names];
}
  .
  .
================================================

而其它的 group_X.c 其檔案內容也一樣(所以可以用繼
承來省略)。

然後，設計一個 group.c，讀取資料都透過它，底下是
程式片段

group.c
================================================
// 讀取某一玩家資料的例子
mapping query_group_data(string names)
{
 object group_ob;

 // 去找跟該玩家ID字頭有關的 group_X.c
 if(!catch(group_ob=find_object(__DIR__+"group_"+names[0..0])))
  return group_ob->query_group_data(names);
}

// 能讀取自然就能 set, del, add, ..
================================================

上面的意思可用底下的圖示來表示

               query
             ────→   判斷字頭         找到物件
               set      ┌─────┐  ┌─────┐
  Request 方 ────→ │ group.c  ├→┤ group_X.c├←存取對映.o檔
               modify   └─────┘  └─────┘
             ────→
               .
               .

這樣就可以把一個 group.o 檔，分拆成 36 個 .o 檔
，分別是 group_0.o、group_1.o、...、group_z.o。

底下是一個分拆後的實例:

> ls *.o
   1 group_data_0.o    1 group_data_9.o    3 group_data_i.o    5 group_data_r.o
   1 group_data_1.o    9 group_data_a.o    4 group_data_j.o   16 group_data_s.o
   1 group_data_2.o    7 group_data_b.o    6 group_data_k.o    5 group_data_t.o
   1 group_data_3.o    9 group_data_c.o    8 group_data_l.o    1 group_data_u.o
   1 group_data_4.o    8 group_data_d.o    7 group_data_m.o    1 group_data_v.o
   1 group_data_5.o    5 group_data_e.o    5 group_data_n.o    4 group_data_w.o
   1 group_data_6.o    5 group_data_f.o    1 group_data_o.o    1 group_data_x.o
   1 group_data_7.o    5 group_data_g.o    6 group_data_p.o    3 group_data_y.o
   1 group_data_8.o    6 group_data_h.o    2 group_data_q.o    2 group_data_z.o


分拆的好處是..

一、每一分拆檔如上所示，檔案內容都很小，處理速度快。
    資料不需集中儲存於同一個地方。

二、所有的家族資料，會在不同的時間載入。通常是有玩家
    去呼叫到時，比方剛 shutdown 完，某家族族長去list
    了自己的家族，那 group_X.c的部份只會載入跟它家族
    有關的成員ID字頭的物件

三、當我們變動了一筆家族資料時，只需去動到跟該筆資料
    有關的 group_X.o，其它的 group_X.o檔不會動到。

四、分拆後可儲存的家族資料可變多，底下是實例:

    > list -easy
    全部共 574 個族群、3714 個族員.

五、萬一發生資料損毀的情況，可避免全面性的資料損壞。


至於家族(或幫派)資料為何不儲存在玩家身上，而要另外儲
存呢？這是因為這樣一來即便家族裡頭有玩家離線，也不會
妨礙家族資料的存取及變更。當然實際上即便資料是存在玩
家身上，透過一些特殊做法同樣能不妨礙家族資料的存取及
變更。只是我不想去實作那些方法。

以上一點心得。


                    Laechan@Sanc

--
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 編輯: laechan         來自: 210.61.157.53        (01/28 16:07)
推 cibs        :如果以家族/幫派資料來看，我覺得直
→ cibs        :接用家族名來存會更方便存取？
有些是一對一關係，例如族長─族名，所以用族長ID為
keyname、或用族名為 keyname 來存家族是可行的，而
用族長ID的好處是絕不會重覆，族名則可能重覆、中文
、色碼、空白等等。

※ 編輯: laechan         來自: 1.165.174.117        (01/29 07:50)