Quelles sont les limites pratiques d'une famille de colonnes à Cassandra?

À Cassandra, il n'est pas recommandé d'avoir plus de quelques milliers de familles de colonnes , disons 2000 par argument. Dans les cas où plus de 2 000 types de données doivent être conservés, une approche consisterait à répartir plusieurs types de données non liés dans chaque famille de colonnes.

Par exemple, une seule CF peut contenir des commandes, des factures et des clients, à condition que leurs clés de ligne soient distinctes (par exemple, préfixées avec le type d'objet, c'est-à-dire que les clés d'une seule CF peuvent inclure les deux Order|1234et Customer|1234). Un deuxième CF peut contenir, par exemple, des adresses, des éléments de ligne et des types de commande. Compte tenu de la faisabilité de base de cette approche, quelles sont les limites pratiques de celle-ci? Par exemple, qu'y aurait-il de mal à mettre les 10 000 types d'objets dans un seul CF? Pour autant que je sache sur le wiki de Cassandra , il n'y a pas de limitation stricte sur la taille d'un CF.

Je ne suis pas fan. C'est aussi une bonne idée que de créer une table relationnelle nommée OrdersOrCustomers avec des colonnes définies pour les deux. La pénalité du moteur de stockage est légèrement inférieure à Cassandra en raison du stockage à cellules clairsemées sous le capot, mais c'est toujours une mauvaise pratique.

Cela vous mord plus tard lorsque vous souhaitez mapper / réduire vos données; chaque tâche devra parcourir toutes vos données et filtrer les lignes qui ne correspondent pas à ce qui vous intéresse réellement (par exemple, les clients). Et bonne chance pour donner un sens aux statistiques que Cassandra suit par CF. ("Est-ce que CF est la source de 80% de mes demandes lues à cause des données de la commande? Ou à cause des sessions client avec lesquelles il est combiné? Ou aux cinq autres types de données que j'ai ajoutés?")

Si vous avez absolument besoin de dizaines ou de centaines de milliers de FC? Même alors, je préfère exécuter Cassandra sans allocation d'arène, plutôt que de mutiler mon modèle de données comme celui-ci.