從Mysql遷移到Cassandra

以前我使用的是類here將userID轉換爲一些隨機字符串。從Mysql遷移到Cassandra

從他的博客：

運行：

alphaID(9007199254740989);

會返回PpQXn7COf'和：

alphaID('PpQXn7COf', true);

將返回 '9007199254740989'

這樣的想法是，用戶可以做www.mysite.com/user/PpQXn7COf，我把它轉換成一個正常的整數，所以我可以做在mysql中

"Select * from Users where userID=".alphaID('PpQXn7COf', true)

現在我剛開始與Cassandra合作，我正在尋找一些替代品。

我想網址喜歡www.mysite.com/user/PpQXn7COf不喜歡www.mysite.com/user/username1
的「PpQXn7COf」 UUID必須儘可能短。

在Twissandra例子來說明這裏：http://www.rackspace.com/cloud/blog/2010/05/12/cassandra-by-example/

他們創造一些長期UUID（我想這是這麼長時間，因爲那麼它幾乎達到100％肯定它是隨機的）。

在MySQL中，我只是有一個用戶ID列自動增加，所以當我使用alphaID（）函數時，我總是得到一個非常短的隨機字符串。

任何想法如何解決這個儘可能乾淨？

編輯：

它用於社交媒體網站，所以它必須是持久的。這也是爲什麼我不想在網址中使用用戶名/真實姓名，用戶如果他們需要，不能檢測到谷歌。

我剛剛得到一個簡單的想法，但我不知道它是多麼可擴展

<?php 
//createUUID() makes +- 14 char string with A-Z a-z 1-0 based on micro/milli/nanoseconds 
while(get_count(createUUID()) > 0){//uuid is unique 
    //insert username pass, uuid etc into cassandra 
    if($result == "1"){ 
     header('Location: http://www.mysite.com/usercenter'); 
    }else{ 
     echo "error"; 
    } 
} 
?>

當這得到的大小可以說嘰嘰喳喳/ Facebook的：

將它在執行可接受的時間
它是否仍然生成獨特的uuid足夠快，所以如果10000用戶/秒正在註冊它不混亂嗎？

來源

2011-04-16 Writecoder

自動增量不適用於強大的分佈式系統。如果系統中的每個節點都可用，則只能分配一個唯一ID，以確保它是唯一的。

當然，您可以創建自己的unique-id生成器，但必須確保它將在您的基礎架構中的任何位置生成唯一的ID。例如，每個節點可以只有一個文件（它具有合適的鎖定等）只是遞增，但是您還需要確保它們不會發生衝突 - 例如，通過將服務器ID包含在生成算法。

這可能在操作上不重要 - 您的操作員工程師需要確保基礎架構中的所有服務器配置正確，並設置自己的ID生成器，以便它們不生成相同的ID。但是，這是可能的。

UUID是合理的選擇，因爲它們一定是唯一的。

UUID是128位;如果我們每個字符存儲6位（即base64），那麼需要22個字符，這是相當長的URI。如果你想縮短它，你將需要以不同的方式生成唯一的ID。

再加上這一切都取決於你實際需要你的ID的「多麼獨特」。如果您的ID可以在幾個月後安全地重新使用，那麼您可以在60個位（也取決於基礎架構中的服務器數量以及需要生成它們的頻率）執行此操作。

我們使用

服務器ID
時間（粒度= 2秒），但包裝幾個月
每個服務器櫃檯後（這常常包裹，但在2秒之內）

並將所有位粘在一起。這產生一個ID是< 64位長，但保證是爲它需要的時間長度是唯一的（在我們的情況下是唯一的幾個月）

我們的算法會發生故障並生成重複的ID如果：

我們的某個節點上的系統時鐘向後倒退的時間與計數器換行的時間相同。
我們的操作工程師犯了一個錯誤，並將相同的服務器ID分配給兩臺服務器。
最終，大約9個月後。

來源

2011-04-16 14:03:47 MarkR

謝謝你的精彩回答！但是，你認爲我的第一篇文章中的簡單版本（查看編輯中）是否也可以工作？這實現起來會簡單得多。 – Writecoder 2011-04-16 14:33:43

從Mysql遷移到Cassandra

回答

相關問題