Vous n'avez pas vraiment en dire beaucoup sur ce que vous avez à régler votre instance PostgreSQL ou de vos requêtes. Il n'est pas rare de voir un 50x vitesse sur un PostgreSQL requête par le biais de réglage et/ou de réitérer votre requête dans un format qui optimise le mieux.
Juste cette semaine, il y avait un rapport au travail qui quelqu'un avait écrit à l'aide de Java et de plusieurs requêtes dans un chemin qui, en se basant sur la manière dont il avait obtenu dans les quatre heures, allait prendre environ un mois. (Il fallait frapper cinq tables différentes, chacune avec des centaines de millions de lignes.) Je l'ai réécrit en utilisant plusieurs expressions de table communes et une fonction de fenêtre, de sorte qu'il a couru en moins de dix minutes et a généré les résultats escomptés tout droit sorti de la requête. C'est un 4400x vitesse.
Peut-être la meilleure réponse à votre question n'a rien à voir avec les détails techniques de la façon dont les recherches peuvent être effectuées dans chaque produit, mais plus à voir avec la facilité d'utilisation pour votre cas d'utilisation particulier. Clairement, vous avez pu trouver le moyen rapide de recherche avec Solr avec moins de problèmes que PostgreSQL, et il ne peut pas venir vers le bas pour quelque chose de plus.
Je suis notamment un court exemple de la façon dont les recherches de texte pour plusieurs critères pourrait être fait dans PostgreSQL, et comment quelques petits changements peuvent faire une grande différence en termes de performances. Pour le garder simple et rapide, je suis juste la course de la Guerre et de la Paix dans la forme d'un texte dans une base de données de test, à chaque "document" d'une seule ligne de texte. Des techniques similaires peuvent être utilisés pour arbitraire de champs à l'aide de l' hstore type ou JSON colonnes, si les données doivent être vaguement définis. Où il y a plusieurs colonnes, avec leurs propres indices, les avantages de l'utilisation d'index ont tendance à être beaucoup plus grand.
-- Create the table.
-- In reality, I would probably make tsv NOT NULL,
-- but I'm keeping the example simple...
CREATE TABLE war_and_peace
(
lineno serial PRIMARY KEY,
linetext text NOT NULL,
tsv tsvector
);
-- Load from downloaded data into database.
COPY war_and_peace (linetext)
FROM '/home/kgrittn/Downloads/war-and-peace.txt';
-- "Digest" data to lexemes.
UPDATE war_and_peace
SET tsv = to_tsvector('english', linetext);
-- Index the lexemes using GiST.
-- To use GIN just replace "gist" below with "gin".
CREATE INDEX war_and_peace_tsv
ON war_and_peace
USING gist (tsv);
-- Make sure the database has statistics.
VACUUM ANALYZE war_and_peace;
Une fois mis en place, pour l'indexation, je montre quelques recherches avec les nombres de lignes et des horaires avec les deux types d'indices:
-- Find lines with "gentlemen".
EXPLAIN ANALYZE
SELECT * FROM war_and_peace
WHERE tsv @@ to_tsquery('english', 'gentlemen');
84 lignes, gist: 2.006 ms, gin: 0.194 ms
-- Find lines with "ladies".
EXPLAIN ANALYZE
SELECT * FROM war_and_peace
WHERE tsv @@ to_tsquery('english', 'ladies');
184 lignes, gist: 3.549 ms, gin: 0.328 ms
-- Find lines with "ladies" and "gentlemen".
EXPLAIN ANALYZE
SELECT * FROM war_and_peace
WHERE tsv @@ to_tsquery('english', 'ladies & gentlemen');
1 ligne, gist: 0.971 ms, gin: 0.104 ms
Maintenant, depuis le GIN indice était environ 10 fois plus rapide que l'Essentiel index vous pourriez vous demander pourquoi quelqu'un voudrait utiliser GiST pour l'indexation des données de texte. La réponse est que le GiST est généralement plus rapide à entretenir. Donc, si vos données de texte est très volatile, l'Essentiel de l'indice pourrait gagner sur l'ensemble de la charge, tandis que le GIN indice permettrait de gagner si vous êtes seulement intéressé dans le temps de recherche, ou pour une lecture principalement de la charge de travail.
Sans l'indice ci-dessus requêtes prendre n'importe où à partir de 17.943 ms à 23.397 ms car ils doivent numériser l'ensemble de la table et de vérifier pour un match sur chaque ligne.
Le GIN indexé de recherche pour les lignes avec les deux "dames" et "messieurs" est de plus de 172 fois plus rapide que l'analyse d'une table, exactement de la même base de données. De toute évidence les avantages de l'indexation est de plus en plus dramatique avec plus de documents que ceux qui ont été utilisés pour ce test.
L'installation est, bien sûr, une chose une seule fois. Avec un seuil de déclenchement de maintenir l' tsv colonne, toutes les modifications apportées seraient instantanément être consultée sans refaire toute l'installation.
Avec la lenteur de la requête PostgreSQL, si vous montrez de la structure de la table (y compris index), le problème de la requête, et le résultat de l'exécution de EXPLAIN ANALYZE de votre question, quelqu'un peut presque toujours de repérer le problème et de suggérer comment le faire courir plus vite.
