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/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 >> >> 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 <[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 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 <[EMAIL PROTECTED]> >>>>> 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 >>>>>>> <[EMAIL PROTECTED]>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. >>>>>>>> >>>>>>>> http://hsqldb.org/web/hsqlLicense.html >>>>>>>> >>>>>>>> Dawid >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Shalin Shekhar Mangar. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> --Noble Paul >>>>> >>>> >>>> -------------------------- >>>> Grant Ingersoll >>>> >>>> Lucene Helpful Hints: >>>> http://wiki.apache.org/lucene-java/BasicsOfPerformance >>>> http://wiki.apache.org/lucene-java/LuceneFAQ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> --Noble Paul >>> >>> >> >> >> >> > > -- --Noble Paul
