Comments 36
Я правильно понимаю, что его можно поставить на отдельный сервер и обращаться к нему по tcp?
Да конечно, он может быть установлен на отдельном севере. Так же там может быть авторизация и SSL.
Т.е. архитектура такова, что прямого доступа к почтовым ящикам ему не надо? Если не секрет, какой объем почты у вас? Хотелось бы сопоставить цифры в статье к объему.
И, если я правильно понял, появляется контекстный поиск по вложениям в формате doc, pdf, etc?
Сейчас у меня почты около 5.5 Тb. Нет в данном варианте контекстный поиск по вложениям не настраивался, у Solr для этого есть дополнительная приблуда в виде Apache Tika, которую надо ставить и настраивать. Но это работает, проверял на тестовой машине, но не внедрял.
Т.е. по содержимому вложений в письмах вида .doc и т.п. искать без Apache Tika не будет? Вот этого поиска оч. не хватает…
Т.е. мы ставим отдельно Tika и указываем его в конфигах довкота? И перед тем, как отправить файл на идексацию, довкот его разберет с помощью Tika?
И и при этом это два независимых сервиса, правильно?
Да именно так, у dovecot есть отдельная опция:
fts_tika = http://tikahost:9998/tika

Доступно с версии 2.1+
И пару слов о неприменимости к эксплуатации schema.xml из комплекта dovecot можно? Почему?
По-умолчанию dovecot не использует wildcard поиск, т.е. если использовать схему из коробки то при поиске слова «отчёт» в результат не попадет слово «отчеты»,«отчетам»,«отчетов» и т.п. Как понимаете это не совсем правильно.
/>
От этого отказались что позволило снизить скорость индексации и размер базы solr
для того что бы искать вхождения пересобрали dovecot что позволило искать вхождение с помощью * и?

патч dovecot
— dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2017-10-05 13:10:44.000000000 -0400
+++ dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2018-02-20 05:10:33.192433172 -0500
@@ -63,7 +63,7 @@
unsigned int truncate_header:1;
};

-static const char *solr_escape_chars = "+-&|!(){}[]^\"~*?:\\/ ";
+static const char *solr_escape_chars = "+-&|!(){}[]^\"~:\\/ ";

static bool is_valid_xml_char(unichar_t chr)
{
Не очень Вас понял, у меня сейчас 2.2.32 версия dovecot. Можно более развернуто. Спасибо.
да, прошу прощения, чего то теги порвало.
отказались от этого:
filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="40"
размер индекса уменьшился в 10 раз, но так как из за этого перестало искать вхождения, то пришлось пропатчить довекот, вот этим патчем:
— dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2017-10-05 13:10:44.000000000 -0400
+++ dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2018-02-20 05:10:33.192433172 -0500
@@ -63,7 +63,7 @@
unsigned int truncate_header:1;
};

-static const char *solr_escape_chars = "+-&|!(){}[]^\"~*?:\\/ ";
+static const char *solr_escape_chars = "+-&|!(){}[]^\"~:\\/ ";

static bool is_valid_xml_char(unichar_t chr)
{

это позволило в поисковых запросах использовать *(0 или более символов) и ?(1 символ), время поиска почти не изменилось

еще поле user у меня имеет вот такой вид, без нее поиск в public namespaces не работал нормально:
field name=«user» type=«string» indexed=«true» stored=«true» required=«false» default=""
ps: 1500000 писем, размер индекса менее 6гб.
Поиск не находил письма, потому что для namespace индексить может под одним юзером, а искать другой.
Это директория в почте к которой можно дать доступ более чем 1 аккаунту, например можно делать public namespace для отдела и ввесь отдел будет видеть все письма которые к примеру можно перемещать туда с помощью sieve
поиск и вывод 100 писем из 16000 найденых(пагинация в веб морде) поиском на запрос *777*(поиск проводится по всем полям from, to, subj, body, headers..etc) в директории в которой всего около 350тыс писем заняло 10секунд.
поиск без * около 1.5с, для нас это допустимо
Но в таком случае, получается что пользователь сам должен вводить * и? А вот это для меня было не приемлемо, так как «НЕ как у google!!! » кричали пользователи. Поэтому я пожертвовал размером индекса в угоду пользователя. Но то что вы сделали, это было моей первой идеей, я тоже так сделал, но в итоге отказался.
эти изменения не я делал, и выкусить именно этот кусок врядли получится.
filter class=«solr.StopFilterFactory» ignoreCase=«true» words=«lang/stopwords_en.txt»/

Тут, я так понимаю, lang/stopwords_ru.txt?
Тут уже зависит от цели, если в рамках описаного вопроса, то нет, оставить так как в статье.
В 7.3 блок
updateProcessor class=«solr.AddSchemaFieldsUpdateProcessorFactory»
Выглядит как
updateProcessor class=«solr.AddSchemaFieldsUpdateProcessorFactory» name=«add-schema-fields»

После его удаления пишет, что
No such processor add-schema-fields

Я правильно понимаю, что надо удалить add-schema-fields из блока ниже^

<updateRequestProcessorChain name=«add-unknown-fields-to-the-schema» default="${update.autoCreateFields:true}"
processor=«uuid,remove-blank,field-name-mutating,parse-boolean,parse-long,parse-double,parse-date,add-schema-fields»
В schema.xml пара ворнингов про устаревшие плагины. TrieLongField и SynonymFilterFactory.
Из документации (https://lucene.apache.org/solr/guide/7_0/field-types-included-with-solr.html)
TrieLongField Deprecated. Use LongPointField instead.
Просто меняем?

А вот насчет второго пока не совсем понял…
Вот что пишут по второму
Use SynonymGraphFilterFactory instead, but be sure to also use FlattenGraphFilterFactory at index time (not at search time) as well.

И в то же время

public class FlattenGraphFilterFactory
extends TokenFilterFactory
Factory for FlattenGraphFilter.
WARNING: This API is experimental and might change in incompatible ways in the next release.

В общем, я так понимаю, проще синонимы отключить. Тем более, файл не заполнен, а заполнять его вручную — та ее идея…
Каксательно устаревших плагинов, то смотрите в документации, часть можно сменить часть оставить, у меня все поднималось на 7.1 и я еще не обновлялся, так как нет особо надобности.
Вы не встречали ошибку вида
doveadm(mailbox@domain.ru): Info: Sent: Caching mails seq=1..125
doveadm(mailbox@domain.ru): Panic: file http-client-request.c: line 1106 (http_client_request_send_more): assertion failed: (req->payload_input != NULL)
Аварийное завершение

при попытке проиндексировать ящик вручную? Странность в том, что со второго-третьего раза все может нормально пройти.
Смотрите логи Solr что и как он отвечает, сложно сказать в чем причина не имея логов.

касательно AddSchemaFieldsUpdateProcessorFactory лучше выложите свой конфиг полностью, тяжело подсказывать что-либо не видя того что вы наделали.
Solr.Exception: Early Eof.
При том отваливается он не по тайм-ауту, т.к. ошибка выскакивает сразу же.

Конфиг — я так понимаю, там под 1000 строк. Это стандартный конфиг, который идет с 7.3.
Only those users with full accounts are able to leave comments. Log in, please.