1. Accueil
  2. Question et réponse
  3. Base de données avec peu de mémoire et interface Ruby

Base de données avec peu de mémoire et interface Ruby

2011-01-06 5 views
2

J'ai besoin d'une base de données avec peu de mémoire requise pour un petit serveur virtuel avec peu de mémoire. En ce moment je suis coincé avec SQLite et Kyoto Cabinet ou Tokyo Cabinet. La base de données devrait avoir une interface Ruby.Base de données avec peu de mémoire et interface Ruby

Idéalement, je souhaite éviter les magasins de valeurs-clés, car j'ai des requêtes "complexes" (plus complexes que la recherche d'une seule clé) et des tuples comme clés. D'un autre côté, je ne veux pas avoir un schéma fixe et éviter les efforts de planification et de migration d'une base de données SQL. Un serveur de base de données n'est pas non plus nécessaire car une seule application utilisera la base de données.

Avez-vous des recommandations et des chiffres pour moi?

Source

2011-01-06 Anonymous

+0

Quelle quantité de mémoire pouvez-vous autoriser le serveur à consommer? –

+0

Je dirais moins de 10 MiB. Mais je pourrais mettre à jour le serveur s'il y a une caractéristique convaincante de la base de données. –

Répondre

0

SQLite3 est un excellent choix pour ce que vous essayez de faire. Il est utilisé par beaucoup de companies comme base de données d'applications embarquées car il est flexible, rapide, bien testé et peu encombrant. Il est facile de créer et d'extraire des tableaux pour qu'ils soient compatibles avec les tests ou les magasins de données à application unique. Le langage SQL qu'il utilise est assez riche pour faire des choses normales mais je recommanderais d'utiliser Sequel avec lui. C'est un excellent ORM et vous permet de le traiter facilement comme un ORM complet, ou de descendre jusqu'au langage DBM.

Source

2011-01-07 00:16:31

+0

SQLite est quelque peu limité (http://www.sqlite.org/omitted.html). Je voudrais vraiment pouvoir écrire aux vues. De plus, le support DROP COLUMN manquant me semble problématique pour les migrations (vous pouvez faire la migration en créant une table temporaire, en copiant les données sauf les colonnes à supprimer, déposer la table d'origine et recréer depuis la table temporaire, mais c'est vraiment laid). –

0

Vous recherchez une solution qui ne dispose que d'un fichier de base de données et pas de serveur en cours d'exécution, probablement. Dans ce cas, Sqlite devrait être un bon choix - Si vous n'en avez pas besoin, fermez simplement la connexion et c'est tout. Sqlite a tout ce dont vous avez besoin et RDMS (attendez-vous à forcer FK directement, mais cela peut être fait avec des triggers), avec très peu de mémoire, alors dans ce cas, vous êtes probablement plus inquiet de la mémoire de votre ORM (le cas échéant) les usages. Personnellement, j'utilise sqlite pour ce cas d'utilisation, car il est portable et facile d'accès et d'installation (ce qui ne devrait pas être le problème sur un serveur, mais dans une application de bureau).

Source

2011-01-06 21:25:05 Femaref

+0

Mais avec SQL vous avez le problème des schémas et de la planification (dessin des schémas de modèle de données, les convertissant en forme normale, etc.) et peut-être des problèmes avec les migrations de schémas. SQLite serait mon choix si je ne trouve pas d'autre solution, car je sais que ça marchera. Il y a longtemps que j'ai utilisé les ORM (enfin ActiveRecord). J'ai l'impression qu'ils ne fournissent que le plus petit dénominateur commun des bases de données qu'ils ont abstraites et génèrent des requêtes sous-optimales. Mais puisque SQLite implémente uniquement SQL 92, il ne devrait pas être une énorme limitation. –

+0

@ott "problème des schémas et de la planification (dessin schémas de modèle de données, les convertissant en forme normale, etc) généraux et peut-être des problèmes avec les migrations de schémas" Pourquoi? Cela peut être compliqué si vous voulez le faire de cette façon, ou vous pouvez écrire des migrations pour ActiveRecord ou Sequel, et les laisser faire le gros du travail. Changez l'adaptateur de base de données en MySQL, Postgres ou autre chose, et l'ORM s'occupera de toute la création et de la manipulation du schéma. –

+0

@ott En ce qui concerne la qualité des requêtes SQL, j'ai regardé la sortie d'ActiveRecord et de Sequel plusieurs fois et ils génèrent des requêtes que j'écrirais la plupart du temps. Vous seriez surpris de voir à quel point ils sont intelligents. Et, si vous les voyez se tromper de route, vous pouvez facilement remplacer votre propre SQL modifié à la main et ils l'utiliseront volontiers. Ils ont certainement battu en utilisant DBI et en écrivant tout à la main. –

0

BerkeleyDB avec l'API SQLite est ce dont vous avez besoin. http://www.oracle.com/technetwork/database/berkeleydb/overview/sql-160887.html

Source

2011-01-08 15:34:48 Jeff

+0

Quels sont les avantages de Berkeley DB sur le moteur de stockage par défaut de SQLite dans la pratique? –

+0

@ott Le moteur de stockage par défaut de SQLite utilise le verrouillage au niveau de la base de données, ce qui signifie qu'un seul auteur peut accéder à la base de données à la fois. BerkeleyDB utilise le verrouillage au niveau de la page et MVCC, de sorte qu'il autorise plus d'un auteur simultané. Si votre application est intensive en écriture, vous devez utiliser le moteur de stockage BerkeleyDB. Si votre application ne modifie pas les données fréquemment, le moteur de stockage par défaut de SQLite et BerkeleyDB effectuent la même chose. – Jeff

3

  1. Il est schema-less Postgresql (Postgresql 9.2 + JSON). Pas aussi dur/confus à mettre en place que je pensais. Vous obtenez beaucoup de flexibilité avec les requêtes tout en bénéficiant des avantages du stockage sans schéma. PG 9.2 inclut plv8js, un nouveau gestionnaire de langue qui vous permet de créer des fonctions en JavaScript. Voici un exemple de la façon dont vous pouvez indexer et requête JSON docs dans PG 9.2: http://people.planetpostgresql.org/andrew/index.php?/archives/249-Using-PLV8-to-index-JSON.html

  2. CouchDB (utilisation BigCouch Basé sur CouchDB, mais moins de bugs/problèmes..):

    • très faibles besoins en mémoire .
    • sans schéma.
    • Interface HTTP. Ruby a beaucoup de clients HTTP. La mise en cache HTTP (comme Varnish) peut également accélérer les lectures.
    • requêtes créatives/complexes. Vous pouvez créer des index et des requêtes sur n'importe quelle clé du document (enregistrement). Vous pouvez être très créatif avec les requêtes car les index sont très programmables.

    : Downsides

    Si le disque est pas cher et mémoire cher, il serait un bon candidat pour vos besoins.

    "... une autre force de CouchDB, qui a fait ses preuves pour des milliers de requêtes simultanées, ne nécessitait qu'environ 10 Mo de mémoire vive - quelle est cette impression?!?!" (De: http://www.larsgeorge.com/2009/03/hbase-vs-couchdb-in-berlin.html)

Source

2011-07-13 00:44:47

Questions connexes

 Questions connexes