Re: MongoDb vs Solr

2017-08-12 Thread Jcd
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  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  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  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"  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

2017-08-12 Thread Leonardo Perez Pulido
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  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  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"  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

2017-08-12 Thread Dave
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  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"  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

2017-08-12 Thread Lars Karlsson
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  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"  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

2017-08-12 Thread Muwonge Ronald
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"  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

2017-08-08 Thread Lars Karlsson
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  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=j==s=web=2=rja=8=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE=https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-guardian-solr-is-the-new-database%2F=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  wrote:
> >
> >> Watch their videos
> >>
> >> On 4 August 2017 at 23:26, Walter Underwood 
> 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
> >>> wun...@wunderwood.org
> >>> http://observer.wunderwood.org/  (my blog)
> >>>
> >>>
>  On Aug 4, 2017, at 8:13 PM, David Hastings 
> >>> 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 
> >>> 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  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  >
> >>> 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
> >>> wun...@wunderwood.org
> >>> http://observer.wunderwood.org/  (my blog)
> >>>
> >>>
>  On Aug 4, 2017, at 4:16 PM, Francesco Viscomi  >
> >>> 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

2017-08-07 Thread Charlie Hull

On 05/08/2017 12:28, GW wrote:

For The Guardian, Solr is the new database | Lucidworks

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  wrote:


Watch their videos

On 4 August 2017 at 23:26, Walter Underwood  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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)



On Aug 4, 2017, at 8:13 PM, David Hastings 

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 

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  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 

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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)



On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 

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

2017-08-05 Thread Walter Underwood
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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Aug 5, 2017, at 9:51 AM, Peter Sturge  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 
> 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
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>>> On Aug 5, 2017, at 4:59 AM, Dave  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  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  wrote:
> 
> Insults for Walter only.. sorry..
> 
>> On 5 August 2017 at 06:28, GW  wrote:
>> 
>> For The Guardian, Solr is the new database | Lucidworks
>> > cd=2=rja=8=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE=
>> https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-
>> guardian-solr-is-the-new-database%2F=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  wrote:
>>> 
>>> Watch their videos
>>> 
>>> On 4 August 2017 at 23:26, Walter Underwood 
>>> 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
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)
 
 
> On Aug 4, 2017, at 8:13 PM, David Hastings 
 wrote:
> 
> Also, id love to see an example of a many to many relationship in a
 nosql db as you 

Re: MongoDb vs Solr

2017-08-05 Thread Peter Sturge
*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 
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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> > On Aug 5, 2017, at 4:59 AM, Dave  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  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  wrote:
> >>>
> >>> Insults for Walter only.. sorry..
> >>>
>  On 5 August 2017 at 06:28, GW  wrote:
> 
>  For The Guardian, Solr is the new database | Lucidworks
>   cd=2=rja=8=0ahUKEwiR1rn6_b_VAhVB7IMKHWGKBj4QFgguMAE=
> https%3A%2F%2Flucidworks.com%2F2010%2F04%2F29%2Ffor-the-
> guardian-solr-is-the-new-database%2F=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  wrote:
> >
> > Watch their videos
> >
> > On 4 August 2017 at 23:26, Walter Underwood 
> > 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
> >> wun...@wunderwood.org
> >> http://observer.wunderwood.org/  (my blog)
> >>
> >>
> >>> On Aug 4, 2017, at 8:13 PM, David Hastings 
> >> 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 
> >> 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.
> 
> 
> 

Re: MongoDb vs Solr

2017-08-05 Thread Walter Underwood
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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Aug 5, 2017, at 4:59 AM, Dave  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  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  wrote:
>>> 
>>> Insults for Walter only.. sorry..
>>> 
 On 5 August 2017 at 06:28, GW  wrote:
 
 For The Guardian, Solr is the new database | Lucidworks
 
 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  wrote:
> 
> Watch their videos
> 
> On 4 August 2017 at 23:26, Walter Underwood 
> 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
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>>> On Aug 4, 2017, at 8:13 PM, David Hastings 
>> 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 
>> 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  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. :-)
> 
> 
> 

Re: MongoDb vs Solr

2017-08-05 Thread Dave
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  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  wrote:
>> 
>> Insults for Walter only.. sorry..
>> 
>>> On 5 August 2017 at 06:28, GW  wrote:
>>> 
>>> For The Guardian, Solr is the new database | Lucidworks
>>> 
>>> 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  wrote:
 
 Watch their videos
 
 On 4 August 2017 at 23:26, Walter Underwood 
 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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Aug 4, 2017, at 8:13 PM, David Hastings 
> 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 
> 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  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 
> 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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
> wrote:
>> 
>> Hi all,
>> why i have to choose solr if mongoDb is easier to learn and to use?

Re: MongoDb vs Solr

2017-08-05 Thread Dave
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  wrote:
> 
> Insults for Walter only.. sorry..
> 
>> On 5 August 2017 at 06:28, GW  wrote:
>> 
>> For The Guardian, Solr is the new database | Lucidworks
>> 
>> 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  wrote:
>>> 
>>> Watch their videos
>>> 
>>> On 4 August 2017 at 23:26, Walter Underwood 
>>> 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
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)
 
 
> On Aug 4, 2017, at 8:13 PM, David Hastings 
 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 
 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  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 
 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
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)
 
 
> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
 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

2017-08-05 Thread Dave
Solr=search engine
Mongodb=schemaless database



> On Aug 5, 2017, at 12:26 AM, Walter Underwood  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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Aug 4, 2017, at 8:13 PM, David Hastings  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  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  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  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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
> 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

2017-08-05 Thread GW
Insults for Walter only.. sorry..

On 5 August 2017 at 06:28, GW  wrote:

> For The Guardian, Solr is the new database | Lucidworks
> 
> 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  wrote:
>
>> Watch their videos
>>
>> On 4 August 2017 at 23:26, Walter Underwood 
>> 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
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>>
>>>
>>> > On Aug 4, 2017, at 8:13 PM, David Hastings 
>>> 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 
>>> 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  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 
>>> 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
>>>  wun...@wunderwood.org
>>>  http://observer.wunderwood.org/  (my blog)
>>> 
>>> 
>>> > On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
>>>  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

2017-08-05 Thread GW
For The Guardian, Solr is the new database | Lucidworks

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  wrote:

> Watch their videos
>
> On 4 August 2017 at 23:26, Walter Underwood  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
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>>
>> > On Aug 4, 2017, at 8:13 PM, David Hastings 
>> 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 
>> 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  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 
>> 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
>>  wun...@wunderwood.org
>>  http://observer.wunderwood.org/  (my blog)
>> 
>> 
>> > On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
>>  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

2017-08-05 Thread Lars Karlsson
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  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

2017-08-05 Thread GW
Watch their videos

On 4 August 2017 at 23:26, Walter Underwood  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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> > On Aug 4, 2017, at 8:13 PM, David Hastings  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  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  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 
> 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
>  wun...@wunderwood.org
>  http://observer.wunderwood.org/  (my blog)
> 
> 
> > On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
>  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

2017-08-04 Thread Walter Underwood
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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Aug 4, 2017, at 8:13 PM, David Hastings  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  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  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  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
 wun...@wunderwood.org
 http://observer.wunderwood.org/  (my blog)
 
 
> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
 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

2017-08-04 Thread David Hastings
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  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  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  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
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>> 
>>> 
 On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
>>> 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

2017-08-04 Thread Dave
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  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  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
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 
>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
>> 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

2017-08-04 Thread GW
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  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
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> > On Aug 4, 2017, at 4:16 PM, Francesco Viscomi 
> 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

2017-08-04 Thread Walter Underwood
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
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi  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

2017-08-04 Thread Dave
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  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