Dans un projet que je suis en train de travailler, le client dispose d'un une ancienne et massive(téraoctet de gamme) SGBDR. Les requêtes de toutes sortes sont lents et il n'y a pas de temps à corriger/refactoriser le schéma. J'ai identifié les ensembles de requêtes communes qui doivent être optimisés. Cet ensemble est divisé en deux: le texte intégral et les métadonnées de requêtes.
Mon plan est d'extraire les données à partir de leur base de données et la partition à travers deux différents systèmes de stockage de chaque optimisé pour une requête particulière définie.
Pour la recherche de texte intégral, Solr est un moteur qui a plus de sens. C'est la fragmentation et la réplication en font un grand ajustement pour la moitié du problème.
Pour les métadonnées de requêtes, je ne suis pas sûr de ce que la route à prendre. Actuellement, je suis en train de penser à l'aide d'un SGBDR avec extrêmement de-schéma normalisé qui représente un sous-ensemble particulier de données à partir de la "foi" des SGBDR. Cependant, mon client est préoccupé par l'absence de la fragmentation et de la réplication de ces sous-système et de la difficulté/complications de réglage des caractéristiques telles que la comparaison avec Solr, qui comprend déjà entre eux. Les métadonnées dans ce cas, prend la forme de nombres entiers, les dates, les booléens, les bits, et les chaînes de caractères(avec la taille max de 10chars).
Est-il une base de données un système de stockage intégré dans la fragmentation et de la réplication peut être particulièrement utile pour la requête a dit métadonnées? Peut-être un no-sql solution qui fournit un bon moteur de recherche?
Éclairer s'il vous plaît.
Ajouts/Réponses:
Solr peut être utilisé pour les métadonnées, toutefois, les métadonnées ne sont pas volatiles. Par conséquent, je voudrais avoir à s'engager souvent à l'index. Ce serait la cause de la recherche à se dégrader assez vite.
