Cassandra: texte vs varchar

probablement vous vouliez dire les types de stockage CQL, sinon, ne tenez pas compte de ma réponse.

dans CQL il y a eu une tendance continue à essayer de s'éloigner des internes de cassandra. Qu'il s'agisse d'une bonne ou d'une mauvaise chose est sujet à interprétation. Ce qui est pertinent, cependant, c'est que dans les dernières versions de CQL les développeurs ont essayé de trouver une syntaxe qui est plus familière pour les gens qui ne sont pas si en profondeur dans les internes de cassandra.

si vous deviez jeter un oeil à cette question, donc vous obtiendrez une belle illustration de la situation: création d'une famille de colonnes ou d'une table dans Cassandra tout en travaillant avec L'API Datastax (qui utilise un nouveau protocole binaire)

dans les versions récentes de CQL, certains alias, étrangers à cassandra, mais très bien connus de DBA ont commencé à apparaître. Par exemple, le natif de cassandra ColumnFamily a été aliasé avec Table, et text est juste un alias pour varchar et vice versa. Encore une fois, c'est une question d'opinion, si c'est une bonne chose ou pas.

donc, en conclusion, vous pouvez utiliser varchar et le texte de façon interchangeable.

cela m'a bouleversé aussi quand J'ai commencé avec Cassandra.

text et varchar sont des chaînes encodées UTF8 et sont synonymes l'un pour l'autre, c'est-à-dire qu'ils sont exactement la même chose.

comme note ajoutée si l'on vient d'un monde relationnel comme MS SQL, on serait peut-être aussi hésitant à utiliser ces types (en particulier le texte) comme champ primaire pour une entité. Le texte est surtout généralement associé à de grands blobs de contenu de texte qui ne CRI clé primaire de l'esprit relationnel de la 3ème forme normale. Mais puisque tous les types de Cassandra sont essentiellement stockés sous forme de tableaux hexadécimaux sur le disque, il n'y a pas de véritable performance significative en les utilisant comme clé primaire.