Les limites théoriques de redis


Nombre de clés max: 2^64-1
Nombre d’éléments max dans un set: 2^64-1
Nombre d’éléments max dans une liste: 2^32-1
Nombre d’éléments max dans une liste: 2^64-1
Taille maximum d’une clé: 2^31 octets
Taille maximum d’une valeur de type string: 512 Mo
Nombre max de DB: virtuellement infinie, mais s’attendre à des problèmes de perf si on dépasse 1000, et le fichier de conf met la limite à 16 par défaut.

Ca va, il y a de la marge.

4 thoughts on “Les limites théoriques de redis

  • fero14041

    Question de noob: est-ce que vous connaîtriez un guide un peu pointu sur les différentes bases de données NoSQL? Qui serait “raisonnablement” complet, et ne se contenterait pas de généralités ou vues de trop haut niveau? Un moyen terme entre “elles ont toutes leurs avantages et inconvénients propres”, et “teste-les, fais-toi une idée par toi-même” (i.e. “deviens expert, et tu auras répondu à ta question)…

  • Sam Post author

    Pas que je connaisse.

    Le meilleur comparatif que j’ai lu est:

    http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

    Mais c’est succin.

    De notre côté on a utilisé que MongoDB, CouchDB, Memcached et Redis.

    J’ai un faible pour MongoDB et Redis, mais ça se débat.

    Par contre en deux ans de pratique, j’en suis arrivé à la conclusion qu’il y a pour le moment très peu de cas où le NOSQL est plus intéressant que le SQL. D’ailleurs, ça mériterait un article.

  • fero14041

    Cool, merci pour le lien! Quant à l’idée d’un petit article sur les conditions d’intérêt d’usage du NoSQL VS SQL, ça devrait en intéresser plus d’un…

  • fero14041

    Ah, je crois avoir trouvé une référence sur le sujet: “Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement” d’E.Redmond & J.Wilson, chez The Pragmatic Bookshelf. Ca traite de PostgreSQL, Riak, HBase, MongoDB, CouchDB, Neo4J et Redis. L’ouvrage sent bon (même si pas encore lu).

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.