On Oct 2, 2008, at 9:41 AM, agatone wrote:
Now I have to go detailed into every one of them and write down stuff.
Couple of handy guidelines:
http://www.w3.org/DesignIssues/Principles.html
E.g. "Principle of Least Power" :)
Cheers,
--
PA.
http://alt.textdrive.com/nanoki/
Thank you all for your replies.
I didn't expect so many of them - all appreciated.
Now I have to go detailed into every one of them and write down stuff.
Thank you again.
--
View this message in context:
http://www.nabble.com/Lucene-vs.-Database-tp19755932p19774692.html
Sent from the L
On Oct 1, 2008, at 9:43 AM, agatone wrote:
I'm working on a project that has big database in the background (some
tables have about 150 rows). We decided to use Lucene for "faster"
search. Our search works similar as all searches: you write search
string,
get list of hits with detail link
Mathieu:
> Crawling a DB is not a good idea. Indexing while writing/deleting is
> clever.
These operations also consume network traffic in architectures like Solr WS.
Also there is a waste of network traffic when a query is filtered
against relational data (slides 15 and 18 of Google presentati
Another thing you could consider is that rather than meshing all this
data into a single index, logically break out the data you need for
searching into one index, and the data you need for display into another
index.
This is the technique we use here and its been wildly successful for us,
as
be drawbacks and advantages of both approaches.
>> Actually can someone write down what's the actual profit, where and when
> of
>> the Lucene itself in real production env.
>>
>> IT would be great if there is anyone who could write his experience with
>> indexing and
both approaches.
> Actually can someone write down what's the actual profit, where and when of
> the Lucene itself in real production env.
>
> IT would be great if there is anyone who could write his experience with
> indexing and searching large amount of data.
>
>
Have a look at Compass : http://www.compass-project.org/
It's one of the easyest way to mix db and lucene.
M.
On Wed, 1 Oct 2008 00:43:57 -0700 (PDT), agatone <[EMAIL PROTECTED]>
wrote:
>
> Hi,
> I asked this question already on "lucene-general" list but also got
> advised
> to ask here too.
>
e please describe drawbacks and advantages of both approaches.
> Actually can someone write down what's the actual profit, where and when
> of the Lucene itself in real production env.
>
> IT would be great if there is anyone who could write his experience with
>
Pros of keeping content only in the database
* Need only one stored copy of data (saved disk space)
Pros of storing copy of content in Lucene:
* A match is more easily explained
If you collapse multiple DB fields into a single searchable field e.g.
customer first name and surname database fiel
gt; IT would be great if there is anyone who could write his experience with
> indexing and searching large amount of data.
>
>
> Thank you
> --
> View this message in context:
> http://www.nabble.com/Lucene-vs.-Database-tp19755932p19755932.html
> Sent from the Lucene
when of
the Lucene itself in real production env.
IT would be great if there is anyone who could write his experience
with
indexing and searching large amount of data.
Thank you
--
View this message in context:
http://www.nabble.com/Lucene-vs.-Database-tp19755932p19755932.html
Sent from the Lucene -
e write down what's the actual profit, where and when of
the Lucene itself in real production env.
IT would be great if there is anyone who could write his experience with
indexing and searching large amount of data.
Thank you
--
View this message in context:
http://www.nabble.com/Lucene-vs
Agree with Nick that Jing's task doesn't really need Lucene if mostly
range search is needed. Database is good for range search.
But for his search on 'Select * from table where Name like
"%mymymy%"'. It's not a scalable solution for database. And using
Lucene makes a lot of sense.
The easiest wa
I think this should be a new thread since it's a different problem.
Based on your description, I don't see any compelling reasons for you to
use Lucene just for indexing purposes, since you are not indexing text
docs as you indicated. Claiming database of lacking performance is not
accurate and o
Performance wise, Lucene search is much faster for full-text search.
If you only do "Employee ID" search, or exact match of Names,
database's search can do a good job already.
If it's regarding the index maintenance, you should have a updated_at
column for each record, and select the latest recor
Hi,
I have an application. It has large number of records around (1.2 million)
with a possibility of doubling every year. The average records being added per
day is around 3000 distributed over the day. The inserted record has to be
searchable immediately once it is entered into the databa
17 matches
Mail list logo
