On Fri, Dec 5, 2008 at 7:46 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 11:49 PM, Noble Paul നോബിള് नोब्ळ्
> <[EMAIL PROTECTED]> wrote:
>> Considering the fact that the extra Lucene write is over and above the
>> normal indexing I guess we must compare the cost of indexing
On Thu, Dec 4, 2008 at 11:49 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> Considering the fact that the extra Lucene write is over and above the
> normal indexing I guess we must compare the cost of indexing of 1
> document in luven vs cost of writing one row in a DB.
I'ts one write
On Fri, Dec 5, 2008 at 12:57 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
> <[EMAIL PROTECTED]> wrote:
>> I tried that and the solution looked so clumsy .
>> I need to commit the to read anything was making things difficult
>
> In a high u
On Thu, Dec 4, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> I tried that and the solution looked so clumsy .
> I need to commit the to read anything was making things difficult
In a high update environment, most documents would be exposed to an
open reader with no need
I tried that and the solution looked so clumsy .
I need to commit the to read anything was making things difficult
DB provides me 'immediate' reads .
I am sure performance will be hit anyway.
Is Lucene write much faster than DB (embedded) writes?
http://www.h2database.com/html/performance.html
On
A database, just to store uncommitted documents in case they might be
updated, seems like it will have a pretty major impact on indexing
performance. A lucene-only implementation would seem to be much
lighter on resources.
-Yonik
On Thu, Dec 4, 2008 at 11:32 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL
The solution will be an UpdateRequestProcessor (which itself is
pluggable).I am implementing a JDBC based one. I'll test with H2 and
MySql (and may be Derby)
We will ship the H2 (embedded) jar
On Thu, Dec 4, 2008 at 9:53 PM, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> Again, I would hope that
Again, I would hope that solr builds a storage agnostic solution.
As long as we have a simple interface to load/store documents, it
should be easy to write a JDBC/ehcache/disk/Cassandra/whatever
implementation.
ryan
On Dec 4, 2008, at 10:29 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
Cassan
Cassandra does not meet our requirements.
we do not need that kind of scalability
Moreover its future is uncertain and they are trying to incubate it into Solr
On Thu, Dec 4, 2008 at 8:52 PM, Sami Siren <[EMAIL PROTECTED]> wrote:
> Yet another possibility: http://wiki.apache.org/incubator/Cassan
Yet another possibility: http://wiki.apache.org/incubator/Cassandra
It at least claims to be scalable, no personal experience.
--
Sami Siren
Noble Paul ??? ?? wrote:
Another persistence solution is ehcache with diskstore. It even has replication
I have never used ehcache . So I canno
Another persistence solution is ehcache with diskstore. It even has replication
I have never used ehcache . So I cannot comment on it
any comments?
--Noble
On Wed, Dec 3, 2008 at 8:50 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 5:52 PM, Grant Ingersoll <[E
On Wed, Dec 3, 2008 at 5:52 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
> On Dec 3, 2008, at 1:28 AM, Noble Paul നോബിള് नोब्ळ् wrote:
>
>> The code can be written against JDBC. But we need to test the DDL and
>> data types on al the supported DBs
>>
>> But , which one would we like to ship wi
Also, whatever is chosen needs to scale to millions of documents, and
I wonder about an embedded DB doing that. I also have a hard time
believing that both a DB w/ millions of docs and Solr can live on the
same machine, which is presumably what an embedded DB must do.
Presumably, it also ne
On Dec 3, 2008, at 7:22 AM, Grant Ingersoll wrote:
On Dec 3, 2008, at 1:28 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
The code can be written against JDBC. But we need to test the DDL and
data types on al the supported DBs
But , which one would we like to ship with Solr as a default option?
On Dec 3, 2008, at 1:28 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
The code can be written against JDBC. But we need to test the DDL and
data types on al the supported DBs
But , which one would we like to ship with Solr as a default option?
Why do we need a default option? Is this something th
Noble Paul നോബിള് नोब्ळ् wrote:
The code can be written against JDBC. But we need to test the DDL and
data types on al the supported DBs
But , which one would we like to ship with Solr as a default option?
H2 looks impressive. the jar (small) is just 667KB and the memory
footprint is small to
The code can be written against JDBC. But we need to test the DDL and
data types on al the supported DBs
But , which one would we like to ship with Solr as a default option?
H2 looks impressive. the jar (small) is just 667KB and the memory
footprint is small too
--Noble
On Wed, Dec 3, 2008 at 1
check http://www.h2database.com/ in my view the best embedded DB out
there.
from the maker of HSQLDB... is second round.
However, from anything solr, I would hope it would just rely on JDBC.
On Dec 2, 2008, at 12:08 PM, Shalin Shekhar Mangar wrote:
HSQLDB has a limit of upto 8GB of data.
I shall try to explain the implementation.
Ideally the backup store should keep all fields of all uncommitted docs.
For committed docs, it must store all the non-stored fields and any
field which is a destination of copyField.
The idea of fetching all the stored fields from DB is not right I
gue
On Tue, Dec 2, 2008 at 12:08 PM, Shalin Shekhar Mangar
<[EMAIL PROTECTED]> wrote:
> HSQLDB has a limit of upto 8GB of data. In Solr, you might want to go beyond
> that without a commit.
Ah, so you only use the DB to store the uncommitted docs so you can
quickly reference their fields?
If that's a
HSQLDB has a limit of upto 8GB of data. In Solr, you might want to go beyond
that without a commit.
On Tue, Dec 2, 2008 at 10:33 PM, Dawid Weiss
<[EMAIL PROTECTED]>wrote:
>
> Isn't HSQLDB an option? Its performance ranges a lot depending on the
> volume of data and queries, but otherwise the lice
Isn't HSQLDB an option? Its performance ranges a lot depending on the volume of
data and queries, but otherwise the license looks BSDish.
http://hsqldb.org/web/hsqlLicense.html
Dawid
On Tue, Dec 2, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> OK . Could you guys give some quick feedback on SOLR-828 and SOLR-810
>
> If I get early feedback I may be able to avoid rewrites.
Took a very quick look. Seems like documents should have a version or
revision
OK . Could you guys give some quick feedback on SOLR-828 and SOLR-810
If I get early feedback I may be able to avoid rewrites.
On Tue, Dec 2, 2008 at 10:14 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> OK . So , I'll stick to JDBC. Derby looks like the best bet
>
> If we must ship it
OK . So , I'll stick to JDBC. Derby looks like the best bet
If we must ship it along w/ Solr it is another 2.6MB jar (embdded
version) with the distro.
On Tue, Dec 2, 2008 at 9:35 PM, Jason Rutherglen
<[EMAIL PROTECTED]> wrote:
> It's mostly dead and synchronizes on reads and writes.
>
> On Tue
Jason Rutherglen wrote:
It's mostly dead and synchronizes on reads and writes.
On Tue, Dec 2, 2008 at 7:46 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
Please consider using JDBM, now in the Apache incubator,
It does
It's mostly dead and synchronizes on reads and writes.
On Tue, Dec 2, 2008 at 7:46 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
> > Please consider using JDBM, now in the Apache incubator,
>
> It doesn't look like it's
On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
> Please consider using JDBM, now in the Apache incubator,
It doesn't look like it's in the incubator yet... there was interest,
but a proposal was never put on the wiki.
> but with a long
> history at SF.net and wide us
Yonik Seeley wrote:
On Mon, Dec 1, 2008 at 11:20 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
BDB-JE does not have a a JDBC driver. It has a java API to read/write.
I just looked at this license - unfortunately it has a GPL like clause:
* 3. Redistributions in any form must be ac
On Mon, Dec 1, 2008 at 11:20 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> BDB-JE does not have a a JDBC driver. It has a java API to read/write.
I just looked at this license - unfortunately it has a GPL like clause:
* 3. Redistributions in any form must be accompanied by informati
cool. So we can have a compile time dependency if we wish to do so.
Anyway in the first cut I'll be only coding for JDBC.
And users can be given an option to download and drop in the jar if
they wish to use BDB-JE as the backup option.
My considerations are these w/ the data store.
* Embedded (if
: I just wanted to know if BDB-JE can be given as an option or not.
Lucene-Java has a contrib with a BDB dependency (contrib/db), it just
can't be included in the release.
-Hoss
BDB-JE does not have a a JDBC driver. It has a java API to read/write.
http://www.oracle.com/technology/products/berkeley-db/pdf/performing%20queries%20in%20oracle%20berkeley%20db%20java%20edition.pdf
On Tue, Dec 2, 2008 at 3:52 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> I'm not followi
I'm not following why you would need a compile time dep? Wouldn't
your dependency be on JDBC?
On Dec 1, 2008, at 4:43 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
I guess it is not possible to distribute it w/ apache products because
of the license.
But can we have a compile time dependency ?
On Mon, Dec 1, 2008 at 4:36 PM, Ian Holsman <[EMAIL PROTECTED]> wrote:
> could you use something like derby http://db.apache.org/derby/ or hsqldb ?
> sure... it has a SQL interface, but it might let people use other DB
> backends.
JDBC is definitely there. So HSQLDB is something I have in mind. De
could you use something like derby http://db.apache.org/derby/ or hsqldb ?
sure... it has a SQL interface, but it might let people use other DB
backends.
regards
Ian
On Mon, Dec 1, 2008 at 8:43 PM, Noble Paul നോബിള് नोब्ळ् <
[EMAIL PROTECTED]> wrote:
> I guess it is not possible to distribute
I guess it is not possible to distribute it w/ apache products because
of the license.
But can we have a compile time dependency ?
I may be interested in that for SOLR-828
--
--Noble Paul
37 matches
Mail list logo
