Migration de Mysql à Cassandra

Question

Auparavant, j'utilisais la classe trouvé here pour convertir userID une certaine chaîne aléatoire.

De son blog:

Course à pied:

alphaID(9007199254740989); 

retournera 'PpQXn7COf' et:

alphaID('PpQXn7COf', true); 

retournera '9007199254740989'

L'idée est que les utilisateurs pourrait faire www.mysite.com/user/PpQXn7COf et je convertis cela en entier normal afin que je puisse le faire dans mysql

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

Maintenant je commence à travailler avec Cassandra et je cherche un remplacement.

1. Je veux URL comme www.mysite.com/user/PpQXn7COf pas comme www.mysite.com/user/username1
2. UUID "PpQXn7COf" doit être aussi courte que possible.

Dans l'exemple Twissandra expliqué ici: http://www.rackspace.com/cloud/blog/2010/05/12/cassandra-by-example/

Ils créent un peu de temps UUID (je suppose qu'il est si long car alors sa presque 100 pour cent sûr son aléatoire).

Dans mysql je viens d'avoir une colonne userID avec increasement automatique alors quand je l'ai utilisé la fonction alphaID() i toujours eu une chaîne aléatoire très court.

Toute une idée de comment résoudre ce aussi propre que possible?

---

Edit:

Il est utilisé pour un site de médias sociaux de sorte qu'il doit être persistant. C'est aussi pourquoi je ne veux pas utiliser les noms d'utilisateur/noms réels dans les URL, l'utilisateur ne peut pas rester indétecté google s'ils en ont besoin.

Je viens de recevoir une idée simple, mais je ne sais pas comment il est évolutif

<?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"; 
    } 
} 
?> 

Lorsque cela devient la taille permet de dire twitter/facebook:

1. aura-t-il exécuter en temps acceptable? Va-t-il encore générer un uuid unique assez rapidement, donc si 10000 utilisateurs/seconde sont en train de s'enregistrer, ce n'est pas encombré?

Answer 1

Auto-incréments ne conviennent pas pour un système distribué robuste. Vous ne pouvez attribuer un ID unique que si tous les nœuds de votre système sont disponibles, afin de garantir leur caractère unique.

Vous pouvez bien sûr inventer votre propre générateur d'identificateur unique, mais vous devez alors veiller à ce qu'il génère des identifiants uniques partout dans votre infrastructure.Par exemple, chaque noeud peut simplement avoir un fichier qu'il incrémente (avec un verrouillage approprié, par exemple), mais vous devrez également vous assurer qu'il ne se contracte pas, par exemple en insérant l'ID du serveur dans le fichier. algorithme de génération.

Cela peut être pratique non trivial - vos ingénieurs ops devront s'assurer que tous les serveurs de l'infrastructure sont configurés correctement avec leurs propres générateurs d'ID configurés afin qu'ils ne génèrent pas le même ID. Cependant, c'est possible.

Les UUID sont l'alternative raisonnable, car ils seront définitivement uniques.

Un UUID est 128 bits; si nous stockons 6 bits par caractère (c'est-à-dire base64), cela prend 22 caractères, ce qui est un URI assez long. Si vous le souhaitez plus court, vous devrez générer des ID uniques de manière différente. En outre, tout dépend de la «façon dont» vous avez réellement besoin de vos ID. Si vos ID peuvent être réutilisés en toute sécurité après quelques mois, vous pouvez probablement le faire en < 60 bits (en fonction également du nombre de serveurs dans votre infrastructure et de la fréquence à laquelle vous devez les générer).

Nous utilisons

• ID serveur
• Temps (granularité = 2 secondes), mais enveloppements après quelques mois
• Un compteur par serveur (qui enveloppe souvent, mais pas à moins de 2 secondes)

Et coller tous les bits ensemble. Cela génère un ID qui est < 64 bits de long, mais il est garanti unique pour la durée du temps dont il a besoin d'être (dans notre cas est seulement quelques mois)

---

Notre algorithme ne fonctionnera pas correctement et générez un ID en double si:

• L'horloge système de l'un de nos noeuds recule de la même durée que le compteur.
• Nos ingénieurs d'exploitation font une erreur et attribuent le même identifiant de serveur à deux serveurs.
• Finalement, après environ 9 mois.