<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>cache=false &#8211; Solr.pl</title>
	<atom:link href="https://solr.pl/tag/cachefalse/feed/" rel="self" type="application/rss+xml" />
	<link>https://solr.pl</link>
	<description>All things to be found - Blog related to Apache Solr &#38; Lucene projects - https://solr.apache.org</description>
	<lastBuildDate>Wed, 11 Nov 2020 22:26:04 +0000</lastBuildDate>
	<language>pl-PL</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9</generator>
	<item>
		<title>Użycie parametrów cache=false i cost w zapytaniach</title>
		<link>https://solr.pl/2012/03/05/uzycie-parametrow-cachefalse-i-cost-w-zapytaniach/</link>
					<comments>https://solr.pl/2012/03/05/uzycie-parametrow-cachefalse-i-cost-w-zapytaniach/#respond</comments>
		
		<dc:creator><![CDATA[Rafał Kuć]]></dc:creator>
		<pubDate>Mon, 05 Mar 2012 22:25:35 +0000</pubDate>
				<category><![CDATA[Solr]]></category>
		<category><![CDATA[cache]]></category>
		<category><![CDATA[cache=false]]></category>
		<category><![CDATA[cost]]></category>
		<category><![CDATA[filter]]></category>
		<category><![CDATA[fq]]></category>
		<category><![CDATA[koszt]]></category>
		<category><![CDATA[solr]]></category>
		<guid isPermaLink="false">http://sematext.solr.pl/?p=404</guid>

					<description><![CDATA[Od chwili premiery Solr 3.4 użytkownicy otrzymali całkiem ciekawą funkcjonalność pozwalającą na określenie, czy wynik działania filtra, bądź zapytanie mają być cachowane. Oprócz tego dostaliśmy do ręki możliwość określania kosztu filtra. Przyjrzyjmy się zatem tym parametrom. Parametr cache=false Ustawiając parametr]]></description>
										<content:encoded><![CDATA[<p>Od chwili premiery <a href="http://solr.pl/2011/09/14/lucene-i-solr-3-4/">Solr 3.4 </a>użytkownicy otrzymali całkiem ciekawą funkcjonalność pozwalającą na określenie, czy wynik działania filtra, bądź zapytanie mają być cachowane. Oprócz tego dostaliśmy do ręki możliwość określania kosztu filtra. Przyjrzyjmy się zatem tym parametrom.</p>
<p><span id="more-404"></span></p>
<h3>Parametr cache=false</h3>
<p>Ustawiając parametr <em>cache</em> na wartość <em>false</em> mówimy Solr, aby wyniki danego zapytania nie były zapisywanie w cache&#8217;u. Parametr ten może być także użyty w ramach filtra (<em>fq</em>) powodując to samo zachowanie &#8211; wynik działania filtra nie trafi do cache&#8217;u. Co na to daje ? Wyobraźmy sobie następujący filtr, jako część zapytania:
</p>
<pre class="brush:xml">fq={!frange l=10 u=100}log(sum(sqrt(popularity),100))</pre>
<p>Jeżeli wiemy, iż zapytania z tym filtrem zdarzają się sporadycznie, możemy zdecydować, iż nie chcemy tych informacji w cache&#8217;u, aby np. nie powodować zmiany jego stanu poprzez dodawanie zbędnych wpisów. Aby to zrobić dodajemy atrybut <em>cache=false</em> w następujący sposób:
</p>
<pre class="brush:xml">fq={!frange l=10 u=100 cache=false}log(sum(sqrt(popularity),100))</pre>
<p>Dodanie dodatkowego atrybutu spowoduje, że wynik zapytania nie będzie dodany do cache&#8217;u.</p>
<h3>Parametr cost</h3>
<p>Dodatkowa możliwość oferowana przez Solr 3.4 to określenie ciężaru, jaki niesie filtr w przypadku filtrów, których nie chcemy cache&#8217;ować. Filtry z określonym ciężarem wykonywane są na samym końcu, po wszystkich wcześniejszych filtrach. Sam koszt określamy podając liczbę całkowitą jako wartość atrybutu <em>cost</em>. Weźmy na przykład następujący fragment zapytania:
</p>
<pre class="brush:xml">fq=cat:video&amp;fq={!cache=false cost=50}productGroup:12&amp;fq={!frange l=10 u=100 cache=false cost=150}log(sum(sqrt(popularity),100))</pre>
<p>Na początku zostanie wykonany filtr <em>fq=cat:video</em> ze względu na to, że jego zawartość trafi do cache&#8217;u. Następnie zostanie wykonany filtr z mniejszą wartością parametru <em>cost</em>, czyli filtr <em>fq={!cache=false cost=50}</em>. Na sam koniec Solr zostawi sobie najbardziej kosztowny filtr. Dodatkowo ostatni filtr zostanie nałożony tylko na dokumenty, które pasują do zapytania i wszystkich pozostałych filtrów (ze względu na to, że atrybut <em>cost</em> wynosi więcej, niż 100).</p>
<p>Należy pamiętać, że atrybut <em>cost</em> działa tylko wtedy, kiedy filtr nie jest cache&#8217;owany.</p>
<h3>Podsumowanie</h3>
<p>Parametry <em>cache </em>oraz <em>cost</em> pozwalają na kontrolę tego co umieszczane jest w cache&#8217;u Solr, co jest przydatne wtedy kiedy wiemy jakie zapytania zadawane są do naszych instancji Solr. Co więcej, w przypadku korzystania z obu z nich jesteśmy w stanie poprawić wydajność niektórych zapytań, szczególnie tych z atrybutem <em>cost</em> większym, niż 100. Warto więc przyjrzeć się swoim zapytaniom i zastanowić się, czy na pewno chcemy cacheować wszystkie wykorzystywane filtry <img src="https://s.w.org/images/core/emoji/17.0.2/72x72/1f642.png" alt="🙂" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
]]></content:encoded>
					
					<wfw:commentRss>https://solr.pl/2012/03/05/uzycie-parametrow-cachefalse-i-cost-w-zapytaniach/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
