ID de ligne séquentielle dans les DB axés sur les colonnes (HBase, Cassandra)?

Question

j'ai vu deux morceaux contradictoires de conseils en matière de conception ID de ligne dans HBase, (en particulier, mais je pense qu'il applique à Cassandra aussi.)

1. clés du groupe que vous regroupera des données ensemble souvent pour tirer parti de la localité de données. (Blanc, Hadoop: Le Guide Définitif et je me souviens de l'avoir vu sur le site HBase, mais je ne le trouve pas ...)
2. Répartissez les touches de sorte que le travail puisse être réparti sur plusieurs machines (Twitter, Pig, and HBase at Twitter diapo 14)

Je suppose que la solution optimale peut dépendre de votre cas d'utilisation, mais est-ce que quelqu'un a de l'expérience avec l'une ou l'autre stratégie?

Answer 1

Dans HBase, une table est partitionnée en régions en divisant l'espace clé, qui est trié lexicographiquement. Chaque région de la table appartient à un serveur de région unique, donc toutes les lectures et les écritures sont traitées par ce serveur (ce qui permet une forte garantie de cohérence). Cela signifie que si toutes vos lectures ou écritures sont concentrées sur une petite partie de votre espace de clés, vous ne pourrez pas évoluer vers ce qu'un seul serveur de région peut gérer. Par exemple, si vos données sont des séries temporelles et indexées par l'horodatage, toutes les écritures vont à la dernière région de la table, et vous serez contraint d'écrire au débit qu'un seul serveur peut gérer. D'un autre côté, si vous pouvez choisir vos clés de sorte qu'une requête donnée n'a besoin que d'analyser une petite plage de lignes, mais que l'ensemble des lectures et des écritures est réparti sur votre espace de clés, la charge totale sera être distribué et évoluer correctement, mais vous pouvez toujours profiter des avantages de la localité pour votre requête.