Les données hiérarchiques et BerkeleyDB

Question

Bonnes nouvelles! Depuis la version 4.8 BerkeleyDB possède une interface c #. BerkeleyDB est une chose tout à fait intéressant pour moi en raison de sa nature non-SQL. Je sais qu'il est un excellent outil si quelqu'un veut stocker un grand nombre de paires clé / valeur. Et je sais que sur les tables « connectables ». Ce que je ne sais pas comment stocker des données hiérarchiques avec BerkeleyDB. Est-il approprié pour cela en général?

Qu'est-ce que je veux faire? Je veux stocker des données dmoz.org. Maintenant, j'ai tous rdfs thous importés db MySQL. Mais je ne ai pas besoin de procédures stockées ou une autre des caractéristiques complexes. Je veux utiliser BerkeleyDB comme un magasin de données pour mon lecteur RSS en ligne. Donc, il y a des flux dans un arbre de catégorie (comme je l'ai dit catégories que j'ai importé de DMOZ et j'ai beaucoup d'entre eux, ainsi que des flux -. Millions). Et ... j'ai oublié sur les éléments d'alimentation. Je veux les stocker trop avec BerkleyDB :-).

Il est ressembler à je dois mettre en œuvre toutes les relations manuellement ,,, Il est ok ... Mais la chose la plus importante que je demande au sujet de la vitesse. Est-ce que (peut) ma solution avec BerkeleyDB plus rapide puis un basé sur MySQL (ou sur des SGBDR en général)?

Answer 1

Il convient pour cela, mais il peut être plus de travail que vous êtes prêt à mettre en. BerkeleyDB est une clé très générale / magasin de valeur, donc tout ce que vous faites est à dire « pour la touche X, la valeur du magasin Y ». Plus tard, vous pouvez dire « donnez-moi la valeur de la clé X » et il vous redonneront Y. C'est vraiment tout ce qu'il fait d'un niveau élevé. Il a des caractéristiques très robustes pour garantir des propriétés importantes de fiabilité (appelé acide, pour atomicité, cohérence, isolation et durabilité), et a une grande performance, mais du point de vue du programmeur, il est une structure simple de la carte.

Alors oui, vous pouvez stocker des arbres, mais vous auriez besoin de se prononcer sur une bonne représentation pour eux. Vous pouvez aller pour les clés entiers (assurez-vous qu'ils sont stockés dans le grand-endian parce que BDB utilise l'ordre lexicographique sur les touches) et ont simplement une structure comme la valeur contenant une liste d'entiers pour les enfants. Vous auriez encore écrire tous vos algorithmes traversal à la main, bien que. Sans savoir quelles sont les exigences que vous avez pour vos données hiérarchique cependant, il est difficile de donner une suggestion plus concrète.

speedwise, pour ce qu'il fait Berkeley DB probablement ne peut pas obtenir beaucoup plus rapidement (par exemple, vous ne trouverez pas beaucoup là-bas qui est plus rapide, surtout si vous êtes prêt à sacrifier quelques-unes des propriétés ACID). Il vous donne un contrôle presque complet sur votre interface à la carte, donc en théorie vous pourriez probablement construire une structure hautement optimisée pour votre cas d'utilisation particulière. Cependant, compte tenu de l'interface de bas niveau, si vous implémentez les jointures, les requêtes de filtrage complexes, ou tout autre type de langage de requête non négligeable sur le dessus de celui-ci, vous devrez écrire un code très rapide et des algorithmes pour suivre le grand bases de données relationnelles sur le marché.

Si vos données peuvent être modélisées par XML (CJE, mais je sais que certaines personnes aiment), il y a une base de données existante construite au-dessus de BDB appelé XML BDB (aussi par Sleepycat, fait maintenant partie d'Oracle). Cela vous permet de stocker des documents XML arbitraires dans la base de données et d'effectuer des requêtes XPath et XQuery rapide sur la base de données. Je ne pense pas qu'il y ait une API .NET officielle à ce moment, mais je suis sûr que je suis venu dans un .NET non officiel se liant à elle.

En général, sauf si vous avez des exigences très particulières que les solutions existantes là-bas ne permettent pas (cela ne semble pas être le cas avec votre scénario), je vous conseille de se mettre à rouler votre propre base de données (même construit sur le dessus de BDB), sauf si vous êtes très habile avec des algorithmes efficaces et optimisation de code. Si vous stockez triplets RDF, il existe des bases de données dédiées à cela, et même des bases de données relationnelles ne sont pas particulièrement inadaptées pour eux. BDB XML est encore une solution viable pour cela aussi. Il est finalement votre choix, mais si je vous je choisirais de travailler sur les problèmes les plus intéressants sans avoir à faire face à des opérations de base de données à faible niveau (et serait donc utiliser une couche mince sur paquet existant pour mon magasin de RDF réelle).

Answer 2

Les structures hiérarchiques peuvent être stockés dans les magasins à valeur clé à l'aide d'un attribut parent ou un enfant.

Si vous voulez un parent d'avoir 1 ou plusieurs enfants, utilisez un attribut parent sur chaque enregistrement et ont des nœuds racine ont un parent d'ID 0 ou une autre valeur significative.

Si vous voulez un enfant d'avoir 1 ou plus de parents, utilisez un attribut enfant sur chaque enregistrement.

Si vous voulez des noeuds peuvent avoir plusieurs parents, et les enfants utilisent une table séparée pour stocker les relations.

De cette façon, vous pouvez parcourir l'arborescence en interrogeant par des noeuds qui ont un certain parent ou un enfant.