2010-06-28 35 views
1

J'ai un problème de stockage de 50 Go de journaux chaque jour dans un environnement distribué. J'ai regardé Hadoop HDFS mais parce qu'il a des problèmes fonctionnant sur l'infrastructure de Windows, le manque d'API de système de fichiers multilingue ne me convient pas très bien. Cassandra, d'un autre côté, est très facile à déployer sur n'importe quelle plateforme. Le seul gros problème auquel je suis confronté est l'utilisation de l'espace disque. Voici les chiffres:Cassandra est-il suffisamment adapté pour stocker des journaux en termes d'utilisation de l'espace disque?

  • taille du journal original est 224 Mo
  • fichier de données Cassandra est 557Mb
  • fichier d'index Cassandra est 109Mo

Je suis arrivé en tête presque 2x lors de l'enregistrement des lignes de journaux à partir d'un fichier journal.

Est-il possible d'accorder Cassandra d'une manière ou d'une autre afin qu'il ne mange pas autant d'espace disque pour des scénarios très simples?

+0

mamu, s'il vous plaît lire http://stackoverflow.com/questions/2359175/cassandra-file-structure-how-are-the-files-use/2359282#2359282 – Schildmeijer

Répondre

3

Je suppose que vous voulez dire une ligne (avec quatre colonnes) dans votre famille de colonnes? Le "surcoût" associé à chaque colonne est un long (horodatage, 64 bits) et un octet [] (nom de colonne, max 64 kb). Donc, l'utilisation du disque 4x semble un peu étrange. Faites-vous des suppressions? Assurez-vous de comprendre how deletes are done in a distributed, eventually consistent system.

Soyez sûr de lire sur "compactions" aussi. ("Une fois le compactage terminé, les anciens fichiers SSTable peuvent être supprimés")

Nous aimerions également vous rappeler une limite d'épargne concernant la diffusion en continu.

L'API publique de Cassandra est basée sur Thrift, qui n'offre aucune capacité de diffusion en continu - toute valeur écrite ou récupérée doit tenir dans la mémoire. Ceci est inhérent à la conception de Thrift et est donc peu susceptible de changer. L'ajout d'un support d'objets volumineux à Cassandra nécessite donc une API spéciale qui divise manuellement les gros objets en morceaux. Une approche potentielle est décrite dans http://issues.apache.org/jira/browse/CASSANDRA-265. Pour contourner ce problème, vous pouvez diviser manuellement les fichiers en morceaux de la taille qui vous convient (au moins une personne utilise 64 Mo) et faire en sorte que le fichier corresponde à une ligne, avec les fragments en tant que valeurs de colonne. (De la page 'Cassandra Limitations' sur le wiki)

+0

Schildmeijer, en fait, je me trompais avec l'utilisation de l'espace disque de Cassandra lorsque j'ai soumis ma question (vous avez raison, je n'ai pas exécuté de compactage). Voici donc les chiffres réels (je aussi mis à jour la question d'origine): - taille du journal d'origine est 224 Mo - fichier de données Cassandra est 557Mb - fichier d'index Cassandra est 109Mo Je ne fais aucune supprime. J'ai mis chaque ligne de log dans Cassandra séparément et la ligne la plus longue est d'environ 1kb. Encore 2x frais généraux est un peu gros pour mon but stocker des longs - y at-il un moyen d'optimiser cela? Merci! – sha1dy