Zend_Search_Lucene-BestPractice.xml 24 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 18715 -->
  3. <!-- Reviewed: no -->
  4. <sect1 id="zend.search.lucene.best-practice">
  5. <title>Die besten Anwendungen</title>
  6. <sect2 id="zend.search.lucene.best-practice.field-names">
  7. <title>Feldnamen</title>
  8. <para>
  9. Es gibt keine Begrenzungen für Feldnamen in <classname>Zend_Search_Lucene</classname>.
  10. </para>
  11. <para>
  12. Trotzdem ist es eine gute Idee die '<emphasis>id</emphasis>' und
  13. '<emphasis>score</emphasis>' Namen nicht zu verwenden um Doppeldeutigkeiten in den Namen
  14. der <code>QueryHit</code> Eigenschaften zu verhindern.
  15. </para>
  16. <para>
  17. Die <classname>Zend_Search_Lucene_Search_QueryHit</classname> <code>id</code> und
  18. <code>score</code> Eigenschaften referieren immer zur internen Lucene Dokumenten Id und
  19. Treffer- <link linkend="zend.search.lucene.searching.results-scoring">Anzahl</link>.
  20. Wenn ein indiziertes Dokument die gleichen Felder gespeichert hat, muß die
  21. <methodname>getDocument()</methodname> Methode verwendet werden um auf Sie zuzugreifen:
  22. <programlisting language="php"><![CDATA[
  23. $hits = $index->find($query);
  24. foreach ($hits as $hit) {
  25. // Das 'title' Dokumentfeld erhalten
  26. $title = $hit->title;
  27. // Das 'contents' Dokumentfeld erhalten
  28. $contents = $hit->contents;
  29. // Die interne Lucene Dokument ID erhalten
  30. $id = $hit->id;
  31. // Die Anzahl der Abfragetreffer erhalten
  32. $score = $hit->score;
  33. // Das 'id' Dokumentfeld erhalten
  34. $docId = $hit->getDocument()->id;
  35. // Das 'score' Dokumentfeld erhalten
  36. $docId = $hit->getDocument()->score;
  37. // Ein anderer Weg um das 'title' Dokumentfeld zu erhalten
  38. $title = $hit->getDocument()->title;
  39. }
  40. ]]></programlisting>
  41. </para>
  42. </sect2>
  43. <sect2 id="zend.search.lucene.best-practice.indexing-performance">
  44. <title>Geschwindigkeit von Indezes</title>
  45. <para>
  46. Die Geschwindigkeit von Indezes ist ein Kompromiss zwischen verwendeten Ressourcen, der
  47. Zeit für das Indizieren und die Qualität des Index.
  48. </para>
  49. <para>
  50. Die Qualität des Index wird komplett eruiert durch die Anzahl an Indexsegmenten.
  51. </para>
  52. <para>
  53. Jedes Indexsegment ist ein komplett unabhängiger Teil von Daten. Deshalb benötigt ein
  54. Index der mehr Segmente hat, auch mehr Speicher und mehr Zeit für das Suchen.
  55. </para>
  56. <para>
  57. Indexoptimierung ist ein Prozess der mehrere Segmente in ein neues zusammenfügt. Ein
  58. komplett optimierter Index enthält nur ein Segment.
  59. </para>
  60. <para>
  61. Komplette Indexoptimierung kann mit der <methodname>optimize()</methodname> Methode
  62. durchgeführt werden:
  63. <programlisting language="php"><![CDATA[
  64. $index = Zend_Search_Lucene::open($indexPath);
  65. $index->optimize();
  66. ]]></programlisting>
  67. </para>
  68. <para>
  69. Index Optimierung arbeitet mit Daten Streams und benötigt nicht viel Speicher dafür aber
  70. Prozessorzessourcen und Zeit.
  71. </para>
  72. <para>
  73. Lucene Index Segmente sind nicht aktualisierbar durch Ihre Natur (eine Aktualisierung
  74. erfordert das die Segment Datei komplett neu geschrieben wird). Deshalb erzeugt das
  75. Hinzufügen neuer Dokumente zu einem Index auch immer ein neues Segment. Das verkleinert
  76. natürlich die Qualität des Index.
  77. </para>
  78. <para>
  79. Der automatische Optimierungsprozess des Index wird nach jeder Erstellung eines Segments
  80. durchgeführt und besteht darin das Teilsegmente zusammengeführt werden.
  81. </para>
  82. <para>
  83. Es gibt drei Optionen um das Verhalten der automatischen Optimierung zu beeinflussen
  84. (siehe das Kapitel <link linkend="zend.search.lucene.index-creation.optimization">Index
  85. Optimierung</link>):
  86. <itemizedlist>
  87. <listitem>
  88. <para>
  89. <emphasis>MaxBufferedDocs</emphasis> ist die Anzahl an Dokumenten die im
  90. Speicher gepuffert werden bevor ein neues Segment erstellt und auf die
  91. Festplatte geschrieben wird.
  92. </para>
  93. </listitem>
  94. <listitem>
  95. <para>
  96. <emphasis>MaxMergeDocs</emphasis> ist die maximale Anzahl an Dokumenten die
  97. durch den automatischen Optimierungsprozess in ein neues Segment
  98. zusamengeführt werden.
  99. </para>
  100. </listitem>
  101. <listitem>
  102. <para>
  103. <emphasis>MergeFactor</emphasis> ermittelt wie oft die automatische
  104. Optimierung durchgeführt wird.
  105. </para>
  106. </listitem>
  107. </itemizedlist>
  108. <note>
  109. <para>
  110. Alle diese Optionen sind Objekteigenschaften von
  111. <classname>Zend_Search_Lucene</classname>, aber keine Indexeigenschaften. Sie
  112. beeinflussen nur das Verhalten des aktuellen
  113. <classname>Zend_Search_Lucene</classname> Objekts und können sich für
  114. verschiedene Skripte unterscheiden.
  115. </para>
  116. </note>
  117. </para>
  118. <para>
  119. <emphasis>MaxBufferedDocs</emphasis> hat keinen Effekt wenn nur ein Dokument pro
  120. Skriptausführung indiziert wird. Auf der anderen Seite ist das sehr wichtig für die
  121. Indizierung per Batch. Größere Werte erhöhen die Geschwindigkeit des Indizierens,
  122. benötigen aber auch mehr Speicher.
  123. </para>
  124. <para>
  125. Es gibt einfach keinen Weg um den besten Wert für den
  126. <emphasis>MaxBufferedDocs</emphasis> Parameter zu berechnen weil es von der
  127. durchschnittlichen Größe des Dokuments abhängt, dem verwendeten Analysator und dem
  128. erlaubten Speicher.
  129. </para>
  130. <para>
  131. Ein guter Weg um den richtigen Wert herauszufinden, ist die Durchführung von
  132. verschiedenen Tests mit den größten Dokumenten von denen man erwartet das Sie indiziert
  133. werden.
  134. <footnote>
  135. <para>
  136. <methodname>memory_get_usage()</methodname> und
  137. <methodname>memory_get_peak_usage()</methodname> können verwendet werden um die
  138. Verwendung des Speichers zu kontrollieren.
  139. </para>
  140. </footnote>
  141. Es ist eine gute Praxis nicht mehr als die Hälfte des erlaubten Speichers zu verwenden.
  142. </para>
  143. <para>
  144. <emphasis>MaxMergeDocs</emphasis> limitiert die Größe des Segments (in Dokumenten).
  145. Es begrenzt also die Zeit für die automatische Optimierung indem es garantiert das die
  146. <methodname>addDocument()</methodname> Methode nur eine bestimmte Anzahl oft ausgeführt
  147. wird. Das ist für interaktive Anwendungen sehr wichtig.
  148. </para>
  149. <para>
  150. Das Verkleinern des <emphasis>MaxMergeDocs</emphasis> Parameters kann auch die
  151. Geschwindigkeit des Batchinzieierens beeinflussen. Automatische Optimierung des Index
  152. ist ein iterativer Prozess und wird Schritt für Schritt durchgeführt. Kleine Segmente
  153. werden in größere zusammengeführt, und irgendwann werden Sie in sogar noch größere
  154. zusammengeführt und so weiter. Komplette Optimierung des Index wird durchgeführt wenn
  155. nur mehr ein großes Segment überbleibt.
  156. </para>
  157. <para>
  158. Kleinere Segmente verkleinern generell die Qualität des Index. Viele kleine Segmente
  159. können auch zu einem "Too many open files" Fehler führen, ausgelöst durch die
  160. Beschränkungen des Betriebsystems.
  161. <footnote>
  162. <para>
  163. <classname>Zend_Search_Lucene</classname> hält jedes Segment offen um die
  164. Geschwindigkeit des Suchens zu erhöhen.
  165. </para>
  166. </footnote>
  167. </para>
  168. <para>
  169. Generell sollte die Optimierung des Index für einen interaktiven Modus des Indizierens
  170. im Hintergrund durchgeführt werden und <emphasis>MaxMergeDocs</emphasis> sollte für die
  171. nicht zu klein für die Indizierung per Batch sein.
  172. </para>
  173. <para>
  174. <emphasis>MergeFactor</emphasis> beeinflußt die Frequenz der automatischen Optimierung.
  175. Kleinere Werte erhöhen die Qualität des nicht optimierten Index. Größere Werte erhöhen
  176. die Geschwindigkeit des Indizierens, aber auch die Anzahl an Segmenten. Das wiederum
  177. kann wieder zu einem "Too many open files" Fehler führen.
  178. </para>
  179. <para>
  180. <emphasis>MergeFactor</emphasis> gruppiert Indexsegmente anhand Ihrer Größe:
  181. <orderedlist>
  182. <listitem>
  183. <para>
  184. Nicht größer als <emphasis>MaxBufferedDocs</emphasis>.
  185. </para>
  186. </listitem>
  187. <listitem>
  188. <para>
  189. Größer als <emphasis>MaxBufferedDocs</emphasis>, aber nicht größer als
  190. <emphasis>MaxBufferedDocs</emphasis>*<emphasis>MergeFactor</emphasis>.
  191. </para>
  192. </listitem>
  193. <listitem>
  194. <para>
  195. Größer als
  196. <emphasis>MaxBufferedDocs</emphasis>*<emphasis>MergeFactor</emphasis>, aber
  197. nicht größer als
  198. <emphasis>MaxBufferedDocs</emphasis>*<emphasis>MergeFactor</emphasis>*<emphasis>MergeFactor</emphasis>.
  199. </para>
  200. </listitem>
  201. <listitem>
  202. <para>...</para>
  203. </listitem>
  204. </orderedlist>
  205. </para>
  206. <para>
  207. <classname>Zend_Search_Lucene</classname> prüft wärend jedem Aufruf von
  208. <methodname>addDocument()</methodname> ob das Zusammenführen von Segmentgruppen dazu
  209. führt das neu erstellte Segmente in die nächste Gruppe verschoben werden. Wenn ja, wird
  210. das Zusammenführen durchgeführt.
  211. </para>
  212. <para>
  213. Also kann ein Index mit N Gruppen
  214. <emphasis>MaxBufferedDocs</emphasis> + (N-1)*<emphasis>MergeFactor</emphasis> Segmente
  215. und zumindest
  216. <emphasis>MaxBufferedDocs</emphasis>*<emphasis>MergeFactor</emphasis><superscript>(N-1)</superscript>
  217. Dokumente enthalten.
  218. </para>
  219. <para>
  220. Das gibt eine gute Annäherung für die Anzahl an Segmenten im Index:
  221. </para>
  222. <para>
  223. <emphasis>NumberOfSegments</emphasis> &lt;= <emphasis>MaxBufferedDocs</emphasis> +
  224. <emphasis>MergeFactor</emphasis>*log
  225. <subscript><emphasis>MergeFactor</emphasis></subscript>
  226. (<emphasis>NumberOfDocuments</emphasis>/<emphasis>MaxBufferedDocs</emphasis>)
  227. </para>
  228. <para>
  229. <emphasis>MaxBufferedDocs</emphasis> wird durch den erlaubten Speicher eruiert. Das
  230. erlaubt es dem gewünschten Faktor für das Zusammenführen eine erwünschte Anzahl an
  231. Segmenten zu erhalten.
  232. </para>
  233. <para>
  234. Das Tunen des <emphasis>MergeFactor</emphasis> Parameters ist effektiver für die
  235. Geschwindigkeit der Indizierens per Batch als <emphasis>MaxMergeDocs</emphasis>. Aber es
  236. ist auch gröber. Deshalb sollte die obige Annäherung für das Tunen des
  237. <emphasis>MergeFactor</emphasis>'s verwendet werden und anschließend mit
  238. <emphasis>MaxMergeDocs</emphasis> herumgespielt werden um die beste Geschwindigkeit für
  239. die Indizieren per Batch zu erhalten.
  240. </para>
  241. </sect2>
  242. <sect2 id="zend.search.lucene.best-practice.shutting-down">
  243. <title>Index wärend des Herunterfahrens</title>
  244. <para>
  245. Die <classname>Zend_Search_Lucene</classname> Instanz führt einiges an Arbeit während
  246. des Herunterfahrens durch, wenn Dokumente zum Index hinzugefügt aber nicht in ein neues
  247. Segment geschrieben wurden.
  248. </para>
  249. <para>
  250. Das kann auch einen automatischen Optimierungsprozess anwerfen.
  251. </para>
  252. <para>
  253. Das Indexobjekt wird automatisch geschlossen wenn es, und alle zurückgegebenen QueryHit
  254. Objekte, ausserhalb des Sichtbereichs sind.
  255. </para>
  256. <para>
  257. Wenn das Indexobjekt in einer globalen Variable gespeichert wird, wird es nur am Ende
  258. der Skriptausführung zerstört
  259. <footnote>
  260. <para>
  261. Das kann auch vorkommen wenn der Index oder die QueryHit Instanzen in zyklischen
  262. Datenstrukturen referenziert werden, weil <acronym>PHP</acronym> Objekte mit
  263. zyklischen Referenzen nur am Ende der Skriptausführung beseitigt.
  264. </para>
  265. </footnote>.
  266. </para>
  267. <para>
  268. Die Behandlung von <acronym>PHP</acronym> Ausnahmen wird in diesem Moment auch
  269. Herunterfahren.
  270. </para>
  271. <para>
  272. Das beeinflußt den normalen Shutdown Prozess des Index nicht, kann aber eine akurate
  273. Diagnostik von Fehlern verhindern wenn ein Fehler wärend des herunterfahrens
  274. stattfindet.
  275. </para>
  276. <para>
  277. Es gibt zwei Wege mit denen dieses Problem verhindert werden kann.
  278. </para>
  279. <para>
  280. Der erste ist, dass das Herausgehen aus dem Sichtbereich erzwungen wird:
  281. <programlisting language="php"><![CDATA[
  282. $index = Zend_Search_Lucene::open($indexPath);
  283. ...
  284. unset($index);
  285. ]]></programlisting>
  286. </para>
  287. <para>
  288. Und der zweite ist, das eine commit Operation vor dem Ausführungsende des Skripts
  289. durchgeführt wird:
  290. <programlisting language="php"><![CDATA[
  291. $index = Zend_Search_Lucene::open($indexPath);
  292. $index->commit();
  293. ]]></programlisting>
  294. Diese Möglichkeit wird auch im Kapitel "<link
  295. linkend="zend.search.lucene.advanced.static">Fortgeschrittene Verwendung von Indezes
  296. als statische Eigenschaften</link>" beschrieben.
  297. </para>
  298. </sect2>
  299. <sect2 id="zend.search.lucene.best-practice.unique-id">
  300. <title>Dokumente anhand der eindeutigen Id erhalten</title>
  301. <para>
  302. Eine übliche Praxis ist es eindeutige Dokument Id's im Index zu speichern. Beispiele
  303. beinhalten URL, Pfad, Datenbank Id.
  304. </para>
  305. <para>
  306. <classname>Zend_Search_Lucene</classname> bietet eine
  307. <methodname>termDocs()</methodname> Methode um Dokumente zu empfangen die spezielle
  308. Terme enthalten.
  309. </para>
  310. <para>
  311. Das ist effizienter als die Verwendung der <methodname>find()</methodname> Methode:
  312. <programlisting language="php"><![CDATA[
  313. // Dokumente mit find() empfangen durch verwenden eines Abfragestrings
  314. $query = $idFieldName . ':' . $docId;
  315. $hits = $index->find($query);
  316. foreach ($hits as $hit) {
  317. $title = $hit->title;
  318. $contents = $hit->contents;
  319. ...
  320. }
  321. ...
  322. // Dokumente mit der find() Methode empfangen durch verwenden der Anfrage API
  323. $term = new Zend_Search_Lucene_Index_Term($docId, $idFieldName);
  324. $query = new Zend_Search_Lucene_Search_Query_Term($term);
  325. $hits = $index->find($query);
  326. foreach ($hits as $hit) {
  327. $title = $hit->title;
  328. $contents = $hit->contents;
  329. ...
  330. }
  331. ...
  332. // Dokumente mit der termDocs() Methode empfangen
  333. $term = new Zend_Search_Lucene_Index_Term($docId, $idFieldName);
  334. $docIds = $index->termDocs($term);
  335. foreach ($docIds as $id) {
  336. $doc = $index->getDocument($id);
  337. $title = $doc->title;
  338. $contents = $doc->contents;
  339. ...
  340. }
  341. ]]></programlisting>
  342. </para>
  343. </sect2>
  344. <sect2 id="zend.search.lucene.best-practice.memory-usage">
  345. <title>Speicherverwendung</title>
  346. <para>
  347. <classname>Zend_Search_Lucene</classname> ist ein relativ speicherintensives Modul.
  348. </para>
  349. <para>
  350. Es verwendet Speicher um Informationen zu Cachen, das Suchen zu optimieren und das
  351. Indizieren zu beschleunigen.
  352. </para>
  353. <para>
  354. Der benötigte Speicher ist für unterschiedliche Modi verschieden.
  355. </para>
  356. <para>
  357. Der Verzeichnisindex der Ausdrücke wird während der Suche geladen. Das ist aktuelle
  358. jeder 128 <superscript>te</superscript> Ausdruck des kompletten Verzeichnisses.
  359. <footnote>
  360. <para>
  361. Das Lucene Dateiformat erlaubt es diese Zahl zu ändern, aber
  362. <classname>Zend_Search_Lucene</classname> bietet keine Möglichkeit das über
  363. seine <acronym>API</acronym> durchzuführen. Trotzdem gibt es die Möglichkeit
  364. diesen Wert zu ändern wenn er mit einer anderen Lucene Implementation
  365. vorbereitet wird.
  366. </para>
  367. </footnote>
  368. </para>
  369. <para>
  370. Deswegen ist der Speicherverbrauch erhöht wenn man eine große Anzahl an eindeutigen
  371. Ausdrücke hat. Das kann passieren wenn man ungeteilte Phrasen als Feld Werte verwendet,
  372. oder ein großes Volumen von nicht-textuellen Informationen hat.
  373. </para>
  374. <para>
  375. Ein nicht optimierter Index besteht aus verschiedenen Segmenten. Er erhöht auch den
  376. Speicherverbrauch. Segmente sind voneinander unabhängig, sodas jedes Segment sein
  377. eigenes Verzeichnis an Ausdrücken enthält und den Verzeichnisindex der Ausdrücke. Wenn
  378. der Index aus <emphasis>N</emphasis> Segmenten besteht kann der Speicherverbrauch im
  379. schlimmsten Fall <emphasis>N</emphasis> mal so groß sein. Eine Optimierung des Index
  380. kann durchgeführt werden um alle Segmente in eines zusammenzuführen um diesen
  381. Speicherverbrauch zu verhindern.
  382. </para>
  383. <para>
  384. Indizierung verwendet den gleichen Speicher wie das Suchen und zusätzlich Speicher für
  385. das Puffern von Dokumenten. Die Größe des Speichers der hierfür verwendet wird kann mit
  386. dem <emphasis>MaxBufferedDocs</emphasis> Parameter verwaltet werden.
  387. </para>
  388. <para>
  389. Index Optimierung (komplett oder teilweise) verwendet stream-artiges Bearbeiten von
  390. Daten und benötigt nicht viel Speicher.
  391. </para>
  392. </sect2>
  393. <sect2 id="zend.search.lucene.best-practice.encoding">
  394. <title>Verschlüsselung</title>
  395. <para>
  396. <classname>Zend_Search_Lucene</classname> arbeitet intern mit UTF-8 Strings. Das
  397. bedeutet also das alle von <classname>Zend_Search_Lucene</classname> zurückgegebenen
  398. Strings UTF-8 verschlüsselt sind.
  399. </para>
  400. <para>
  401. Man sollte sich keine Gedanken über Verschlüsselung machen solange man mit reinen
  402. <acronym>ASCII</acronym> Daten arbeitet, sollte aber vorsichtig sein wenn das nicht der
  403. Fall ist.
  404. </para>
  405. <para>
  406. Eine falsche Verschlüsselung kann Fehlernotizen wärend der Konvertierung oder den
  407. Verlust von Daten verursachen.
  408. </para>
  409. <para>
  410. <classname>Zend_Search_Lucene</classname> bietet einen breite Palette von Möglichkeiten
  411. für die Verschlüsselung von indizierten Dokumenten und analysierten Abfragen.
  412. </para>
  413. <para>
  414. Verschlüsselung kann explizit als optionaler Parameter bei den Felderstellung Methoden
  415. spezifiziert werden:
  416. <programlisting language="php"><![CDATA[
  417. $doc = new Zend_Search_Lucene_Document();
  418. $doc->addField(Zend_Search_Lucene_Field::Text('title',
  419. $title,
  420. 'iso-8859-1'));
  421. $doc->addField(Zend_Search_Lucene_Field::UnStored('contents',
  422. $contents,
  423. 'utf-8'));
  424. ]]></programlisting>
  425. Das ist der beste Weg um Problemen bei der verwendeten Verschlüsselung vorzubeugen.
  426. </para>
  427. <para>
  428. Wenn der optionale Parameter der Verschlüsselung unterdrückt wird, wird das aktuelle
  429. Gebietsschema verwendet. Das aktuelle Gebietsschema kann Daten zur
  430. Zeichenverschlüsselung, zusätzlich zur Spezifikation der Sprache, enthalten.
  431. <programlisting language="php"><![CDATA[
  432. setlocale(LC_ALL, 'fr_FR');
  433. ...
  434. setlocale(LC_ALL, 'de_DE.iso-8859-1');
  435. ...
  436. setlocale(LC_ALL, 'ru_RU.UTF-8');
  437. ...
  438. ]]></programlisting>
  439. </para>
  440. <para>
  441. Der selbe Weg wird verwendet um die Verschlüsselung beim Abfragestring zu setzen.
  442. </para>
  443. <para>
  444. Wenn die Verschlüsselung nicht definiert wird, wird das aktuelle Gebietsschema verwendet
  445. um die Verschlüsselung zu ermitteln.
  446. </para>
  447. <para>
  448. Verschlüsselung kann als optionaler Parameter übergeben werden, wenn die Abfrage
  449. explizit vor der Suche geparsed wird:
  450. <programlisting language="php"><![CDATA[
  451. $query =
  452. Zend_Search_Lucene_Search_QueryParser::parse($queryStr, 'iso-8859-5');
  453. $hits = $index->find($query);
  454. ...
  455. ]]></programlisting>
  456. </para>
  457. <para>
  458. Die Standardverschlüsselung kann auch mit der
  459. <methodname>setDefaultEncoding()</methodname> Methode spezifiziert werden:
  460. <programlisting language="php"><![CDATA[
  461. Zend_Search_Lucene_Search_QueryParser::setDefaultEncoding('iso-8859-1');
  462. $hits = $index->find($queryStr);
  463. ...
  464. ]]></programlisting>
  465. Ein leerer String impliziert das 'aktuelle Gebietsschema'.
  466. </para>
  467. <para>
  468. Wenn die richtige Verschlüsselung spezifiziert wurde, kann Sie vom Analysator richtig
  469. bearbeitet werden. Das aktuelle Verhalten hängt vom verwendeten Analysator ab. Siehe
  470. das Kapitel <link linkend="zend.search.lucene.charset">Zeichensatz</link> der
  471. Dokumentation für Details.
  472. </para>
  473. </sect2>
  474. <sect2 id="zend.search.lucene.best-practice.maintenance">
  475. <title>Index Wartung</title>
  476. <para>
  477. Es sollte klar sein das <classname>Zend_Search_Lucene</classname>, genauso wie jede
  478. andere Lucene Implementation, keine "Datenbank" ersetzt.
  479. </para>
  480. <para>
  481. Indizes sollten nicht als Datenspeicher verwendet werden. Sie bieten keine partiellen
  482. Backup/Wiederherstellungs Funktionen, Journal, Logging, Transactions und viele
  483. andere Features die mit Datenbank Management Systemen assoziiert werden.
  484. </para>
  485. <para>
  486. Trotzdem versucht <classname>Zend_Search_Lucene</classname> Indizes jederzeit in einem
  487. gültigen Status zu halten.
  488. </para>
  489. <para>
  490. Index Backup/Wiederherstellung sollte durch Kopieren des Inhalts des Index
  491. Verzeichnisses durchgeführt werden.
  492. </para>
  493. <para>
  494. Wenn der Index durch irgendeinen Grund beschädigt wird, sollte der beschädigte Index
  495. wiederhergestellt oder komplett neu gebaut werden.
  496. </para>
  497. <para>
  498. Es ist also eine gute Idee von großen Indizes ein Backup zu machen und ein Änderungslog
  499. zu speichern um manuelle Wiederherstellung + Roll-Forward Operationen durchzuführen wenn
  500. es notwendig ist. Diese Praxis reduziert die Wiederherstellungszeit des Index
  501. dramatisch.
  502. </para>
  503. </sect2>
  504. </sect1>