Qu'est-ce qu'un tableau / commandé base de données de recherche?

Question

Je suis à la recherche d'une base de données qui prend en charge les fonctionnalités suivantes:

1) des enregistrements dans la base de données sont comme des dictionnaires Python ou Perl hachages. Par exemple, un dossier « d'achat » pourrait ressembler à ceci:

<purchase 5436> = { product: "BMX Bike", price: 99.50, city: "Springfield" }

2) Les enregistrements sont stockés dans des tableaux de longueur variable. La base de données contient beaucoup de ces tableaux. Par exemple, la table d'achat pourrait ressembler à ceci:

purchase array 1: [ <purchase 5436>, <purchase 54>, <purchase 112> ]
purchase array 2: [ <purchase 76>, <purchase 5984>, <purchase 1102>, <purchase 12> ]
...
purchase array 658: [ <purchase 10142>, <purchase 35>, <purchase 6458>, <purchase 23> ]

3) Je veux être en mesure de faire deux types de requêtes sur cette base de données:

3a) Compter le nombre de dossiers qui correspondent à un divers critères. Par exemple, combien d'achat ont été faites avec une valeur de plus de 50? Je connais beaucoup de bases de données qui prennent en charge cela.

3b) Comptez le nombre de fois les enregistrements apparaissent dans un certain ordre. Par exemple, combien de tableaux sont il y avait un achat de plus de 50 a été faite et un achat dans « Springfield » a été fait? Je ne sais pas quel genre de base de données que vous utilisez pour le faire.

edit: Réponse à Steve Haigh: Je aurais dû mentionner que la vitesse est importante, et cette base de données doit prendre en charge gigaoctets de données. Par exemple, il pourrait y avoir 1000000000 tableaux d'achat, et je veux compter combien d'entre eux ont un achat dans « Springfield » suivi d'un achat dans « Hometown » (notez que l'ordre est important). Peut-être que je me trompe, mais je pense qu'un relationnel DB serait trop lent à cet effet.

Answer 1

Êtes-vous sûr que vous ne pouvez pas faire cela avec un DB relationnelle à l'aide d'un lien ou d'une table jonction?

Vous auriez une colonne de commandes, une colonne de produits et une table commande-produits qui a une ligne pour chaque produit par commande.

Je pense que exprime sans doute mieux que moi pouvait.

Answer 2

  

Par exemple, il pourrait y avoir   1000000000 tableaux d'achat, et je   veulent compter combien d'entre eux ont une   acheter dans « Springfield » suivi   un achat dans « Hometown » (notez que   ordre est important). J'ai peut-être tort,   mais je pense qu'un DB relationnelle serait   trop lent à cet effet.

Ce que vous décrivez sont typiques href="http://en.wikipedia.org/wiki/Data_warehouse" , et ceux-ci sont généralement AFAIK implémentés à l'aide relationnelle DB, mais ceux qui sont optimisés pour des rapports plutôt que pour le traitement des transactions simultanées. Cependant, je ne pense pas que la différence de vitesse sera extrême si vous utilisez un SGBDR « régulier ». Bien sûr, si vous avez assez d'argent, vous pouvez opter pour un SGBD d'entrepôt de données spécial.

L'influence la plus importante sur la vitesse va être le 1) une technologie optimisée pour quering grands ensembles de données sur disque - c'est exactement ce que tout « réel » offre DMBSs et 2) des données organisées dans le droit chemin.

  

3b) Compter le nombre d'enregistrements fois   apparaissent dans un certain ordre. Pour   par exemple, combien de tableaux sont là   ont été fait un achat de plus de 50 et   puis un achat dans « Springfield » était   fabriqué? Je ne sais pas quel genre de   base de données que vous utilisez pour le faire.

Vous utilisez un DB relationnel avec un schéma conçu pour soutenir ce genre de de requête. Vous allez devoir renoncer à votre idée préconçue de la façon dont doivent être représentés les données.

Answer 3

Vous n'avez pas vraiment besoin d'une base de données relationnelle que vous avez juste key-> paires de valeurs groupées dans les collections, vous auriez besoin des jointures entre les deux tables (un pour les enregistrements, un pour les collections) pour itérer les enregistrements d'une la collecte et dans votre cas ne vaut pas le coût.

Pour vos besoins de performance, ce dont vous avez besoin est de faire en sorte que toute la structure tienne en mémoire et ne nécessite pas l'accès au disque. Vous pourriez avoir besoin de plusieurs serveurs pour ce faire, et un maître qui envoie les références externes pour les autres serveurs (en supposant que la taille de votre structure est plus grande que la quantité raisonnable de mémoire qu'un serveur moderne peut gérer, et que vos exigences de vitesse sont si grand que vous ne pouvez pas se permettre de disque pagination.

Pour le genre de questions que vous mentionnez, votre meilleure option est d'avoir un peu de redondance des données. Sur les insertions, vous devez garder une trace de ces chefs d'accusation. tentes de redondance des données à paniquer les gens juste en lisant le nom, mais il est parfois nécessaire. Juste être extrêmement prudent avec votre mise en œuvre et d'investir une bonne quantité de tests unitaires ici.

Il pourrait y avoir, cependant, une sorte de requêtes, que vous ne serez jamais en mesure de le faire en temps réel en quelques millisecondes, et que l'on de trouver des achats avec une condition suivie par des achats avec une autre condition semble être cette. Soit vous trouver un moyen de maintenir un suivi en direct de ce nombre lors de l'insertion / suppression / modification, ou vous devrez parcourir des millions de vos actualy tableaux, aucun moyen d'éviter cela. Vous aurez besoin d'examiner comment vos données récentes doit être, et peut-être pré-calculer toutes les quelques heures pour produire ces statistiques, puis être en mesure d'y accéder en O avec clés de recherche (1).

En un mot, votre problème est bien au-delà de la technologie que vous décidez d'utiliser pour le résoudre.

Answer 4

Je ne suis pas sûr que je comprends tout à fait ce que vous cherchez, mais avez-vous regardé CouchDB ? . Son orientation du document et le schéma libre

Answer 5

Ce que vous décrivez est tout à fait similaire à OREILLONS même si j'ai quelques doutes au sujet de la possibilité de définir des requêtes où l'ordre des « enregistrements » dans les tableaux est possible.

Jetez un oeil sur le lien, il existe des versions commerciales actuelles aussi de ce que vous verrez.