Hi Shawn,
Thank for suggestion of Zookeepers. For the 'buyout', I think your
misunderstanding is my fault since my description is kinda vague. Actually, the
'buyout' is requested by special customers. Their budget can only buy some
special service that "must be" (not just be able to) allowed to install whole
system, including s/w and h/w, on their site. The license is not about Solr.
It's about this whole service. Our biz manager want to get that budget and it's
approved by boss. So he ask us to provide such service.
scott.chu，scott....@udngroup.com
2016/5/12 (週四)
----- Original Message -----
From: Shawn Heisey
To: solr-user
CC:
Date: 2016/5/12 (週四) 07:03
Subject: Re: [scottchu] What kind of configuration to use for this size
ofnewsdata?
On 5/11/2016 3:55 AM, scott.chu wrote:
> **************************
> If I use SolrCloud, I know I have to setup Zookeeper. I know there're
> something called 'quorum' or 'ensemble' in Zookeeper terminologies. I
> also know there is a need for (2n+1) Zookeeper nodes per n SolrCloud
> nodes. Is your case running one SolrCloud node per one machine
> (Whether PM or VM). According to your experiences, how many nodes ,
> including SolrCloud's and Zookeeper's, do I need to setup? Is
> Replication in SolrCloud easy to setup as that in old version? (I
> setup replication solrconfig.xml and use solrcore.properties file to
> setup/switch roles in Solr node, rather than defining role directly in
> solrconfig.xml)
> **************************
No, you do not need that many Zookeeper nodes. You need three zookeeper
nodes. The only reason to add more zookeeper nodes is to handle more ZK
failures. I cannot think of any reason for anybody to install more than
five zookeeper nodes in a single ZK ensemble. Five nodes will sustain a
failure of two nodes, which means that you can take a node down for
maintenance, and *still* survive if another machine dies during maintenance.
Master-Slave replication is incompatible with SolrCloud, because
SolrCloud uses replication for disaster recovery operations.
> **************************
> We have a special biz case called 'buyout newspaper search service'.
> Customers buy intranet license to use search service for articles of some
> newspaper types and some range of publish dates, e.g. paper type 'A' for
> 2010-2012 and paper type 'B' for 2015. The buyout means we have to install
> who search service at customer site and customer can only use search service
> within their enterprise intranet environment. So you know, I have to build a
> special Solr server for each of such customers. Your idea of filtering is
> very much like ElasticSearch's multitenancy, which both are not fit in our
> buyout biz model. Do you have any suggestion for building Solr server in such
> condition?
> **************************
Solr does not include any kind of licensing system. It will always
work, and will usually allow somebody to search the entire index. To do
otherwise would be contrary to the general goal of open source projects.
If you need the service to expire or be limited in some way according to
license terms, you will need to write software to handle that ... but be
aware that if the users know anything about Solr, and they can get
access to the machine's filesystem, they will be able to get around most
such restrictions simply by copying the index config and data to another
machine. You would need to embed the restrictions into custom Lucene
code (perhaps encrypting the index and obfuscating search terms in some
way) to make it more difficult to defeat your licensing system.
Thanks,
Shawn
-----
未在此訊息中找到病毒。
已透過 AVG 檢查 - www.avg.com
版本: 2015.0.6189 / 病毒庫: 4568/12206 - 發佈日期: 05/10/16
