You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Francesco Viscomi <fv...@gmail.com> on 2017/08/04 23:16:24 UTC
MongoDb vs Solr
Hi all,
why i have to choose solr if mongoDb is easier to learn and to use?
Both are NoSql database, is there a good reason to chose solr and not
mongoDb?
thanks really much
--
Ing. Viscomi Francesco
Re: MongoDb vs Solr
Posted by Walter Underwood <wu...@wunderwood.org>.
People who want to use Solr as a database should understand that it does not satisfy the ACID properties. It doesn’t have atomicity, because if some documents in a batch fail, the rest will still be committed. It doesn’t have isolation, one commit will submit all pending updates. Not sure about durability, but Solr is generally not considered to be durable across crashes or “kill -9”.
https://en.wikipedia.org/wiki/ACID
Also, there is no explicit schema migration support. Schema changes usually require a full reload from the repository.
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Aug 5, 2017, at 9:51 AM, Peter Sturge <pe...@gmail.com> wrote:
>
> *And insults are not something I'd like to see in this mailing list, at all*
> +1
> Everyone is entitled to their opinion..
>
> Solr can and does work extremely well as a database - it depends on your db
> requirements.
> For distributed/replicated search via REST API that is read heavy, Solr is
> a great choice.
>
> If you need joins or stored procedure-like functionality, don't choose any
> of the mentioned ones - stick with SQL.
>
> Security-wise, Solr is pretty much like all db access tools - you will need
> a robust front-end to keep your data secure.
> It's just that with an easy-to-use API like Solr, it's easier to
> accidentally 'let it run free'. If you're using Solr for db rather than
> search, you will need a secure front-end.
>
> Joy and good will to all, regardless of what tool you choose!
>
> Peter
>
>
> On Sat, Aug 5, 2017 at 5:08 PM, Walter Underwood <wu...@wunderwood.org>
> wrote:
>
>> I read the seven year old slides just now. The Guardian was using Solr to
>> deliver the content. Their repository (see slide 38) is an RDBMS.
>>
>> https://www.slideshare.net/matwall/no-sql-at-the-guardian
>>
>> In slide 37, part of “Is Solr a database?”, they note “Search index not
>> really persistence”. To me, that means “not a database”.
>>
>> wunder
>> Walter Underwood
>> wunder@wunderwood.org
>> http://observer.wunderwood.org/ (my blog)
>>
>>
>>> On Aug 5, 2017, at 4:59 AM, Dave <ha...@gmail.com> wrote:
>>>
>>> And to add to the conversation, 7 year old blog posts are not a reason
>> to make decisions for your tech stack.
>>>
>>> And insults are not something I'd like to see in this mailing list, at
>> all, so please do not repeat any such disrespect or condescending
>> statements in your contributions to the mailing list that's supposed to
>> serve as a source of help, which, you asked for.
>>>
>>>> On Aug 5, 2017, at 7:54 AM, Dave <ha...@gmail.com> wrote:
>>>>
>>>> Also I wouldn't really recommend mongodb at all, it should only to be
>> used as a fast front end to an acid compliant relational db same with
>> memcahed for example. If you're going to stick to open source, as I do, you
>> should use the correct tool for the job.
>>>>
>>>>> On Aug 5, 2017, at 7:32 AM, GW <th...@gmail.com> wrote:
>>>>>
>>>>> Insults for Walter only.. sorry..
>>>>>
>>>>>> On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
>>>>>>
>>>>>> For The Guardian, Solr is the new database | Lucidworks
>>>>>> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&
>> cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=
>> https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-
>> guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_
>> vtL8A>
>>>>>> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
>>>>>> is-the-new-database/
>>>>>> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I
>> blogged
>>>>>> a few days ago about how open search source is disrupting the
>> relationship
>>>>>> between ...
>>>>>>
>>>>>> You are arrogant and probably lame as a programmer.
>>>>>>
>>>>>> All offense intended
>>>>>>
>>>>>>> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>>>>>>>
>>>>>>> Watch their videos....
>>>>>>>
>>>>>>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> MarkLogic can do many-to-many. I worked there six years ago. They
>> use
>>>>>>>> search engine index structure with generational updates, including
>> segment
>>>>>>>> level caches. With locking. Pretty good stuff.
>>>>>>>>
>>>>>>>> A many to many relationship is an intersection across posting lists,
>>>>>>>> with transactions. Straightforward, but not easy to do it fast.
>>>>>>>>
>>>>>>>> The “Inside MarkLogic Server” paper does a good job of explaining
>> the
>>>>>>>> guts.
>>>>>>>>
>>>>>>>> Now, back to our regularly scheduled Solr presentations.
>>>>>>>>
>>>>>>>> wunder
>>>>>>>> Walter Underwood
>>>>>>>> wunder@wunderwood.org
>>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Also, id love to see an example of a many to many relationship in a
>>>>>>>> nosql db as you described, since that's a rdbms concept. If it
>> exists in a
>>>>>>>> nosql environment I would like to learn how...
>>>>>>>>>
>>>>>>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Uhm. Dude are you drinking?
>>>>>>>>>>
>>>>>>>>>> 1. Lucidworks would never say that.
>>>>>>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
>>>>>>>> source version of MySQL before oracle bought them
>>>>>>>>>> 3.walter is 100% correct. Solr is search. The only complex data
>>>>>>>> structure it has is an array. Something like mongo can do arrays
>> hashes
>>>>>>>> arrays of hashes etc, it's actually json based. But it can't search
>> well as
>>>>>>>> a search engine can.
>>>>>>>>>>
>>>>>>>>>> There is no one tool. Use each for their own abilities.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The people @ Lucidworks would beg to disagree but I know exactly
>>>>>>>> what you
>>>>>>>>>>> are saying Walter.
>>>>>>>>>>>
>>>>>>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>>>>>>> noSQL DB.
>>>>>>>>>>> I like to express it as knowing when to fish and when to cut
>> bait.
>>>>>>>> As soon
>>>>>>>>>>> as you are in the one - many or many - many world a real DB is a
>>>>>>>> whole lot
>>>>>>>>>>> more sensible.
>>>>>>>>>>>
>>>>>>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and
>> you've
>>>>>>>> got a
>>>>>>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long
>> time
>>>>>>>> but It
>>>>>>>>>>> just does not compare to Solr. Put the two together and you've
>> got
>>>>>>>> some
>>>>>>>>>>> serious magic.
>>>>>>>>>>>
>>>>>>>>>>> No offense intended, There's nothing wrong with being 97.5%
>> correct.
>>>>>>>> I wish
>>>>>>>>>>> I could be 97.5% correct all the time. :-)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <
>> wunder@wunderwood.org>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Solr is NOT a database. If you need a database, don’t choose
>> Solr.
>>>>>>>>>>>>
>>>>>>>>>>>> If you need both a database and search, choose MarkLogic.
>>>>>>>>>>>>
>>>>>>>>>>>> wunder
>>>>>>>>>>>> Walter Underwood
>>>>>>>>>>>> wunder@wunderwood.org
>>>>>>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <
>> fviscomi@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to
>> use?
>>>>>>>>>>>>> Both are NoSql database, is there a good reason to chose solr
>> and
>>>>>>>> not
>>>>>>>>>>>>> mongoDb?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks really much
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Ing. Viscomi Francesco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>
>>
Re: MongoDb vs Solr
Posted by Peter Sturge <pe...@gmail.com>.
*And insults are not something I'd like to see in this mailing list, at all*
+1
Everyone is entitled to their opinion..
Solr can and does work extremely well as a database - it depends on your db
requirements.
For distributed/replicated search via REST API that is read heavy, Solr is
a great choice.
If you need joins or stored procedure-like functionality, don't choose any
of the mentioned ones - stick with SQL.
Security-wise, Solr is pretty much like all db access tools - you will need
a robust front-end to keep your data secure.
It's just that with an easy-to-use API like Solr, it's easier to
accidentally 'let it run free'. If you're using Solr for db rather than
search, you will need a secure front-end.
Joy and good will to all, regardless of what tool you choose!
Peter
On Sat, Aug 5, 2017 at 5:08 PM, Walter Underwood <wu...@wunderwood.org>
wrote:
> I read the seven year old slides just now. The Guardian was using Solr to
> deliver the content. Their repository (see slide 38) is an RDBMS.
>
> https://www.slideshare.net/matwall/no-sql-at-the-guardian
>
> In slide 37, part of “Is Solr a database?”, they note “Search index not
> really persistence”. To me, that means “not a database”.
>
> wunder
> Walter Underwood
> wunder@wunderwood.org
> http://observer.wunderwood.org/ (my blog)
>
>
> > On Aug 5, 2017, at 4:59 AM, Dave <ha...@gmail.com> wrote:
> >
> > And to add to the conversation, 7 year old blog posts are not a reason
> to make decisions for your tech stack.
> >
> > And insults are not something I'd like to see in this mailing list, at
> all, so please do not repeat any such disrespect or condescending
> statements in your contributions to the mailing list that's supposed to
> serve as a source of help, which, you asked for.
> >
> >> On Aug 5, 2017, at 7:54 AM, Dave <ha...@gmail.com> wrote:
> >>
> >> Also I wouldn't really recommend mongodb at all, it should only to be
> used as a fast front end to an acid compliant relational db same with
> memcahed for example. If you're going to stick to open source, as I do, you
> should use the correct tool for the job.
> >>
> >>> On Aug 5, 2017, at 7:32 AM, GW <th...@gmail.com> wrote:
> >>>
> >>> Insults for Walter only.. sorry..
> >>>
> >>>> On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
> >>>>
> >>>> For The Guardian, Solr is the new database | Lucidworks
> >>>> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&
> cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=
> https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-
> guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_
> vtL8A>
> >>>> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
> >>>> is-the-new-database/
> >>>> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I
> blogged
> >>>> a few days ago about how open search source is disrupting the
> relationship
> >>>> between ...
> >>>>
> >>>> You are arrogant and probably lame as a programmer.
> >>>>
> >>>> All offense intended
> >>>>
> >>>>> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
> >>>>>
> >>>>> Watch their videos....
> >>>>>
> >>>>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
> >>>>> wrote:
> >>>>>
> >>>>>> MarkLogic can do many-to-many. I worked there six years ago. They
> use
> >>>>>> search engine index structure with generational updates, including
> segment
> >>>>>> level caches. With locking. Pretty good stuff.
> >>>>>>
> >>>>>> A many to many relationship is an intersection across posting lists,
> >>>>>> with transactions. Straightforward, but not easy to do it fast.
> >>>>>>
> >>>>>> The “Inside MarkLogic Server” paper does a good job of explaining
> the
> >>>>>> guts.
> >>>>>>
> >>>>>> Now, back to our regularly scheduled Solr presentations.
> >>>>>>
> >>>>>> wunder
> >>>>>> Walter Underwood
> >>>>>> wunder@wunderwood.org
> >>>>>> http://observer.wunderwood.org/ (my blog)
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Also, id love to see an example of a many to many relationship in a
> >>>>>> nosql db as you described, since that's a rdbms concept. If it
> exists in a
> >>>>>> nosql environment I would like to learn how...
> >>>>>>>
> >>>>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Uhm. Dude are you drinking?
> >>>>>>>>
> >>>>>>>> 1. Lucidworks would never say that.
> >>>>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
> >>>>>> source version of MySQL before oracle bought them
> >>>>>>>> 3.walter is 100% correct. Solr is search. The only complex data
> >>>>>> structure it has is an array. Something like mongo can do arrays
> hashes
> >>>>>> arrays of hashes etc, it's actually json based. But it can't search
> well as
> >>>>>> a search engine can.
> >>>>>>>>
> >>>>>>>> There is no one tool. Use each for their own abilities.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> The people @ Lucidworks would beg to disagree but I know exactly
> >>>>>> what you
> >>>>>>>>> are saying Walter.
> >>>>>>>>>
> >>>>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
> >>>>>> noSQL DB.
> >>>>>>>>> I like to express it as knowing when to fish and when to cut
> bait.
> >>>>>> As soon
> >>>>>>>>> as you are in the one - many or many - many world a real DB is a
> >>>>>> whole lot
> >>>>>>>>> more sensible.
> >>>>>>>>>
> >>>>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and
> you've
> >>>>>> got a
> >>>>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long
> time
> >>>>>> but It
> >>>>>>>>> just does not compare to Solr. Put the two together and you've
> got
> >>>>>> some
> >>>>>>>>> serious magic.
> >>>>>>>>>
> >>>>>>>>> No offense intended, There's nothing wrong with being 97.5%
> correct.
> >>>>>> I wish
> >>>>>>>>> I could be 97.5% correct all the time. :-)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <
> wunder@wunderwood.org>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Solr is NOT a database. If you need a database, don’t choose
> Solr.
> >>>>>>>>>>
> >>>>>>>>>> If you need both a database and search, choose MarkLogic.
> >>>>>>>>>>
> >>>>>>>>>> wunder
> >>>>>>>>>> Walter Underwood
> >>>>>>>>>> wunder@wunderwood.org
> >>>>>>>>>> http://observer.wunderwood.org/ (my blog)
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <
> fviscomi@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to
> use?
> >>>>>>>>>>> Both are NoSql database, is there a good reason to chose solr
> and
> >>>>>> not
> >>>>>>>>>>> mongoDb?
> >>>>>>>>>>>
> >>>>>>>>>>> thanks really much
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Ing. Viscomi Francesco
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
>
>
Re: MongoDb vs Solr
Posted by Walter Underwood <wu...@wunderwood.org>.
I read the seven year old slides just now. The Guardian was using Solr to deliver the content. Their repository (see slide 38) is an RDBMS.
https://www.slideshare.net/matwall/no-sql-at-the-guardian
In slide 37, part of “Is Solr a database?”, they note “Search index not really persistence”. To me, that means “not a database”.
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Aug 5, 2017, at 4:59 AM, Dave <ha...@gmail.com> wrote:
>
> And to add to the conversation, 7 year old blog posts are not a reason to make decisions for your tech stack.
>
> And insults are not something I'd like to see in this mailing list, at all, so please do not repeat any such disrespect or condescending statements in your contributions to the mailing list that's supposed to serve as a source of help, which, you asked for.
>
>> On Aug 5, 2017, at 7:54 AM, Dave <ha...@gmail.com> wrote:
>>
>> Also I wouldn't really recommend mongodb at all, it should only to be used as a fast front end to an acid compliant relational db same with memcahed for example. If you're going to stick to open source, as I do, you should use the correct tool for the job.
>>
>>> On Aug 5, 2017, at 7:32 AM, GW <th...@gmail.com> wrote:
>>>
>>> Insults for Walter only.. sorry..
>>>
>>>> On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
>>>>
>>>> For The Guardian, Solr is the new database | Lucidworks
>>>> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
>>>> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
>>>> is-the-new-database/
>>>> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged
>>>> a few days ago about how open search source is disrupting the relationship
>>>> between ...
>>>>
>>>> You are arrogant and probably lame as a programmer.
>>>>
>>>> All offense intended
>>>>
>>>>> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>>>>>
>>>>> Watch their videos....
>>>>>
>>>>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
>>>>> wrote:
>>>>>
>>>>>> MarkLogic can do many-to-many. I worked there six years ago. They use
>>>>>> search engine index structure with generational updates, including segment
>>>>>> level caches. With locking. Pretty good stuff.
>>>>>>
>>>>>> A many to many relationship is an intersection across posting lists,
>>>>>> with transactions. Straightforward, but not easy to do it fast.
>>>>>>
>>>>>> The “Inside MarkLogic Server” paper does a good job of explaining the
>>>>>> guts.
>>>>>>
>>>>>> Now, back to our regularly scheduled Solr presentations.
>>>>>>
>>>>>> wunder
>>>>>> Walter Underwood
>>>>>> wunder@wunderwood.org
>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>
>>>>>>
>>>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Also, id love to see an example of a many to many relationship in a
>>>>>> nosql db as you described, since that's a rdbms concept. If it exists in a
>>>>>> nosql environment I would like to learn how...
>>>>>>>
>>>>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Uhm. Dude are you drinking?
>>>>>>>>
>>>>>>>> 1. Lucidworks would never say that.
>>>>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
>>>>>> source version of MySQL before oracle bought them
>>>>>>>> 3.walter is 100% correct. Solr is search. The only complex data
>>>>>> structure it has is an array. Something like mongo can do arrays hashes
>>>>>> arrays of hashes etc, it's actually json based. But it can't search well as
>>>>>> a search engine can.
>>>>>>>>
>>>>>>>> There is no one tool. Use each for their own abilities.
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> The people @ Lucidworks would beg to disagree but I know exactly
>>>>>> what you
>>>>>>>>> are saying Walter.
>>>>>>>>>
>>>>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>>>>> noSQL DB.
>>>>>>>>> I like to express it as knowing when to fish and when to cut bait.
>>>>>> As soon
>>>>>>>>> as you are in the one - many or many - many world a real DB is a
>>>>>> whole lot
>>>>>>>>> more sensible.
>>>>>>>>>
>>>>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>>>>>> got a
>>>>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long time
>>>>>> but It
>>>>>>>>> just does not compare to Solr. Put the two together and you've got
>>>>>> some
>>>>>>>>> serious magic.
>>>>>>>>>
>>>>>>>>> No offense intended, There's nothing wrong with being 97.5% correct.
>>>>>> I wish
>>>>>>>>> I could be 97.5% correct all the time. :-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>>>>>>>
>>>>>>>>>> If you need both a database and search, choose MarkLogic.
>>>>>>>>>>
>>>>>>>>>> wunder
>>>>>>>>>> Walter Underwood
>>>>>>>>>> wunder@wunderwood.org
>>>>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>>>>>>>> Both are NoSql database, is there a good reason to chose solr and
>>>>>> not
>>>>>>>>>>> mongoDb?
>>>>>>>>>>>
>>>>>>>>>>> thanks really much
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ing. Viscomi Francesco
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
And to add to the conversation, 7 year old blog posts are not a reason to make decisions for your tech stack.
And insults are not something I'd like to see in this mailing list, at all, so please do not repeat any such disrespect or condescending statements in your contributions to the mailing list that's supposed to serve as a source of help, which, you asked for.
> On Aug 5, 2017, at 7:54 AM, Dave <ha...@gmail.com> wrote:
>
> Also I wouldn't really recommend mongodb at all, it should only to be used as a fast front end to an acid compliant relational db same with memcahed for example. If you're going to stick to open source, as I do, you should use the correct tool for the job.
>
>> On Aug 5, 2017, at 7:32 AM, GW <th...@gmail.com> wrote:
>>
>> Insults for Walter only.. sorry..
>>
>>> On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
>>>
>>> For The Guardian, Solr is the new database | Lucidworks
>>> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
>>> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
>>> is-the-new-database/
>>> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged
>>> a few days ago about how open search source is disrupting the relationship
>>> between ...
>>>
>>> You are arrogant and probably lame as a programmer.
>>>
>>> All offense intended
>>>
>>>> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>>>>
>>>> Watch their videos....
>>>>
>>>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
>>>> wrote:
>>>>
>>>>> MarkLogic can do many-to-many. I worked there six years ago. They use
>>>>> search engine index structure with generational updates, including segment
>>>>> level caches. With locking. Pretty good stuff.
>>>>>
>>>>> A many to many relationship is an intersection across posting lists,
>>>>> with transactions. Straightforward, but not easy to do it fast.
>>>>>
>>>>> The “Inside MarkLogic Server” paper does a good job of explaining the
>>>>> guts.
>>>>>
>>>>> Now, back to our regularly scheduled Solr presentations.
>>>>>
>>>>> wunder
>>>>> Walter Underwood
>>>>> wunder@wunderwood.org
>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>
>>>>>
>>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>>>> wrote:
>>>>>>
>>>>>> Also, id love to see an example of a many to many relationship in a
>>>>> nosql db as you described, since that's a rdbms concept. If it exists in a
>>>>> nosql environment I would like to learn how...
>>>>>>
>>>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> Uhm. Dude are you drinking?
>>>>>>>
>>>>>>> 1. Lucidworks would never say that.
>>>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
>>>>> source version of MySQL before oracle bought them
>>>>>>> 3.walter is 100% correct. Solr is search. The only complex data
>>>>> structure it has is an array. Something like mongo can do arrays hashes
>>>>> arrays of hashes etc, it's actually json based. But it can't search well as
>>>>> a search engine can.
>>>>>>>
>>>>>>> There is no one tool. Use each for their own abilities.
>>>>>>>
>>>>>>>
>>>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> The people @ Lucidworks would beg to disagree but I know exactly
>>>>> what you
>>>>>>>> are saying Walter.
>>>>>>>>
>>>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>>>> noSQL DB.
>>>>>>>> I like to express it as knowing when to fish and when to cut bait.
>>>>> As soon
>>>>>>>> as you are in the one - many or many - many world a real DB is a
>>>>> whole lot
>>>>>>>> more sensible.
>>>>>>>>
>>>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>>>>> got a
>>>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long time
>>>>> but It
>>>>>>>> just does not compare to Solr. Put the two together and you've got
>>>>> some
>>>>>>>> serious magic.
>>>>>>>>
>>>>>>>> No offense intended, There's nothing wrong with being 97.5% correct.
>>>>> I wish
>>>>>>>> I could be 97.5% correct all the time. :-)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>>>>>>
>>>>>>>>> If you need both a database and search, choose MarkLogic.
>>>>>>>>>
>>>>>>>>> wunder
>>>>>>>>> Walter Underwood
>>>>>>>>> wunder@wunderwood.org
>>>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>>>>>>> Both are NoSql database, is there a good reason to chose solr and
>>>>> not
>>>>>>>>>> mongoDb?
>>>>>>>>>>
>>>>>>>>>> thanks really much
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ing. Viscomi Francesco
>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
Also I wouldn't really recommend mongodb at all, it should only to be used as a fast front end to an acid compliant relational db same with memcahed for example. If you're going to stick to open source, as I do, you should use the correct tool for the job.
> On Aug 5, 2017, at 7:32 AM, GW <th...@gmail.com> wrote:
>
> Insults for Walter only.. sorry..
>
>> On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
>>
>> For The Guardian, Solr is the new database | Lucidworks
>> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
>> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
>> is-the-new-database/
>> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged
>> a few days ago about how open search source is disrupting the relationship
>> between ...
>>
>> You are arrogant and probably lame as a programmer.
>>
>> All offense intended
>>
>>> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>>>
>>> Watch their videos....
>>>
>>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
>>> wrote:
>>>
>>>> MarkLogic can do many-to-many. I worked there six years ago. They use
>>>> search engine index structure with generational updates, including segment
>>>> level caches. With locking. Pretty good stuff.
>>>>
>>>> A many to many relationship is an intersection across posting lists,
>>>> with transactions. Straightforward, but not easy to do it fast.
>>>>
>>>> The “Inside MarkLogic Server” paper does a good job of explaining the
>>>> guts.
>>>>
>>>> Now, back to our regularly scheduled Solr presentations.
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> wunder@wunderwood.org
>>>> http://observer.wunderwood.org/ (my blog)
>>>>
>>>>
>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>>> wrote:
>>>>>
>>>>> Also, id love to see an example of a many to many relationship in a
>>>> nosql db as you described, since that's a rdbms concept. If it exists in a
>>>> nosql environment I would like to learn how...
>>>>>
>>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>> Uhm. Dude are you drinking?
>>>>>>
>>>>>> 1. Lucidworks would never say that.
>>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
>>>> source version of MySQL before oracle bought them
>>>>>> 3.walter is 100% correct. Solr is search. The only complex data
>>>> structure it has is an array. Something like mongo can do arrays hashes
>>>> arrays of hashes etc, it's actually json based. But it can't search well as
>>>> a search engine can.
>>>>>>
>>>>>> There is no one tool. Use each for their own abilities.
>>>>>>
>>>>>>
>>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>>>>
>>>>>>> The people @ Lucidworks would beg to disagree but I know exactly
>>>> what you
>>>>>>> are saying Walter.
>>>>>>>
>>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>>> noSQL DB.
>>>>>>> I like to express it as knowing when to fish and when to cut bait.
>>>> As soon
>>>>>>> as you are in the one - many or many - many world a real DB is a
>>>> whole lot
>>>>>>> more sensible.
>>>>>>>
>>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>>>> got a
>>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long time
>>>> but It
>>>>>>> just does not compare to Solr. Put the two together and you've got
>>>> some
>>>>>>> serious magic.
>>>>>>>
>>>>>>> No offense intended, There's nothing wrong with being 97.5% correct.
>>>> I wish
>>>>>>> I could be 97.5% correct all the time. :-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>>>> wrote:
>>>>>>>>
>>>>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>>>>>
>>>>>>>> If you need both a database and search, choose MarkLogic.
>>>>>>>>
>>>>>>>> wunder
>>>>>>>> Walter Underwood
>>>>>>>> wunder@wunderwood.org
>>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>>>>>> Both are NoSql database, is there a good reason to chose solr and
>>>> not
>>>>>>>>> mongoDb?
>>>>>>>>>
>>>>>>>>> thanks really much
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ing. Viscomi Francesco
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>
Re: MongoDb vs Solr
Posted by GW <th...@gmail.com>.
Insults for Walter only.. sorry..
On 5 August 2017 at 06:28, GW <th...@gmail.com> wrote:
> For The Guardian, Solr is the new database | Lucidworks
> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
> https://lucidworks.com/2010/04/29/for-the-guardian-solr-
> is-the-new-database/
> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged
> a few days ago about how open search source is disrupting the relationship
> between ...
>
> You are arrogant and probably lame as a programmer.
>
> All offense intended
>
> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>
>> Watch their videos....
>>
>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
>> wrote:
>>
>>> MarkLogic can do many-to-many. I worked there six years ago. They use
>>> search engine index structure with generational updates, including segment
>>> level caches. With locking. Pretty good stuff.
>>>
>>> A many to many relationship is an intersection across posting lists,
>>> with transactions. Straightforward, but not easy to do it fast.
>>>
>>> The “Inside MarkLogic Server” paper does a good job of explaining the
>>> guts.
>>>
>>> Now, back to our regularly scheduled Solr presentations.
>>>
>>> wunder
>>> Walter Underwood
>>> wunder@wunderwood.org
>>> http://observer.wunderwood.org/ (my blog)
>>>
>>>
>>> > On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>> wrote:
>>> >
>>> > Also, id love to see an example of a many to many relationship in a
>>> nosql db as you described, since that's a rdbms concept. If it exists in a
>>> nosql environment I would like to learn how...
>>> >
>>> >> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>> wrote:
>>> >>
>>> >> Uhm. Dude are you drinking?
>>> >>
>>> >> 1. Lucidworks would never say that.
>>> >> 2. Maria is not a json +MySQL. Maria is a fork of the last open
>>> source version of MySQL before oracle bought them
>>> >> 3.walter is 100% correct. Solr is search. The only complex data
>>> structure it has is an array. Something like mongo can do arrays hashes
>>> arrays of hashes etc, it's actually json based. But it can't search well as
>>> a search engine can.
>>> >>
>>> >> There is no one tool. Use each for their own abilities.
>>> >>
>>> >>
>>> >>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>> >>>
>>> >>> The people @ Lucidworks would beg to disagree but I know exactly
>>> what you
>>> >>> are saying Walter.
>>> >>>
>>> >>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>> noSQL DB.
>>> >>> I like to express it as knowing when to fish and when to cut bait.
>>> As soon
>>> >>> as you are in the one - many or many - many world a real DB is a
>>> whole lot
>>> >>> more sensible.
>>> >>>
>>> >>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>>> got a
>>> >>> rocket. Maria (MySQL with JSON) has had text search for a long time
>>> but It
>>> >>> just does not compare to Solr. Put the two together and you've got
>>> some
>>> >>> serious magic.
>>> >>>
>>> >>> No offense intended, There's nothing wrong with being 97.5% correct.
>>> I wish
>>> >>> I could be 97.5% correct all the time. :-)
>>> >>>
>>> >>>
>>> >>>
>>> >>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>>> wrote:
>>> >>>>
>>> >>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>> >>>>
>>> >>>> If you need both a database and search, choose MarkLogic.
>>> >>>>
>>> >>>> wunder
>>> >>>> Walter Underwood
>>> >>>> wunder@wunderwood.org
>>> >>>> http://observer.wunderwood.org/ (my blog)
>>> >>>>
>>> >>>>
>>> >>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Hi all,
>>> >>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>> >>>>> Both are NoSql database, is there a good reason to chose solr and
>>> not
>>> >>>>> mongoDb?
>>> >>>>>
>>> >>>>> thanks really much
>>> >>>>>
>>> >>>>> --
>>> >>>>> Ing. Viscomi Francesco
>>> >>>>
>>> >>>>
>>>
>>>
>>
>
Re: MongoDb vs Solr
Posted by Lars Karlsson <la...@gmail.com>.
Yet another reason to stick to Solr:
https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0
On Mon, 7 Aug 2017 at 15:40, Charlie Hull <ch...@flax.co.uk> wrote:
> On 05/08/2017 12:28, GW wrote:
> > For The Guardian, Solr is the new database | Lucidworks
> > <
> https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A
> >
> >
> https://lucidworks.com/2010/04/29/for-the-guardian-solr-is-the-new-database/
> > Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged
> a
> > few days ago about how open search source is disrupting the relationship
> > between ...
>
> Sorry, but the Guardian moved away from Solr to Elasticsearch (which
> isn't a database either) several years ago.
> >
> > You are arrogant and probably lame as a programmer.
> >
> > All offense intended
>
> Oh dear....
>
> C
> >
> > On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
> >
> >> Watch their videos....
> >>
> >> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org>
> wrote:
> >>
> >>> MarkLogic can do many-to-many. I worked there six years ago. They use
> >>> search engine index structure with generational updates, including
> segment
> >>> level caches. With locking. Pretty good stuff.
> >>>
> >>> A many to many relationship is an intersection across posting lists,
> with
> >>> transactions. Straightforward, but not easy to do it fast.
> >>>
> >>> The “Inside MarkLogic Server” paper does a good job of explaining the
> >>> guts.
> >>>
> >>> Now, back to our regularly scheduled Solr presentations.
> >>>
> >>> wunder
> >>> Walter Underwood
> >>> wunder@wunderwood.org
> >>> http://observer.wunderwood.org/ (my blog)
> >>>
> >>>
> >>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
> >>> wrote:
> >>>>
> >>>> Also, id love to see an example of a many to many relationship in a
> >>> nosql db as you described, since that's a rdbms concept. If it exists
> in a
> >>> nosql environment I would like to learn how...
> >>>>
> >>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> Uhm. Dude are you drinking?
> >>>>>
> >>>>> 1. Lucidworks would never say that.
> >>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open
> source
> >>> version of MySQL before oracle bought them
> >>>>> 3.walter is 100% correct. Solr is search. The only complex data
> >>> structure it has is an array. Something like mongo can do arrays hashes
> >>> arrays of hashes etc, it's actually json based. But it can't search
> well as
> >>> a search engine can.
> >>>>>
> >>>>> There is no one tool. Use each for their own abilities.
> >>>>>
> >>>>>
> >>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
> >>>>>>
> >>>>>> The people @ Lucidworks would beg to disagree but I know exactly
> what
> >>> you
> >>>>>> are saying Walter.
> >>>>>>
> >>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
> >>> noSQL DB.
> >>>>>> I like to express it as knowing when to fish and when to cut bait.
> As
> >>> soon
> >>>>>> as you are in the one - many or many - many world a real DB is a
> >>> whole lot
> >>>>>> more sensible.
> >>>>>>
> >>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
> >>> got a
> >>>>>> rocket. Maria (MySQL with JSON) has had text search for a long time
> >>> but It
> >>>>>> just does not compare to Solr. Put the two together and you've got
> >>> some
> >>>>>> serious magic.
> >>>>>>
> >>>>>> No offense intended, There's nothing wrong with being 97.5% correct.
> >>> I wish
> >>>>>> I could be 97.5% correct all the time. :-)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On 4 August 2017 at 18:41, Walter Underwood <wunder@wunderwood.org
> >
> >>> wrote:
> >>>>>>>
> >>>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
> >>>>>>>
> >>>>>>> If you need both a database and search, choose MarkLogic.
> >>>>>>>
> >>>>>>> wunder
> >>>>>>> Walter Underwood
> >>>>>>> wunder@wunderwood.org
> >>>>>>> http://observer.wunderwood.org/ (my blog)
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fviscomi@gmail.com
> >
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi all,
> >>>>>>>> why i have to choose solr if mongoDb is easier to learn and to
> use?
> >>>>>>>> Both are NoSql database, is there a good reason to chose solr and
> >>> not
> >>>>>>>> mongoDb?
> >>>>>>>>
> >>>>>>>> thanks really much
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Ing. Viscomi Francesco
> >>>>>>>
> >>>>>>>
> >>>
> >>>
> >>
> >
> >
> > ---
> > This email has been checked for viruses by AVG.
> > http://www.avg.com
> >
>
>
> --
> Charlie Hull
> Flax - Open Source Enterprise Search
>
> tel/fax: +44 (0)8700 118334
> mobile: +44 (0)7767 825828
> web: www.flax.co.uk
>
Re: MongoDb vs Solr
Posted by Charlie Hull <ch...@flax.co.uk>.
On 05/08/2017 12:28, GW wrote:
> For The Guardian, Solr is the new database | Lucidworks
> <https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
> https://lucidworks.com/2010/04/29/for-the-guardian-solr-is-the-new-database/
> Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged a
> few days ago about how open search source is disrupting the relationship
> between ...
Sorry, but the Guardian moved away from Solr to Elasticsearch (which
isn't a database either) several years ago.
>
> You are arrogant and probably lame as a programmer.
>
> All offense intended
Oh dear....
C
>
> On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
>
>> Watch their videos....
>>
>> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org> wrote:
>>
>>> MarkLogic can do many-to-many. I worked there six years ago. They use
>>> search engine index structure with generational updates, including segment
>>> level caches. With locking. Pretty good stuff.
>>>
>>> A many to many relationship is an intersection across posting lists, with
>>> transactions. Straightforward, but not easy to do it fast.
>>>
>>> The “Inside MarkLogic Server” paper does a good job of explaining the
>>> guts.
>>>
>>> Now, back to our regularly scheduled Solr presentations.
>>>
>>> wunder
>>> Walter Underwood
>>> wunder@wunderwood.org
>>> http://observer.wunderwood.org/ (my blog)
>>>
>>>
>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>>> wrote:
>>>>
>>>> Also, id love to see an example of a many to many relationship in a
>>> nosql db as you described, since that's a rdbms concept. If it exists in a
>>> nosql environment I would like to learn how...
>>>>
>>>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>>> wrote:
>>>>>
>>>>> Uhm. Dude are you drinking?
>>>>>
>>>>> 1. Lucidworks would never say that.
>>>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open source
>>> version of MySQL before oracle bought them
>>>>> 3.walter is 100% correct. Solr is search. The only complex data
>>> structure it has is an array. Something like mongo can do arrays hashes
>>> arrays of hashes etc, it's actually json based. But it can't search well as
>>> a search engine can.
>>>>>
>>>>> There is no one tool. Use each for their own abilities.
>>>>>
>>>>>
>>>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>>>
>>>>>> The people @ Lucidworks would beg to disagree but I know exactly what
>>> you
>>>>>> are saying Walter.
>>>>>>
>>>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>>> noSQL DB.
>>>>>> I like to express it as knowing when to fish and when to cut bait. As
>>> soon
>>>>>> as you are in the one - many or many - many world a real DB is a
>>> whole lot
>>>>>> more sensible.
>>>>>>
>>>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>>> got a
>>>>>> rocket. Maria (MySQL with JSON) has had text search for a long time
>>> but It
>>>>>> just does not compare to Solr. Put the two together and you've got
>>> some
>>>>>> serious magic.
>>>>>>
>>>>>> No offense intended, There's nothing wrong with being 97.5% correct.
>>> I wish
>>>>>> I could be 97.5% correct all the time. :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>>> wrote:
>>>>>>>
>>>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>>>>
>>>>>>> If you need both a database and search, choose MarkLogic.
>>>>>>>
>>>>>>> wunder
>>>>>>> Walter Underwood
>>>>>>> wunder@wunderwood.org
>>>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>>>
>>>>>>>
>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>>>>> Both are NoSql database, is there a good reason to chose solr and
>>> not
>>>>>>>> mongoDb?
>>>>>>>>
>>>>>>>> thanks really much
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ing. Viscomi Francesco
>>>>>>>
>>>>>>>
>>>
>>>
>>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
--
Charlie Hull
Flax - Open Source Enterprise Search
tel/fax: +44 (0)8700 118334
mobile: +44 (0)7767 825828
web: www.flax.co.uk
Re: MongoDb vs Solr
Posted by GW <th...@gmail.com>.
For The Guardian, Solr is the new database | Lucidworks
<https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE&url=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F&usg=AFQjCNE6CwwFRMvNhgzvEZu-Sryu_vtL8A>
https://lucidworks.com/2010/04/29/for-the-guardian-solr-is-the-new-database/
Apr 29, 2010 - For The Guardian, *Solr* is the new *database*. I blogged a
few days ago about how open search source is disrupting the relationship
between ...
You are arrogant and probably lame as a programmer.
All offense intended
On 5 August 2017 at 06:23, GW <th...@gmail.com> wrote:
> Watch their videos....
>
> On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org> wrote:
>
>> MarkLogic can do many-to-many. I worked there six years ago. They use
>> search engine index structure with generational updates, including segment
>> level caches. With locking. Pretty good stuff.
>>
>> A many to many relationship is an intersection across posting lists, with
>> transactions. Straightforward, but not easy to do it fast.
>>
>> The “Inside MarkLogic Server” paper does a good job of explaining the
>> guts.
>>
>> Now, back to our regularly scheduled Solr presentations.
>>
>> wunder
>> Walter Underwood
>> wunder@wunderwood.org
>> http://observer.wunderwood.org/ (my blog)
>>
>>
>> > On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com>
>> wrote:
>> >
>> > Also, id love to see an example of a many to many relationship in a
>> nosql db as you described, since that's a rdbms concept. If it exists in a
>> nosql environment I would like to learn how...
>> >
>> >> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com>
>> wrote:
>> >>
>> >> Uhm. Dude are you drinking?
>> >>
>> >> 1. Lucidworks would never say that.
>> >> 2. Maria is not a json +MySQL. Maria is a fork of the last open source
>> version of MySQL before oracle bought them
>> >> 3.walter is 100% correct. Solr is search. The only complex data
>> structure it has is an array. Something like mongo can do arrays hashes
>> arrays of hashes etc, it's actually json based. But it can't search well as
>> a search engine can.
>> >>
>> >> There is no one tool. Use each for their own abilities.
>> >>
>> >>
>> >>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>> >>>
>> >>> The people @ Lucidworks would beg to disagree but I know exactly what
>> you
>> >>> are saying Walter.
>> >>>
>> >>> A simple flat file like a cardx is fine and dandy as a Solrcloud
>> noSQL DB.
>> >>> I like to express it as knowing when to fish and when to cut bait. As
>> soon
>> >>> as you are in the one - many or many - many world a real DB is a
>> whole lot
>> >>> more sensible.
>> >>>
>> >>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
>> got a
>> >>> rocket. Maria (MySQL with JSON) has had text search for a long time
>> but It
>> >>> just does not compare to Solr. Put the two together and you've got
>> some
>> >>> serious magic.
>> >>>
>> >>> No offense intended, There's nothing wrong with being 97.5% correct.
>> I wish
>> >>> I could be 97.5% correct all the time. :-)
>> >>>
>> >>>
>> >>>
>> >>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
>> wrote:
>> >>>>
>> >>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>> >>>>
>> >>>> If you need both a database and search, choose MarkLogic.
>> >>>>
>> >>>> wunder
>> >>>> Walter Underwood
>> >>>> wunder@wunderwood.org
>> >>>> http://observer.wunderwood.org/ (my blog)
>> >>>>
>> >>>>
>> >>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi all,
>> >>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>> >>>>> Both are NoSql database, is there a good reason to chose solr and
>> not
>> >>>>> mongoDb?
>> >>>>>
>> >>>>> thanks really much
>> >>>>>
>> >>>>> --
>> >>>>> Ing. Viscomi Francesco
>> >>>>
>> >>>>
>>
>>
>
Re: MongoDb vs Solr
Posted by GW <th...@gmail.com>.
Watch their videos....
On 4 August 2017 at 23:26, Walter Underwood <wu...@wunderwood.org> wrote:
> MarkLogic can do many-to-many. I worked there six years ago. They use
> search engine index structure with generational updates, including segment
> level caches. With locking. Pretty good stuff.
>
> A many to many relationship is an intersection across posting lists, with
> transactions. Straightforward, but not easy to do it fast.
>
> The “Inside MarkLogic Server” paper does a good job of explaining the guts.
>
> Now, back to our regularly scheduled Solr presentations.
>
> wunder
> Walter Underwood
> wunder@wunderwood.org
> http://observer.wunderwood.org/ (my blog)
>
>
> > On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com> wrote:
> >
> > Also, id love to see an example of a many to many relationship in a
> nosql db as you described, since that's a rdbms concept. If it exists in a
> nosql environment I would like to learn how...
> >
> >> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com> wrote:
> >>
> >> Uhm. Dude are you drinking?
> >>
> >> 1. Lucidworks would never say that.
> >> 2. Maria is not a json +MySQL. Maria is a fork of the last open source
> version of MySQL before oracle bought them
> >> 3.walter is 100% correct. Solr is search. The only complex data
> structure it has is an array. Something like mongo can do arrays hashes
> arrays of hashes etc, it's actually json based. But it can't search well as
> a search engine can.
> >>
> >> There is no one tool. Use each for their own abilities.
> >>
> >>
> >>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
> >>>
> >>> The people @ Lucidworks would beg to disagree but I know exactly what
> you
> >>> are saying Walter.
> >>>
> >>> A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL
> DB.
> >>> I like to express it as knowing when to fish and when to cut bait. As
> soon
> >>> as you are in the one - many or many - many world a real DB is a whole
> lot
> >>> more sensible.
> >>>
> >>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've
> got a
> >>> rocket. Maria (MySQL with JSON) has had text search for a long time
> but It
> >>> just does not compare to Solr. Put the two together and you've got some
> >>> serious magic.
> >>>
> >>> No offense intended, There's nothing wrong with being 97.5% correct. I
> wish
> >>> I could be 97.5% correct all the time. :-)
> >>>
> >>>
> >>>
> >>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org>
> wrote:
> >>>>
> >>>> Solr is NOT a database. If you need a database, don’t choose Solr.
> >>>>
> >>>> If you need both a database and search, choose MarkLogic.
> >>>>
> >>>> wunder
> >>>> Walter Underwood
> >>>> wunder@wunderwood.org
> >>>> http://observer.wunderwood.org/ (my blog)
> >>>>
> >>>>
> >>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>> why i have to choose solr if mongoDb is easier to learn and to use?
> >>>>> Both are NoSql database, is there a good reason to chose solr and not
> >>>>> mongoDb?
> >>>>>
> >>>>> thanks really much
> >>>>>
> >>>>> --
> >>>>> Ing. Viscomi Francesco
> >>>>
> >>>>
>
>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
Solr=search engine
Mongodb=schemaless database
> On Aug 5, 2017, at 12:26 AM, Walter Underwood <wu...@wunderwood.org> wrote:
>
> MarkLogic can do many-to-many. I worked there six years ago. They use search engine index structure with generational updates, including segment level caches. With locking. Pretty good stuff.
>
> A many to many relationship is an intersection across posting lists, with transactions. Straightforward, but not easy to do it fast.
>
> The “Inside MarkLogic Server” paper does a good job of explaining the guts.
>
> Now, back to our regularly scheduled Solr presentations.
>
> wunder
> Walter Underwood
> wunder@wunderwood.org
> http://observer.wunderwood.org/ (my blog)
>
>
>> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com> wrote:
>>
>> Also, id love to see an example of a many to many relationship in a nosql db as you described, since that's a rdbms concept. If it exists in a nosql environment I would like to learn how...
>>
>>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com> wrote:
>>>
>>> Uhm. Dude are you drinking?
>>>
>>> 1. Lucidworks would never say that.
>>> 2. Maria is not a json +MySQL. Maria is a fork of the last open source version of MySQL before oracle bought them
>>> 3.walter is 100% correct. Solr is search. The only complex data structure it has is an array. Something like mongo can do arrays hashes arrays of hashes etc, it's actually json based. But it can't search well as a search engine can.
>>>
>>> There is no one tool. Use each for their own abilities.
>>>
>>>
>>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>>
>>>> The people @ Lucidworks would beg to disagree but I know exactly what you
>>>> are saying Walter.
>>>>
>>>> A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL DB.
>>>> I like to express it as knowing when to fish and when to cut bait. As soon
>>>> as you are in the one - many or many - many world a real DB is a whole lot
>>>> more sensible.
>>>>
>>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've got a
>>>> rocket. Maria (MySQL with JSON) has had text search for a long time but It
>>>> just does not compare to Solr. Put the two together and you've got some
>>>> serious magic.
>>>>
>>>> No offense intended, There's nothing wrong with being 97.5% correct. I wish
>>>> I could be 97.5% correct all the time. :-)
>>>>
>>>>
>>>>
>>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org> wrote:
>>>>>
>>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>>
>>>>> If you need both a database and search, choose MarkLogic.
>>>>>
>>>>> wunder
>>>>> Walter Underwood
>>>>> wunder@wunderwood.org
>>>>> http://observer.wunderwood.org/ (my blog)
>>>>>
>>>>>
>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>>> Both are NoSql database, is there a good reason to chose solr and not
>>>>>> mongoDb?
>>>>>>
>>>>>> thanks really much
>>>>>>
>>>>>> --
>>>>>> Ing. Viscomi Francesco
>>>>>
>>>>>
>
Re: MongoDb vs Solr
Posted by Walter Underwood <wu...@wunderwood.org>.
MarkLogic can do many-to-many. I worked there six years ago. They use search engine index structure with generational updates, including segment level caches. With locking. Pretty good stuff.
A many to many relationship is an intersection across posting lists, with transactions. Straightforward, but not easy to do it fast.
The “Inside MarkLogic Server” paper does a good job of explaining the guts.
Now, back to our regularly scheduled Solr presentations.
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Aug 4, 2017, at 8:13 PM, David Hastings <DH...@wshein.com> wrote:
>
> Also, id love to see an example of a many to many relationship in a nosql db as you described, since that's a rdbms concept. If it exists in a nosql environment I would like to learn how...
>
>> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com> wrote:
>>
>> Uhm. Dude are you drinking?
>>
>> 1. Lucidworks would never say that.
>> 2. Maria is not a json +MySQL. Maria is a fork of the last open source version of MySQL before oracle bought them
>> 3.walter is 100% correct. Solr is search. The only complex data structure it has is an array. Something like mongo can do arrays hashes arrays of hashes etc, it's actually json based. But it can't search well as a search engine can.
>>
>> There is no one tool. Use each for their own abilities.
>>
>>
>>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>>
>>> The people @ Lucidworks would beg to disagree but I know exactly what you
>>> are saying Walter.
>>>
>>> A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL DB.
>>> I like to express it as knowing when to fish and when to cut bait. As soon
>>> as you are in the one - many or many - many world a real DB is a whole lot
>>> more sensible.
>>>
>>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've got a
>>> rocket. Maria (MySQL with JSON) has had text search for a long time but It
>>> just does not compare to Solr. Put the two together and you've got some
>>> serious magic.
>>>
>>> No offense intended, There's nothing wrong with being 97.5% correct. I wish
>>> I could be 97.5% correct all the time. :-)
>>>
>>>
>>>
>>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org> wrote:
>>>>
>>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>>
>>>> If you need both a database and search, choose MarkLogic.
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> wunder@wunderwood.org
>>>> http://observer.wunderwood.org/ (my blog)
>>>>
>>>>
>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>>> Both are NoSql database, is there a good reason to chose solr and not
>>>>> mongoDb?
>>>>>
>>>>> thanks really much
>>>>>
>>>>> --
>>>>> Ing. Viscomi Francesco
>>>>
>>>>
Re: MongoDb vs Solr
Posted by David Hastings <DH...@wshein.com>.
Also, id love to see an example of a many to many relationship in a nosql db as you described, since that's a rdbms concept. If it exists in a nosql environment I would like to learn how...
> On Aug 4, 2017, at 10:56 PM, Dave <ha...@gmail.com> wrote:
>
> Uhm. Dude are you drinking?
>
> 1. Lucidworks would never say that.
> 2. Maria is not a json +MySQL. Maria is a fork of the last open source version of MySQL before oracle bought them
> 3.walter is 100% correct. Solr is search. The only complex data structure it has is an array. Something like mongo can do arrays hashes arrays of hashes etc, it's actually json based. But it can't search well as a search engine can.
>
> There is no one tool. Use each for their own abilities.
>
>
>> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>>
>> The people @ Lucidworks would beg to disagree but I know exactly what you
>> are saying Walter.
>>
>> A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL DB.
>> I like to express it as knowing when to fish and when to cut bait. As soon
>> as you are in the one - many or many - many world a real DB is a whole lot
>> more sensible.
>>
>> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've got a
>> rocket. Maria (MySQL with JSON) has had text search for a long time but It
>> just does not compare to Solr. Put the two together and you've got some
>> serious magic.
>>
>> No offense intended, There's nothing wrong with being 97.5% correct. I wish
>> I could be 97.5% correct all the time. :-)
>>
>>
>>
>>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org> wrote:
>>>
>>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>>
>>> If you need both a database and search, choose MarkLogic.
>>>
>>> wunder
>>> Walter Underwood
>>> wunder@wunderwood.org
>>> http://observer.wunderwood.org/ (my blog)
>>>
>>>
>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>>> wrote:
>>>>
>>>> Hi all,
>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>> Both are NoSql database, is there a good reason to chose solr and not
>>>> mongoDb?
>>>>
>>>> thanks really much
>>>>
>>>> --
>>>> Ing. Viscomi Francesco
>>>
>>>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
Uhm. Dude are you drinking?
1. Lucidworks would never say that.
2. Maria is not a json +MySQL. Maria is a fork of the last open source version of MySQL before oracle bought them
3.walter is 100% correct. Solr is search. The only complex data structure it has is an array. Something like mongo can do arrays hashes arrays of hashes etc, it's actually json based. But it can't search well as a search engine can.
There is no one tool. Use each for their own abilities.
> On Aug 4, 2017, at 10:35 PM, GW <th...@gmail.com> wrote:
>
> The people @ Lucidworks would beg to disagree but I know exactly what you
> are saying Walter.
>
> A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL DB.
> I like to express it as knowing when to fish and when to cut bait. As soon
> as you are in the one - many or many - many world a real DB is a whole lot
> more sensible.
>
> Augment your one-many|many-many NoSQL DB with a Solrcloud and you've got a
> rocket. Maria (MySQL with JSON) has had text search for a long time but It
> just does not compare to Solr. Put the two together and you've got some
> serious magic.
>
> No offense intended, There's nothing wrong with being 97.5% correct. I wish
> I could be 97.5% correct all the time. :-)
>
>
>
>> On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org> wrote:
>>
>> Solr is NOT a database. If you need a database, don’t choose Solr.
>>
>> If you need both a database and search, choose MarkLogic.
>>
>> wunder
>> Walter Underwood
>> wunder@wunderwood.org
>> http://observer.wunderwood.org/ (my blog)
>>
>>
>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
>> wrote:
>>>
>>> Hi all,
>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>> Both are NoSql database, is there a good reason to chose solr and not
>>> mongoDb?
>>>
>>> thanks really much
>>>
>>> --
>>> Ing. Viscomi Francesco
>>
>>
Re: MongoDb vs Solr
Posted by GW <th...@gmail.com>.
The people @ Lucidworks would beg to disagree but I know exactly what you
are saying Walter.
A simple flat file like a cardx is fine and dandy as a Solrcloud noSQL DB.
I like to express it as knowing when to fish and when to cut bait. As soon
as you are in the one - many or many - many world a real DB is a whole lot
more sensible.
Augment your one-many|many-many NoSQL DB with a Solrcloud and you've got a
rocket. Maria (MySQL with JSON) has had text search for a long time but It
just does not compare to Solr. Put the two together and you've got some
serious magic.
No offense intended, There's nothing wrong with being 97.5% correct. I wish
I could be 97.5% correct all the time. :-)
On 4 August 2017 at 18:41, Walter Underwood <wu...@wunderwood.org> wrote:
> Solr is NOT a database. If you need a database, don’t choose Solr.
>
> If you need both a database and search, choose MarkLogic.
>
> wunder
> Walter Underwood
> wunder@wunderwood.org
> http://observer.wunderwood.org/ (my blog)
>
>
> > On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com>
> wrote:
> >
> > Hi all,
> > why i have to choose solr if mongoDb is easier to learn and to use?
> > Both are NoSql database, is there a good reason to chose solr and not
> > mongoDb?
> >
> > thanks really much
> >
> > --
> > Ing. Viscomi Francesco
>
>
Re: MongoDb vs Solr
Posted by Walter Underwood <wu...@wunderwood.org>.
Solr is NOT a database. If you need a database, don’t choose Solr.
If you need both a database and search, choose MarkLogic.
wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (my blog)
> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi <fv...@gmail.com> wrote:
>
> Hi all,
> why i have to choose solr if mongoDb is easier to learn and to use?
> Both are NoSql database, is there a good reason to chose solr and not
> mongoDb?
>
> thanks really much
>
> --
> Ing. Viscomi Francesco
Re: MongoDb vs Solr
Posted by Jcd <jc...@gmail.com>.
Hello,
I have implemented a NoSQL key/value DB where I index the value field needed for retrieval plus the key value to get back the DB record when searching and it works pretty well.
I use Lucene but you can most probably do the same with SOLR.
Best wishes
JCD
Envoyé de mon iPhone
> Le 12 août 2017 à 21:06, Leonardo Perez Pulido <le...@gmail.com> a écrit :
>
> The main reason to chose Solr is the capacity of it has of return results
> sorted by relevance. Solr returns documents in ranked order based on how
> relevant each document is to the user's query.
> Solr isn't a database, although it can 'store' data.
> Regards.
>
>> On Sat, Aug 12, 2017 at 2:27 PM, Dave <ha...@gmail.com> wrote:
>>
>> Personally I say use a rdbms for data storage, it's what it's for. Solr is
>> for search and retrieve and the expense of possible loss of all data, in
>> which case you rebuild it.
>>
>>> On Aug 12, 2017, at 11:26 AM, Muwonge Ronald <ss...@gmail.com> wrote:
>>>
>>> Hi Solr can use mongodb for storage and you can play with the data as it
>>> grows depending on your data goals.Ease of learning doesn't mean
>>> happiness.I recommend you use both for serious projects that won't
>> collapse
>>> soon.
>>> Ronny
>>>> On 5 Aug 2017 02:16, "Francesco Viscomi" <fv...@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>> why i have to choose solr if mongoDb is easier to learn and to use?
>>>> Both are NoSql database, is there a good reason to chose solr and not
>>>> mongoDb?
>>>>
>>>> thanks really much
>>>>
>>>> --
>>>> Ing. Viscomi Francesco
>>>>
>>
Re: MongoDb vs Solr
Posted by Leonardo Perez Pulido <le...@gmail.com>.
The main reason to chose Solr is the capacity of it has of return results
sorted by relevance. Solr returns documents in ranked order based on how
relevant each document is to the user's query.
Solr isn't a database, although it can 'store' data.
Regards.
On Sat, Aug 12, 2017 at 2:27 PM, Dave <ha...@gmail.com> wrote:
> Personally I say use a rdbms for data storage, it's what it's for. Solr is
> for search and retrieve and the expense of possible loss of all data, in
> which case you rebuild it.
>
> > On Aug 12, 2017, at 11:26 AM, Muwonge Ronald <ss...@gmail.com> wrote:
> >
> > Hi Solr can use mongodb for storage and you can play with the data as it
> > grows depending on your data goals.Ease of learning doesn't mean
> > happiness.I recommend you use both for serious projects that won't
> collapse
> > soon.
> > Ronny
> >> On 5 Aug 2017 02:16, "Francesco Viscomi" <fv...@gmail.com> wrote:
> >>
> >> Hi all,
> >> why i have to choose solr if mongoDb is easier to learn and to use?
> >> Both are NoSql database, is there a good reason to chose solr and not
> >> mongoDb?
> >>
> >> thanks really much
> >>
> >> --
> >> Ing. Viscomi Francesco
> >>
>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
Personally I say use a rdbms for data storage, it's what it's for. Solr is for search and retrieve and the expense of possible loss of all data, in which case you rebuild it.
> On Aug 12, 2017, at 11:26 AM, Muwonge Ronald <ss...@gmail.com> wrote:
>
> Hi Solr can use mongodb for storage and you can play with the data as it
> grows depending on your data goals.Ease of learning doesn't mean
> happiness.I recommend you use both for serious projects that won't collapse
> soon.
> Ronny
>> On 5 Aug 2017 02:16, "Francesco Viscomi" <fv...@gmail.com> wrote:
>>
>> Hi all,
>> why i have to choose solr if mongoDb is easier to learn and to use?
>> Both are NoSql database, is there a good reason to chose solr and not
>> mongoDb?
>>
>> thanks really much
>>
>> --
>> Ing. Viscomi Francesco
>>
Re: MongoDb vs Solr
Posted by Lars Karlsson <la...@gmail.com>.
Agree, but saying
"but Solr is generally not considered to be durable across crashes or kill
-9."
Such statements are misleading, even Cassandra can loose data in such case.
and talking about RDBMS and ACID = non scalable persistence and dealing
with replication hell.
On Sat, 12 Aug 2017 at 17:26, Muwonge Ronald <ss...@gmail.com> wrote:
> Hi Solr can use mongodb for storage and you can play with the data as it
> grows depending on your data goals.Ease of learning doesn't mean
> happiness.I recommend you use both for serious projects that won't collapse
> soon.
> Ronny
> On 5 Aug 2017 02:16, "Francesco Viscomi" <fv...@gmail.com> wrote:
>
> > Hi all,
> > why i have to choose solr if mongoDb is easier to learn and to use?
> > Both are NoSql database, is there a good reason to chose solr and not
> > mongoDb?
> >
> > thanks really much
> >
> > --
> > Ing. Viscomi Francesco
> >
>
Re: MongoDb vs Solr
Posted by Muwonge Ronald <ss...@gmail.com>.
Hi Solr can use mongodb for storage and you can play with the data as it
grows depending on your data goals.Ease of learning doesn't mean
happiness.I recommend you use both for serious projects that won't collapse
soon.
Ronny
On 5 Aug 2017 02:16, "Francesco Viscomi" <fv...@gmail.com> wrote:
> Hi all,
> why i have to choose solr if mongoDb is easier to learn and to use?
> Both are NoSql database, is there a good reason to chose solr and not
> mongoDb?
>
> thanks really much
>
> --
> Ing. Viscomi Francesco
>
Re: MongoDb vs Solr
Posted by Dave <ha...@gmail.com>.
Ones a search engine and the other is a nosql db. They're nothing alike and are completely different tools for completely different jobs.
> On Aug 4, 2017, at 7:16 PM, Francesco Viscomi <fv...@gmail.com> wrote:
>
> Hi all,
> why i have to choose solr if mongoDb is easier to learn and to use?
> Both are NoSql database, is there a good reason to chose solr and not
> mongoDb?
>
> thanks really much
>
> --
> Ing. Viscomi Francesco
Re: MongoDb vs Solr
Posted by Lars Karlsson <la...@gmail.com>.
I doubt your statement, you can learn more about why you should prefer Solr
here:
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
On Sat, 5 Aug 2017 at 01:16, Francesco Viscomi <fv...@gmail.com> wrote:
> Hi all,
> why i have to choose solr if mongoDb is easier to learn and to use?
> Both are NoSql database, is there a good reason to chose solr and not
> mongoDb?
>
> thanks really much
>
> --
> Ing. Viscomi Francesco
>