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 <peter.stu...@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 <wun...@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 >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >> >>> On Aug 5, 2017, at 4:59 AM, Dave <hastings.recurs...@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 <hastings.recurs...@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 <thegeofo...@gmail.com> wrote: >>>>> >>>>> Insults for Walter only.. sorry.. >>>>> >>>>>> On 5 August 2017 at 06:28, GW <thegeofo...@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 <thegeofo...@gmail.com> wrote: >>>>>>> >>>>>>> Watch their videos.... >>>>>>> >>>>>>> On 4 August 2017 at 23:26, Walter Underwood <wun...@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 >>>>>>>> wun...@wunderwood.org >>>>>>>> http://observer.wunderwood.org/ (my blog) >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 4, 2017, at 8:13 PM, David Hastings <dhasti...@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 <hastings.recurs...@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 <thegeofo...@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 < >> wun...@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 >>>>>>>>>>>> wun...@wunderwood.org >>>>>>>>>>>> http://observer.wunderwood.org/ (my blog) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 4, 2017, at 4:16 PM, Francesco Viscomi < >> fvisc...@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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >> >>
