Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B8693DEFF for ; Wed, 4 Jul 2012 08:09:56 +0000 (UTC) Received: (qmail 92321 invoked by uid 500); 4 Jul 2012 08:09:53 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 92274 invoked by uid 500); 4 Jul 2012 08:09:53 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 92245 invoked by uid 99); 4 Jul 2012 08:09:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 08:09:52 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [212.227.126.186] (HELO moutng.kundenserver.de) (212.227.126.186) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 08:09:46 +0000 Received: from [192.168.178.32] (p5DDEC252.dip0.t-ipconnect.de [93.222.194.82]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0MZ6Ot-1SGaVE1wR9-00VjJy; Wed, 04 Jul 2012 10:09:23 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Use of Solr as primary store for search engine From: Paul Libbrecht In-Reply-To: Date: Wed, 4 Jul 2012 10:09:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B5F9E9F-C933-4AE4-BDE0-9AF762E5343C@hoplahup.net> References: To: solr-user@lucene.apache.org X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:34TGKiRMyMKJmU7c8eEPAupjPMTX26AEb8lqfMk+BK9 nfxlx8sPFZR2FbajAKC6sAcnyG22Yq44LC4r/qV+IXFUpZb6VO xnMPvJSj/vu3VUqY2o0TIgeKywZw4w5kTux3qC8yGIE5zb/nf8 PoHfYtPked+eS0yplaO49V2Ap/Y1X3rwt+Pc1uk1Jt0Heq/6Rg B/z7O9JZ57cUrkRhzzxYrCsksVW3as/0sq25WFKxz7167MXA84 Mfn35iDccxZ8UTKE+LQWn4sWrO/s9Qyq+lVw3yljs2BpgFjq6a hR3K27Rrtn1bUgrR66eaAzb47/oEjZHpHSP6EiwQV1BLE7g7qy P3dX9Vbz04791sUiQIDsj/+jCmokB8oOpJA0POZoSr0+grXiSb ckwgKzhVJ3etw== X-Virus-Checked: Checked by ClamAV on apache.org Amit, not exactly a response to your question but doing this with a lucene = index on i2geo.net has resulted in considerably performance boost = (reading from stored-fields instead of reading from the xwiki objects = which pull from the SQL database). However, it implied that we had to = rewrite anything necessary for the rendering, hence the rendering has = not re-used that many code. Paul Le 4 juil. 2012 =E0 09:54, Amit Nithian a =E9crit : > Hello all, >=20 > I am curious to know how people are using Solr in conjunction with > other data stores when building search engines to power web sites (say > an ecommerce site). The question I have for the group is given an > architecture where the primary (transactional) data store is MySQL > (Oracle, PostGres whatever) with periodic indexing into Solr, when > your front end issues a search query to Solr and returns results, are > there any joins with your primary Oracle/MySQL etc to help render > results? >=20 > Basically I guess my question is whether or not you store enough in > Solr so that when your front end renders the results page, it never > has to hit the database. The other option is that your search engine > only returns primary keys that your front end then uses to hit the DB > to fetch data to display to your end user. >=20 > With Solr 4.0 and Solr moving towards the NoSQL direction, I am > curious what people are doing and what application architectures with > Solr look like. >=20 > Thanks! > Amit