Sure. Someone sends an HTTP request that deletes all the content. I’m glad to 
share the curl request.

Or you can put content in with fields that are indexed but not stored. Then the 
content is “gone” as soon
as you send it to Solr.

Or you change the schema and need to reindex, but don’t have copies of the 
original content.

Or there there is some disk problem and some docs are not in the backup because 
the backups aren’t
transactional.

I’m sure there are other situations.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Nov 23, 2016, at 9:00 PM, Kris Musshorn <mussho...@comcast.net> wrote:
> 
> Will someone please give me a detailed scenario where solr content could 
> "disappear"? 
> 
> Disappear means what exactly?
> 
> TIA,
> Kris
> 
> 
> -----Original Message-----
> From: Walter Underwood [mailto:wun...@wunderwood.org] 
> Sent: Wednesday, November 23, 2016 7:47 PM
> To: solr-user@lucene.apache.org
> Subject: Re: SOLR vs mongdb
> 
> Well, I didn’t actually recommend MongoDB as a repository. :-)
> 
> If you want transactions and search, buy MarkLogic. I worked there for two 
> years, and that is serious non-muggle technology.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
> 
>> On Nov 23, 2016, at 4:43 PM, Alexandre Rafalovitch <arafa...@gmail.com> 
>> wrote:
>> 
>> Actually, you need to be ok that your content will disappear when you 
>> use MongoDB as well.... :-(
>> 
>> But I understand what you were trying to say.
>> ----
>> http://www.solr-start.com/ - Resources for Solr users, new and 
>> experienced
>> 
>> 
>> On 24 November 2016 at 11:34, Walter Underwood <wun...@wunderwood.org> wrote:
>>> The choice is simple. Are you OK if all your content disappears and you 
>>> need to reload?
>>> If so, use Solr. If not, you need some kind of repository. It can be files 
>>> in Amazon S3.
>>> But Solr is not designed to preserve your data.
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>> 
>>> 
>>>> On Nov 23, 2016, at 4:12 PM, Alexandre Rafalovitch <arafa...@gmail.com> 
>>>> wrote:
>>>> 
>>>> Solr supports automatic detection of content types for new fields.
>>>> That was - unfortunately - named as schemaless mode. It still is 
>>>> typed under the covers and has limitations. Such as needing all 
>>>> automatically created fields to be multivalued (by the default 
>>>> schemaless definition).
>>>> 
>>>> MongoDB is better about actually storing content, especially nested 
>>>> content. Solr can store content, but that's not what it is about. 
>>>> You can totally turn off all the stored flags in Solr and return 
>>>> just document ids, while storing the content in MongoDB.
>>>> 
>>>> You can search in Mongo and you can store content in Solr, so for 
>>>> simple use cases you can use either one to serve both cause. But you 
>>>> can also pound nails with a brick and make holes with a hammer.
>>>> 
>>>> Oh, and do not read this as me endorsing MongoDB. I would probably 
>>>> look at Postgress with JSON columns instead, as it is more reliable 
>>>> and feature rich.
>>>> 
>>>> Regards,
>>>> Alex.
>>>> ----
>>>> http://www.solr-start.com/ - Resources for Solr users, new and 
>>>> experienced
>>>> 
>>>> 
>>>> On 24 November 2016 at 07:34, Prateek Jain J 
>>>> <prateek.j.j...@ericsson.com> wrote:
>>>>> SOLR also supports, schemaless behaviour. and my question is same that, 
>>>>> why and where should we prefer mongodb. Web search didn’t helped me on 
>>>>> this.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Prateek Jain
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Rohit Kanchan [mailto:rohitkan2...@gmail.com]
>>>>> Sent: 23 November 2016 07:07 PM
>>>>> To: solr-user@lucene.apache.org
>>>>> Subject: Re: SOLR vs mongdb
>>>>> 
>>>>> Hi Prateek,
>>>>> 
>>>>> I think you are talking about two different animals. Solr(actually 
>>>>> embedded
>>>>> lucene) is actually a search engine where you can use different features 
>>>>> like faceting, highlighting etc but it is a document store where for each 
>>>>> text it does create an Inverted index and map that to documents.  Mongodb 
>>>>> is also document store but I think it adds basic search capability.  This 
>>>>> is my understanding. We are using mongo for temporary storage and I think 
>>>>> it is good for that where you want to store a key value document in a 
>>>>> collection without any static schema. In Solr you need to define your 
>>>>> schema. In solr you can define dynamic fields too. This is all my 
>>>>> understanding.
>>>>> 
>>>>> -
>>>>> Rohit
>>>>> 
>>>>> 
>>>>> On Wed, Nov 23, 2016 at 10:27 AM, Prateek Jain J < 
>>>>> prateek.j.j...@ericsson.com> wrote:
>>>>> 
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I have started to use mongodb and solr recently. Please feel free 
>>>>>> to correct me where my understanding is not upto the mark:
>>>>>> 
>>>>>> 
>>>>>> 1.       Solr is indexing engine but it stores both data and indexes in
>>>>>> same directory. Although we can select fields to store/persist in 
>>>>>> solr via schema.xml. But in nutshell, it's not possible to 
>>>>>> distinguish between data and indexes like, I can't remove all 
>>>>>> indexes and still have persisted data with SOLR.
>>>>>> 
>>>>>> 2.       Solr indexing capabilities are far better than any other nosql 
>>>>>> db
>>>>>> like mongodb etc. like faceting, weighted search.
>>>>>> 
>>>>>> 3.       Both support scalability via sharding.
>>>>>> 
>>>>>> 4.       We can have architecture where data is stored in separate db 
>>>>>> like
>>>>>> mongodb or mysql. SOLR can connect with db and index data (in SOLR).
>>>>>> 
>>>>>> I tried googling for question "solr vs mongodb" and there are 
>>>>>> various threads on sites like stackoverflow. But I still can't 
>>>>>> understand why would anyone go for mongodb and when for SOLR 
>>>>>> (except for features like faceting, may be CAP theorem). Are there 
>>>>>> any specific use-cases for choosing NoSQL databases like mongoDB over 
>>>>>> SOLR?
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> Prateek Jain
>>>>>> 
>>>>>> 
>>> 
> 
> 

Reply via email to