Base de données de mémoire principale et base de données d'objets

Question

J'essaie actuellement de choisir un fournisseur de base de données.

Je cherche simplement des opinions personnelles auprès d'autres développeurs de bases de données.

Ma question s'adresse particulièrement aux personnes qui :

1) ont déjà utilisé la base de données de mémoire principale (MMDB) qui prend en charge la réplication sur disque (hybride) (c'est-à-dire ExtrêmeDB)

ou

2) avoir utilisé Base de données d'objets Versant et/ou Base de données d'objectivité et/ou Magasin d'objets de progression

et la question est vraiment :si vous pouviez recommander un fournisseur de base de données, en fonction de votre expérience, cela conviendrait à mon application.

Mon application est une application commerciale en temps réel (lire :hautes performances) de type SIG C++ orienté objet, où nous devons effectuer beaucoup de recherches latitude/longitude (c.-à-d.étant donné une zone, trouvez toutes les cibles correspondantes dans la zone... index R-Tree).

Les types de données que je voudrais stocker dans la base de données sont tous modélisés sous forme d'objets et utilisent std :: list et std :: vector, donc naturellement, Object Database semble avoir du sens.J'ai lu suffisamment d'articles pour me convaincre qu'un SGBDR traditionnel n'est probablement pas ce que je recherche vraiment en termes de

1. Performances (jointures ou plusieurs tables pour des données de longueur dynamique comme la liste / vecteur)
2. facilité de programmation (décalage d'impédance)

Cependant, en termes de performances,

1. Les données d'entrée sont introduites dans le système à environ 40 Mo/s.

2. Par conséquent, le système effectuera également des insertions dans la base de données à un rythme d'environ 350 insertions par seconde (chaque objet variant de 64 Ko à 128 Ko),

3. La base de données sera constamment recherchée et mise à jour via plusieurs threads.

D'après ma compréhension, toutes les bases de données d'objets que j'ai répertoriées ici utilisent le cache pour stocker les objets de base de données.ExtremeDB affirme que puisqu'il est conçu spécialement pour la mémoire, il peut éviter la surcharge de la logique de mise en cache, etc.Pour en savoir plus, recherchez sur Google :Mémoire principale vs.Bases de données sur disque RAM :Un benchmark basé sur Linux

Donc… je suis juste un peu confus.Les bases de données d'objets peuvent-elles être utilisées dans un système temps réel ?Est-ce aussi « rapide » que MMDB ?

Answer 1

Fondamentalement, la différence entre une MMDB et une OODB est que la MMDB s'attend à ce que toutes ses données soient basées dans la RAM, mais soient conservées sur le disque à un moment donné.Alors qu'un ODB est plus conventionnel dans la mesure où on ne s'attend pas à ce que l'intégralité de la base de données s'intègre dans la RAM.

La MMDB peut tirer parti de cela en abandonnant le concept selon lequel les données persistantes ne doivent pas nécessairement « correspondre » aux données de la RAM.

La façon dont tout ce qui a de la persistance va fonctionner est qu'il doit écrire les données sur le disque lors de la mise à jour d'une manière ou d'une autre.

Presque toutes les bases de données utilisent une sorte de journal pour cela.Ces journaux sont essentiellement des pages de données « brutes », ou peut-être des transactions individuelles, annexées à un fichier.Lorsque le fichier devient « trop gros », un nouveau fichier est démarré.

Une fois que les journaux sont correctement consolidés dans le magasin principal, ils sont supprimés (ou réutilisés).

Désormais, une base de données brute dans la RAM peut exister simplement en ajoutant des transactions à un fichier journal, et lorsqu'elle est redémarrée, elle charge simplement la connexion dans la RAM.Donc, essentiellement, le fichier journal EST la base de données.

L'inconvénient de cette technique est que plus vous avez de transactions longues et nombreuses, plus votre journal/base de données est volumineux, et donc plus le temps de démarrage de la base de données est long.Mais, idéalement, vous pouvez également « instantaner » l’état actuel, ce qui élimine tous les journaux à jour et les compresse efficacement.

De cette manière, toutes les opérations de routine de la base de données doivent gérer l'ajout de pages aux journaux, plutôt que la mise à jour d'autres pages de disque, pages d'index, etc.Étant donné que, idéalement, la plupart des systèmes n'ont pas besoin de « démarrer » aussi souvent, le temps de démarrage est peut-être moins problématique.

Ainsi, de cette manière, une MMDB peut être plus rapide qu'une OODB qui a un contrat différent avec le disque, gérant les journaux et les pages du disque.De cette façon, une OODB peut être plus lente même si la totalité de la base de données s'intègre dans la RAM et est correctement mise en cache, simplement parce que vous effectuez des opérations de disque en dehors des opérations de journalisation pendant les opérations normales, par rapport à une MMDB où ces opérations se produisent en tant que "maintenance". tâche, qui peut être programmée pendant les temps d'arrêt et/ou les temps calmes.

Quant à savoir si l'un ou l'autre de ces systèmes peut répondre à vos besoins réels en matière de performances, je ne peux pas le dire.

Answer 2

Les back-ends des bases de données (processus de lecture et d'écriture, mise en cache, gestion des verrous, fichiers journaux txn, sémantique ACID) sont les mêmes, donc les RDB et ODB sont en fait très similaires ici.La différence réside dans l'interface avec le programmeur d'application.Votre modèle de données est-il compliqué, composé de nombreuses classes avec de véritables relations d'héritage ?Alors OO c'est bien.Est-ce relativement plat et simple ?Alors allez RDB.Quelle est la nature des relations ?Est-ce qu'il ressemble à un pointeur et est défini ?Alors allez RDB.Est-ce plus compliqué, comme une liste (ordonnée), un tableau, une carte ?Alors tu devrais aller OO.De plus, disposez-vous d’une application autonome sans avoir besoin de l’intégrer à d’autres applications ?Alors OO c'est ok.Devez-vous partager des données avec d'autres applications (par ex.plusieurs applications accèdent à la même base de données) ?Ensuite, c’est un facteur décisif pour OO, et vous devriez vous en tenir à RDB.Le schéma de votre base de données est-il stable ou attendez-vous à ce qu’il évolue fréquemment ?Les OODB sont une mauvaise évolution du schéma publicitaire, donc si vous vous attendez à des changements fréquents, restez fidèle aux RDB.