Python Psych Experiment a besoin d'une base de données (simple) : veuillez me conseiller

Question

Je suis en train de coder une expérience de psychologie en Python. Je dois stocker les informations et les scores des utilisateurs quelque part, et j'ai besoin que cela fonctionne comme une application web (et soit sécurisé).

Je n'y connais pas grand chose - j'envisage des bases de données XML, BerkleyDB, sqlite, un tableur openoffice, ou je suis très intéressé par la bibliothèque "shelve" de python. (La plupart de mes informations proviennent de ce fil de discussion : http://developers.slashdot.org/story/08/05/20/2150246/FOSS-Flat-File-Database

DONNEES : Je suppose que je vais avoir au maximum 1000 utilisateurs. Pour chaque utilisateur, je dois stocker...

• Nom d'utilisateur / Pass
• Champs de détails de l'utilisateur (pour un profil simple)
• Les scores de l'utilisateur sur l'exercice (2 points de données : chaque essai obtient un score (correct/incorrect/temps mort, et a un nombre associé de 0.1 à 1.0 que je dois enregistrer)
• Métadonnées sur les procès (quand, qui, etc.)
• Résultats de l'analyse des données pour l'utilisateur

Selon une estimation très approximative, chaque utilisateur génère 100 essais / jour. Donc un maximum de 10k points de données / jour. Il doit fonctionner de cette façon pendant environ 3 mois, donc environ 1 million de points de données. Le multiplicateur de sécurité 2x me donne un objectif d'une base de données qui peut gérer 2m de points de données.

((note : je pourrais soit stocker les données de réponse aux essais sous forme de points de données individuels, soit regrouper les essais dans des objets liste Python de longueur variable (les "sessions" de l'utilisateur). Cette dernière solution permettrait de réduire considérablement le nombre d'entrées dans la base de données, mais pas la quantité de données. Est-ce important ? Comment ?))

Je veux une solution qui fonctionnera (au moins) jusqu'à ce que j'atteigne ce niveau de 1000 utilisateurs. Si mon programme est populaire au-delà de ce niveau, je suis d'accord pour faire un peu de modding dans une DB plus musclée. Je répète également qu'il doit être facilement déployable en tant qu'application web.

Au-delà de ces exigences de base, je veux juste que le chose la plus facile qui fera en sorte que ça marche. Je suis plutôt vert.

Merci de votre lecture

Tr3y

Answer 1

SQLite peut certainement gérer ces quantités de données, il a une très large base d'utilisateurs avec quelques des utilisateurs très connus sur toutes les principales plates-formes, il est rapide, léger, et il y a des clients GUI géniaux qui vous permet de parcourir et d'extraire/filtrer des données en quelques clics.

SQLite n'évoluera pas indéfiniment, bien sûr, mais les problèmes de performances graves ne commencent que lorsque des insertions simultanées sont nécessaires ce qui, je suppose, est un problème qui apparaît plusieurs ordres de grandeur après votre charge prospectée.

Je l'utilise depuis quelques années maintenant, et je n'ai jamais eu de problème avec lui (bien que pour les sites plus importants, j'utilise MySQL). Personnellement, je trouve que "Petit. Rapide. Fiable. Choisissez-en trois." (qui est le slogan du site de SQLite) est tout à fait exact.

Quant à la la facilité d'utilisation ... Liaisons SQLite3 (site temporairement indisponible) font partie de la bibliothèque standard de python. Aquí vous pouvez trouver un petit tutoriel. Il est intéressant de noter que la simplicité est un critère de conception de SQLite. À partir de aquí :

Beaucoup de gens aiment SQLite parce qu'il est petit et rapide. Mais ces qualités ne sont que des accidents heureux. Les utilisateurs trouvent également que SQLite est très fiable. La fiabilité est une conséquence de la simplicité. Avec moins de complications, il y a moins de risques d'erreur. Donc, oui, SQLite est petit, rapide et fiable, mais avant tout, SQLite s'efforce d'être simple.

Answer 2

Il y a une discussion très précise sur l'utilisation de SQLite. aquí . Ma phrase préférée est celle-ci :

Une autre façon de voir SQLite est la suivante : SQLite n'est pas conçu pour remplacer Oracle. Il est conçu pour remplacer fopen() .

Il me semble que pour vos besoins, SQLite est parfait. En effet, il me semble très possible que vous n'ayez jamais besoin d'autre chose :

Avec la taille de page par défaut de 1024 octets, une base de données SQLite est limitée en taille à 2 téraoctets (2^41 octets).

On dirait que vous n'aurez jamais autant de données.

Answer 3

J'envisagerais MongoDB. Il est très facile de démarrer, et il est conçu pour les configurations multi-utilisateurs (contrairement à SQLite).

Il a également un modèle beaucoup plus simple. Au lieu de s'amuser avec des tables et des champs, vous prenez simplement toutes les données de votre formulaire et les placez dans la base de données. Même si votre formulaire change (oups, vous avez oublié un champ), vous n'aurez pas besoin de modifier MongoDB.