|Noble Paul നോബിള് नोब्ळ्||Dec 1, 2008 1:42 am|
|Ian Holsman||Dec 1, 2008 3:05 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 1, 2008 3:14 am|
|Grant Ingersoll||Dec 1, 2008 2:21 pm|
|Noble Paul നോബിള് नोब्ळ्||Dec 1, 2008 8:20 pm|
|Chris Hostetter||Dec 1, 2008 9:24 pm|
|Noble Paul നോബിള് नोब्ळ्||Dec 1, 2008 10:02 pm|
|Yonik Seeley||Dec 2, 2008 6:29 am|
|Andrzej Bialecki||Dec 2, 2008 7:11 am|
|Yonik Seeley||Dec 2, 2008 7:45 am|
|Jason Rutherglen||Dec 2, 2008 8:05 am|
|Andrzej Bialecki||Dec 2, 2008 8:41 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 2, 2008 8:44 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 2, 2008 8:46 am|
|Yonik Seeley||Dec 2, 2008 9:02 am|
|Dawid Weiss||Dec 2, 2008 9:03 am|
|Shalin Shekhar Mangar||Dec 2, 2008 9:08 am|
|Yonik Seeley||Dec 2, 2008 9:25 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 2, 2008 10:12 am|
|Ryan McKinley||Dec 2, 2008 9:00 pm|
|Noble Paul നോബിള് नोब्ळ्||Dec 2, 2008 10:28 pm|
|Andrzej Bialecki||Dec 3, 2008 2:59 am|
|Grant Ingersoll||Dec 3, 2008 4:22 am|
|Ryan McKinley||Dec 3, 2008 5:43 am|
|Mark Miller||Dec 3, 2008 5:47 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 3, 2008 7:19 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 4, 2008 12:43 am|
|Sami Siren||Dec 4, 2008 7:20 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 4, 2008 7:29 am|
|Ryan McKinley||Dec 4, 2008 8:22 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 4, 2008 8:32 am|
|Yonik Seeley||Dec 4, 2008 8:37 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 4, 2008 8:47 am|
|Yonik Seeley||Dec 4, 2008 11:26 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 4, 2008 8:49 pm|
|Yonik Seeley||Dec 5, 2008 6:16 am|
|Noble Paul നോബിള് नोब्ळ्||Dec 5, 2008 8:45 am|
|Subject:||Re: Can we use Berkley DB java in Solr|
|From:||Noble Paul നോബിള് नोब्ळ् (nobl...@gmail.com)|
|Date:||Dec 4, 2008 8:32:17 am|
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 <ryan...@gmail.com> wrote:
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.
On Dec 4, 2008, at 10:29 AM, Noble Paul നോബിള് नोब्ळ् wrote:
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 <ssi...@gmail.com> wrote:
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 cannot comment on it
On Wed, Dec 3, 2008 at 8:50 PM, Noble Paul ??????? ?????? <nobl...@gmail.com> wrote:
On Wed, Dec 3, 2008 at 5:52 PM, Grant Ingersoll <gsin...@apache.org> 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?
Why do we need a default option? Is this something that is intended to be on by default? Or, do you mean just to have one for unit tests to work?
Default does not mean that it is enabled bby default. But if it is enabled I can have defaults for stuff like driver, url , DDL etc. And the user may not need to provide an extra jar
I don't know if it is still the case, but I often find embedded dbs to be quite annoying since you often can't connect to them from other clients outside of the JVM which makes debugging harder. Of course, maybe I just don't know the tricks to do it. Derby is one DB that you can still connect to even when it is embedded.
Embedded is the best bet for us because of performance reasons and zero management. The users can still read the data through Solr itself .
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 needs to be able to be replicated, right?
millions of docs.? then you must configure a remote DB for storage reasons and must manage the replication separately
H2 looks impressive. the jar (small) is just 667KB and the memory footprint is small too --Noble
On Wed, Dec 3, 2008 at 10:30 AM, Ryan McKinley <ryan...@gmail.com> wrote:
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. In Solr, you might want to go beyond that without a commit.
On Tue, Dec 2, 2008 at 10:33 PM, Dawid Weiss <dawi...@cs.put.poznan.pl>wrote:
Isn't HSQLDB an option? Its performance ranges a lot depending on the volume of data and queries, but otherwise the license looks BSDish.
-- Regards, Shalin Shekhar Mangar.
-- --Noble Paul
-------------------------- Grant Ingersoll
-- --Noble Paul
-- --Noble Paul
-- --Noble Paul