MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Graph DBs vs Document DBs vs Triplestores

Je ne suis pas sûr d'être d'accord avec le sentiment que beaucoup de gens n'aiment pas SPARQL. SPARQL 1.0 avait quelques défauts, mais il répondait assez bien à ce pour quoi il avait été conçu, et la nouvelle itération, SPARQL 1.1, s'appuie sur elle en ajoutant de nombreuses constructions de SQL que les gens s'attendaient à voir dans la spécification d'origine, y compris les sous-requêtes, les agrégats &mettre à jour la sémantique. Je pense que le fait qu'il soit standard et que vous puissiez vous attendre à voir la même analyse et la même sémantique dans chaque triple magasin, par opposition aux dialectes de SQL, est une fonctionnalité intéressante.

Je dirais également que tous les triple stores sont des bases de données de graphes; vous pouvez mettre des propriétés sur des bords spécifiques dans RDF, mais pas aussi bien que vous le pouvez avec Neo4j. Mais les magasins triples ont l'avantage d'un vrai langage de requête, une représentation de données standard w3c qui rend trivial le transfert de vos données vers un autre triple magasin, et pour un certain nombre de magasins triples, la possibilité d'effectuer un raisonnement basé sur OWL.

Je ne sais rien de l'évolutivité de la plupart des bases de données graphiques, mais en général, les bases de données RDF commerciales évoluent assez bien. Tous peuvent évoluer en milliards de triplets, ce qui gère un grand nombre de cas d'utilisation. Bien que la façon dont ils gèrent l'échelle diffère énormément d'un fournisseur à l'autre en ce qui concerne la mise à l'échelle ou la mise à l'échelle, le clustering, etc. Vous verrez également des exigences de mémoire et de matériel assez différentes pour correspondre aux implémentations de chacun. Pour moi, j'ai eu tendance à simplement aller chercher une instance EC2, généralement une 2XL ou 4XL, monter un EBS assez grand pour contenir les données, et je suis plutôt bien préparé.

De plus, certains magasins triples s'intègrent à Lucene ou à des technologies similaires pour fournir des index inversés sur les données, et beaucoup commencent maintenant à inclure des index géospatiaux et temporels. Ce sont des fonctionnalités très utiles dont je ne suis pas sûr de la disponibilité dans quelque chose comme Neo4j.

Cela dit, ils ne vont pas évoluer aussi bien que les bases de données relationnelles, ils ne sont tout simplement pas aussi matures. Mais vous n'allez pas non plus vous faire avoir lorsque vous avez de "vraies" quantités de données non plus. Bien sûr, l'un des avantages des magasins triples est le raisonnement, dont la performance à grande échelle est délicate, mais c'est en grande partie la raison pour laquelle les différents profils OWL ont été créés. Mais vous pouvez vous mettre dans un coin si vous ne pensez pas à l'avance.

Je pense que les bases de données de graphes, en particulier les magasins triples, peuvent convenir assez bien à de nombreuses applications en cours de construction, mais je ne pense pas que cela signifie que tout devrait être fait avec elles. Comme toute autre chose, ce sont des outils avec leurs bons et leurs mauvais points, vous devez donc en quelque sorte faire le bon choix en fonction de votre application. Mais ils méritent probablement toujours au moins une considération de nos jours.