Comment configurer Lucene / Solr pour une application web B2B?

Question

Vu:

• 1 base de données par client (client commercial)
• 5000 clients
• Les clients ont entre 2 à 2000 utilisateurs (moyenne 100 utilisateurs est ~ / client)
• 100k à 10 millions d'enregistrements par base de données
• Les utilisateurs doivent rechercher les enregistrements souvent (c'est la meilleure façon de naviguer leurs données)

Peut-être des informations pertinentes:

• Plusieurs nouveaux clients chaque semaine (en tout temps pendant les heures ouvrables)
• Plusieurs serveurs Web et les serveurs de base de données (les utilisateurs peuvent se connecter via un serveur Web)
• Le agnostique séjour Let de la langue ou de la marque sql, depuis Lucene (et Solr) ont une largeur de soutien

Par exemple:

Joel Spolsky a dit dans Podcast # 11 que son produit application web hébergé, FogBugz On-Demand , utilise Lucene. Il a des milliers de clients à la demande. Et chaque client obtient leur propre base de données.

Ils utilisent index par client et la stocker dans la base de données du client . Je ne sais pas sur les détails. Et je ne suis pas sûr que ce soit un mod grave pour Lucene.

Question:

Comment qualifieriez-vous la configuration de recherche Lucene de sorte que chaque client ne peut effectuer une recherche dans sa base de données?

Comment les index (es) vous de configuration?
Où stocker l'index vous (es)?
Auriez-vous besoin d'ajouter un filtre à toutes les requêtes de recherche?
Si un client a annulé, comment voulez-vous supprimer leur index (une partie)? (Cela peut être trivial - pas encore sûr)

Solutions possibles:

Créer un index pour chaque client (base de données)

• Pro: La recherche est plus rapide (d'un indice pour tous méthode). Les indices sont liés à la taille des données du client.
• Con. Je ne sais pas ce que cela implique, et je ne sais si cela est au-delà de la portée de Lucene

un indice gigantesque unique, avec un champ bdd. Toujours inclure bdd comme un filtre.

• Pro: Je ne sais pas. Peut-être bon pour le support technique ou département de facturation pour rechercher toutes les bases de données pour plus d'informations.
• Con: La recherche est plus lente (que la méthode index par client). sécurité viciée si le filtre de requête supprimé.

Une dernière chose: Je voudrais également accepter une réponse que les utilisations Solr (l'extension de Lucene). Peut-être qu'il est mieux adapté à ce problème. Je ne sais pas.

Answer 1

Vous me convoqua du FogBugz StackExchange. Mon nom est Jude, je suis l'architecte de recherche en cours pour FogBugz.

Voici une esquisse de la façon dont l'architecture de recherche FogBugz On Demand est mis en place [1]:

• Pour des raisons liées à la portabilité des données, la sécurité, etc., nous gardons toutes nos bases de données de la demande et des indices distincts.
• Nous utilisons Lucene (Lucene.NET, en fait), nous avons modded son back-end assez sensiblement pour qu'il puisse stocker son index entièrement dans la base de données. En outre, est maintenue sur chaque sorte que webhost peuvent être évités succès de bases de données inutiles dans un cache local chaque fois que possible.
• Nos filtres sont presque entièrement base de données côté (car ils sont utilisés par les aspects de FogBugz en dehors de la recherche), de sorte que notre requêtes d'analyseur de recherche en texte intégral et les composants non en texte intégral, exécute les recherches et les moissonneuses-batteuses Les resultats. Ceci est un peu malheureux, car il annule de nombreuses optimisations utiles qui Lucene est capable de faire.

Il y a quelques avantages à ce que nous avons fait. La gestion des comptes est assez simple, puisque les données clients et leur index sont stockés au même endroit. Il y a aussi quelques points négatifs, mais, comme un ensemble de cas de bord vraiment embêtants recherches qui sous-performent nos normes minimales. Rétrospectivement, notre recherche était fraîche et bien fait pour son temps. Si je devais le faire à nouveau, cependant, je dissuade cette approche .

Il suffit, à moins que votre domaine de recherche est très spécial ou vous êtes prêt à consacrer un développeur à la recherche rapide blazingly, vous allez probablement être concurrencés par un excellent produit comme ElasticSearch, Solr, ou Xapian.

Si je fais aujourd'hui, à moins que ma recherche domaine était très spécifique, j'utiliser probablement ElasticSearch, Solr, ou Xapian pour ma base de données soutenue par une solution de recherche en texte intégral. Quant à qui, cela dépend de vos besoins auxiliaires (plate-forme, le type de requêtes, la tolérance Extensibilité pour un ensemble de bizarreries sur une autre, etc.)

Sur le thème d'un grand indice par rapport à de nombreux indices dispersés (!): Les deux travaux peuvent. Je pense que la décision vraiment des mensonges avec ce genre d'architecture que vous cherchez à construire, et quel genre de performance que vous avez besoin. Vous pouvez être assez souple si vous décidez qui est raisonnable, mais une fois que vous commencez une réponse de recherche de 2 secondes en disant que tout ce qui dépasse 200ms est inacceptable, vos options commencent à disparaître assez rapidement. Tout en maintenant un index de recherche unique grand pour tous vos clients peut être beaucoup plus efficace de manutention beaucoup de petits indices, il est pas nécessairement plus rapide (comme vous l'avez indiqué). Personnellement, je pense que, dans un environnement sécurisé, l'avantage de garder vos données client séparé ne doit pas être sous-estimée. Lorsque l'index est corrompu, il ne sera pas apporter toute la recherche à l'arrêt; stupides petits bugs ne seront pas exposer des données sensibles; comptes utilisateur séjour il est plus facile modularité d'extraire un ensemble de comptes et les plop sur un nouveau serveur; etc.

Je ne sais pas si cela répond à votre question, mais j'espère que je au moins satisfait votre curiosité: -)

[1]: En 2013, FogBugz a commencé à alimenter ses capacités de recherche et de filtrage avec ElasticSearch. Nous aimons cela.

Answer 2

Shalin Shekhar Mangar m'a répondu sur liste de diffusion Solr utilisateur et par e-mail privé. Shalin est un contributeur à Solr et auteur du livre à venir Solr en action .

Sa réponse sur la liste de diffusion:

Comment voulez-vous configurer l'index (es)?

  

Je regarde la mise en place de plusieurs cœurs pour chaque client. Vous devrez peut-être configurer   esclaves aussi bien en fonction du trafic de recherche.

Où stockez-vous l'index (es)?

  

Mise en place 5K noyaux sur une boîte ne fonctionnera pas. Donc, vous aurez besoin de partition   les clients en plusieurs zones ayant chacune un sous-ensemble de conducteurs.

Auriez-vous besoin d'ajouter un filtre à toutes les requêtes de recherche?

  

Non, mais vous aurez besoin d'envoyer la requête à l'hôte correct (peut-être un   DB cartographie contribuera)

Si un client a annulé, comment voulez-vous supprimer leur (partie du) indice? (Cela peut être trivial - pas encore sûr)

  

Avec différents noyaux pour chaque client, this'd être assez facile.

Sa réponse par e-mail:

  

J'ai travaillé sur un cas d'utilisation similaire dans le passé et nous avons utilisé l'approche multi-core avec quelques optimisations de lourdes sur le côté Solr. Voir http://wiki.apache.org/solr/LotsOfCores - Je ne l'ai pas été capable de pousser ces changements dans Solr encore.

Answer 3

Je ne comprends toujours pas exactement ce que des utilisateurs de bases de données 5K sont à la recherche pour, pourquoi vous avez besoin Lucene, et les tailles de données dans chaque base de données. Mais je vais prendre un grand coup de toute façon:

1. Vous devriez regarder Multicore Solr (chaque noyau = 1 index) et vous avez une URL unique à la requête. L'authentification sera toujours un problème et un (hackish) façon de l'aborder serait de rendre l'URL difficile à deviner.

2. Votre webservers peut interroger l'instance Solr / core en fonction de ce qu'ils ont accès.

Je vous suggère de rester loin de l'approche du filtre et la création d'un index énorme combinant toutes les bases de données.

HTH