Base de données de recherche et de mémoire la plus rapide pour un projet Python

Question

Je migre une application GAE/Java vers un nouveau prix Python (non-GAE), donc je reçois un petit serveur et j'aimerais trouver une base de données adapte aux exigences suivantes:

• utilisation de la mémoire faible (ou à accordable ou prédictibles)
• plus rapide capacité de recherche de données simple document/arborescentes identifiés par la clé (je ne me soucie pas de la performance sur l'écriture et Je suppose qu'il aura des index)
• Liaisons avec compatibilité Pypy 1.6 (ou Python 2.7 au moins)

Mes données ressemble à ceci:

• Id: courte chaîne clé
• Titre
• Créateurs: un tableau d'une autre structure de données qui a un identifiant - utilisé comme clé -, un nom, une adresse de site, etc.
• Étiquettes: matrice d'étiquettes. Licence: une structure de données qui décrit sa licence (CC, GPL, ... vous le dites) avec son nom, son URL associée, etc ...
• Temps d'addition: quand il a été ajouté dans notre site.
• Traductions: pointeurs vers d'autres entrées traduisant une création.

Mes requêtes sont très simples. Les cas usuels sont les suivants:

• Filtrer par étiquette en fonction du temps d'ajout.
• Sélectionnez quelques-uns (pagination) classés par date d'ajout.
• (Peut-être, pas déjà fait) filtrer par le créateur.
• (Non fait mais prévu) certaines fonctionnalités de saisie semi-automatique dans les formulaires, donc je vais avoir besoin de recherche si certains champs contiennent une sous-chaîne (requêtes 'LIKE').

Le volume de données n'est pas important. À l'heure actuelle, j'ai environ 50 Mo de données, mais je prévois d'avoir un énorme ensemble de données autour de 10 Go.

Aussi, je veux reconstruire ceci à partir de zéro, donc je suis ouvert à n'importe quelle option. Quelle base de données pensez-vous pouvoir répondre à mes exigences?

Editer: Je veux faire quelques benchmarks autour des différentes options et partager les résultats. J'ai sélectionné, jusqu'ici, MongoDB, PostgreSQL, MySQL, Drizzle, Riak et Kyoto Cabinet.

Answer 1

Je recommanderais Postresql, seulement parce qu'il fait ce que vous voulez, peut évoluer, est rapide , plutôt facile à travailler et stable.

Il est exceptionnellement rapide dans les exemples de requêtes donnés, et pourrait être encore plus rapide avec l'interrogation de documents.

Answer 2

Le chemin de moindre résistance pour la migration d'une application de moteur d'application utilisera probablement AppScale, qui implémente une partie importante de l'API du moteur d'application. En particulier, vous pouvez utiliser le magasin de données HyperTable, qui reflète fidèlement le magasin de données Google App Engine.

Edit: ok, donc vous allez pour une refonte. J'aimerais revenir sur certains points que vous avez soulevés dans votre question.

utilisation de la mémoire à faible

C'est à peu près le contraire de ce que vous voulez dans une base de données; Vous voulez autant de votre ensemble de données dans la mémoire de base que possible; Cela peut signifier ajuster l'ensemble de données lui-même pour qu'il soit efficace ou ajouter des noeuds memcached afin que vous puissiez répartir l'ensemble de données sur plusieurs hôtes afin que chaque hôte ait une fraction suffisamment petite de l'ensemble de données qu'il renferme dans le noyau. Pour renvoyer ce point à la maison, considérez que la lecture d'une valeur de ram est environ 1000 fois plus rapide que la lecture à partir du disque; Une base de données qui peut satisfaire chaque requête du noyau peut gérer 10 fois la charge de travail par rapport à une base de données qui doit visiter le disque pour seulement 1% de ses requêtes.

Je prévois d'avoir un énorme ensemble de données autour de 10GB.

Je ne pense pas que vous pourriez appeler 10 Go un «énorme ensemble de données». En fait, c'est quelque chose qui pourrait probablement tenir dans le RAM d'un serveur de base de données raisonnablement grand; Vous ne voudriez pas besoin de plus d'un nœud memcached, les nœuds de Persistance beaucoup moins supplémentaires (tailles de disque typique sont en téraoctets, 100 fois plus grande que cet ensemble de données attendu.

---

Sur la base de ces informations, je vous conseille vraiment à l'aide un produit de base de données mature comme PostgreSQL, qui vous donnerait beaucoup de performance pour les données que vous décrivez, fournit facilement toutes les fonctionnalités dont vous parlez.Si le moment vient que vous avez besoin de changer d'échelle ce que PostgreSQL peut réellement fournir, vous aurez réellement une vraie charge de travail à analyser pour savoir ce que sont vraiment les goulots d'étranglement