1 2
Re[4]: олюцернивание в избранное  новое горячее всё    подписка   модер. 
От: AndrewVK модератор 
Дата: 16.11.06 12:18
Здравствуйте, akasoft, Вы писали:

AVK>>Ага. И при порче или перестроении индекса терять все данные .

A>Ага, можно подумать, что в других случаях при порче есть выбор.

Вероятности порчи даже убогого джета и индексного файла мягко говоря не одинаковая.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[4]: олюцернивание в избранное  новое    модер. 
От: Igor Sukhov rsdn 
Дата: 16.11.06 14:44
Здравствуйте, akasoft, Вы писали:

A>В примере с поиском файлов дата вообще переводится в некое подобие unix timestamp, и уже по этому числу в строковом представлении фильтруется. М.б. имеет смысл поступить так же?

Попробуй и сравни. Т.к. обращения к БД все равно не избежать, тот тут надо сравнить скорость поиска по индексу в БД (поле dte) со скоростью поиска по, как ты сказал, timestamp полю в индексе Lucene.

Если Lucene будет фильтровать по timestamp-у путем тупого сравнения значений, так как не пожертвовав минутами и секундами, кучности значений, а значит и эффективного индекса не добиться — то это будет фигня, медленная фигня. Если это реализовано умнее, то:

может получиться что Access например по датам ищет медленно и в этом случае имеет смысл заранее отфильтровать идентификаторы сообщений по временному интервалу, а для MSSQL дополнительное наложенное условие по индексированному полю — только ускорит поиск, во всяком случае у меня щас он просто летает — запрос по всем форумам с интервалом поиска в 2 года выполняется за 2-3 секунды.
... << RSDN@Home 1.2.0 alpha rev. 0>>
* thriving in a production environment *
Re[5]: олюцернивание в избранное  новое    модер. 
От: akasoft 
Дата: 16.11.06 21:55
Здравствуйте, Igor Sukhov, Вы писали:

IS>Попробуй и сравни.

Попробую. Я думал, ты уже попробовал и знаешь.

Хотя, с другой стороны, уж лучше там оставить минимум данных, всё компактнее будет. Попробовал ейный оптимизатор (вызов Optimize() после построения части индекса), требует 2 раза по столько, сколько весит индекс. Пока не понял, оптимизирует, или в дуду играет. А может, это для удалённых документов задумано.

Формочку индексации я уже наваял. На своих > 1.7 млн. сообщений тоскливо ждать финала не видя конца туннеля и не имея возможности приостановить/продолжить. Хотя, можно наваять утилиту командной строки по переиндексированию ЛБД Януса.

Долго индекс строится, сабака! Обнадёживает, что ежедневный прирост сообщений "всего" 2-2.5 тыс. шт.

Ищет, конечно, уматно. Особенно словоформы. Ну и заморочка с пробелами и &, типа "сеансы в php" не то же самое, что и "сеансы&в&php". А нету ли у тебя ссылки на язык люсеновских поисковых запросов? Я невод покидал-покидал, но пока кроме док на 9 метров, Seekafile Server, книги по люсене и исходников к ней так пока и не нашёл. Вдруг завтра скачаю, а окажется, что там всё на яве. Не отчаиваюсь.

Ты писал тут
Автор: Igor Sukhov
Дата: 15.11.06
 кучу отмазок в конце про удаление, переносы... В общем, всё это побороть можно. При получении пакета сообщений мы можем построить список mid, а затем по этому списку скомандовать люсене удалить документы из индекса, и затем сделать выборку этих mid и переиндексировать. Тысячу сообщений она будет жевать порядка 20 секунд. Приемлимо. Сотню жуёт пару секунд. Хотя, наверное, больше тратит времени на открытие/закрытие индекса.
... << RSDN@Home 1.2.0 alpha rev. 666>> SQL Express 2005
Re[6]: олюцернивание в избранное  новое    модер. 
От: Igor Sukhov rsdn 
Дата: 16.11.06 23:23
Оценка:16 (1)
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

IS>>Попробуй и сравни.

(1)
A>Попробую. Я думал, ты уже попробовал и знаешь.

Ну я уже писал — работает очень быстро даже на медленной машине.
Проблему я решил — вместо минут запросы выполняются за пару секунд,
я же суровый практик — сэкономленная секунда — не стоит лишнего часа
разработки.

Чего мне сейчас в поиске не хватает — так это то что нельзя с найденными
сообщениями работать, как если бы я просматривал форум в штатном режиме —
ни поменить для дальнейшего просмотра, ни поменить как прочинатное/непрочитанное,
ни добавить в "Избранное". Вот это действительно серьезнейший косяк в дизайне.

A>Хотя, с другой стороны, уж лучше там оставить минимум данных, всё компактнее будет. Попробовал ейный оптимизатор (вызов Optimize() после построения части индекса), требует 2 раза по столько, сколько весит индекс. Пока не понял, оптимизирует, или в дуду играет. А может, это для удалённых документов задумано.

И сколько по времени эта оптимизация выполняется — если быстро, то имеет смысл вызывать ее после индексирования новой порции.

A>Формочку индексации я уже наваял. На своих > 1.7 млн. сообщений тоскливо ждать финала не видя конца туннеля и не имея возможности приостановить/продолжить. Хотя, можно наваять утилиту командной строки по переиндексированию ЛБД Януса.

Отлично.
Утилита командной строки идея неплохая — пускай с нее начнут те кто хочет Янус на linux переводить.

A>Долго индекс строится, сабака! Обнадёживает, что ежедневный прирост сообщений "всего" 2-2.5 тыс. шт.

Индексация 2-х тыщ сообщений — это секунды.

A>Ищет, конечно, уматно. Особенно словоформы. Ну и заморочка с пробелами и &, типа "сеансы в php" не то же самое, что и "сеансы&в&php". А нету ли у тебя ссылки на язык люсеновских поисковых запросов? Я невод покидал-покидал, но пока кроме док на 9 метров, Seekafile Server, книги по люсене и исходников к ней так пока и не нашёл. Вдруг завтра скачаю, а окажется, что там всё на яве. Не отчаиваюсь.

А зачем & ? AND — более привычная форма. Синтакис языка запросов тут — http://www.dotlucene.net/documentation/QuerySyntax.html, там и про что делать с & тоже написано.
Кстати, посмотри примеры запросы для date range поиска — как раз для твоего тестирования (*1).

A>Ты писал тут
Автор: Igor Sukhov
Дата: 15.11.06
 кучу отмазок в конце про удаление, переносы... В общем, всё это побороть можно. При получении пакета сообщений мы можем построить список mid, а затем по этому списку скомандовать люсене удалить документы из индекса, и затем сделать выборку этих mid и переиндексировать. Тысячу сообщений она будет жевать порядка 20 секунд. Приемлимо. Сотню жуёт пару секунд. Хотя, наверное, больше тратит времени на открытие/закрытие индекса.

Не нужно удалять сами документы, Document.RemoveFields и затем AddFields решают проблему и перенесенных и удаленных сообщений.
... << RSDN@Home 1.2.0 alpha rev. 0>>
* thriving in a production environment *
Re[7]: олюцернивание в избранное  новое    модер. 
От: akasoft 
Дата: 18.11.06 14:12
Здравствуйте, Igor Sukhov, Вы писали:

IS>Не нужно удалять сами документы, Document.RemoveFields и затем AddFields решают проблему и перенесенных и удаленных сообщений.

Похоже, это не так. Из метаданных:

        // Summary:
        //     Removes all fields with the given name from the document.  If there is no
        //     field with the specified name, the document remains unchanged.   Note that
        //     the removeField(s) methods like the add method only make sense prior to adding
        //     a document to an index. These methods cannot be used to change the content
        //     of an existing index! In order to achieve this, a document has to be deleted
        //     from an index and a new changed version of that document has to be added.
        
        public void RemoveFields(string name);

... << RSDN@Home 1.2.0 alpha rev. 666>> SQL Express 2005
Re[8]: олюцернивание в избранное  новое    модер. 
От: Igor Sukhov rsdn 
Дата: 18.11.06 19:58
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, Igor Sukhov, Вы писали:

IS>>Не нужно удалять сами документы, Document.RemoveFields и затем AddFields решают проблему и перенесенных и удаленных сообщений.

A>Похоже, это не так. Из метаданных:

A>

A>
A>        // Summary:
A>        //     Removes all fields with the given name from the document.  If there is no
A>        //     field with the specified name, the document remains unchanged.   Note that
A>        //     the removeField(s) methods like the add method only make sense prior to adding
A>        //     a document to an index. These methods cannot be used to change the content
A>        //     of an existing index! In order to achieve this, a document has to be deleted
A>        //     from an index and a new changed version of that document has to be added.
        
A>        public void RemoveFields(string name);
A>
Нда — точно И почему могли по-нормальному сделать
Ксати, а что Optimize то делает — ты писал что он

требует 2 раза по столько, сколько весит индекс. Пока не понял, оптимизирует, или в дуду играет. А может, это для удалённых документов задумано.


в он в 2 раза увеличивает размер индекса ? На сайте есть только что:

Merges all segments together into a single segment, optimizing an index for search.



сами же сегменты, а точнее их количество влияют как на скорость индексации так и на скорость поиска.
Нормального же примера или рекомендаций, как изменять количество сегментов, при

    1 Batch индексации
    2 Индексации небольшого количества документов
    3 Активном поиске

я найти у них не смог
... << RSDN@Home 1.2.0 alpha rev. 0>>
* thriving in a production environment *
Re[9]: олюцернивание в избранное  новое    модер. 
От: akasoft 
Дата: 20.11.06 12:07
Здравствуйте, Igor Sukhov, Вы писали:

IS>Ксати, а что Optimize то делает — ты писал что он

Оптимизирует индекс, удаляет удалённые документы (их можно восстановить при необходимости, как в dbf), сливает все сегменты в один, поэтому требует в 2 раза больше места. Полезно иногда делать, только не злоупотреблять. Сродни акцессовскому "сжать и восстановить". По индексу из одного сегмента и без хлама поиск быстрее и производительнее.

IS>я найти у них не смог

Я нашёл некоторые рекомендации на сайте zend, они люценовский движок используют.

По умолчанию SetMaxBufferedDocs выставлен в 10, что приводит к частому сбросу мелких порций на диск, надо выставить больше, например 4096. Тогда индекс строится существенно быстрее, но и память требует порядка 100 — 200 МБ. Это всё актуально при обработке (индексировании) большого массива данных. Поиск и на 10 вполне шустр.

Прикрутил я Люську к Янусу, вроде даже работает , тестирую сейчас...
... << RSDN@Home 1.2.0 alpha rev. 667>> SQLE 2005
Re[10]: олюцернивание в избранное  новое    модер. 
От: ironwit 
Дата: 20.11.06 12:33
Здравствуйте, akasoft, Вы писали:

A>Прикрутил я Люську к Янусу, вроде даже работает , тестирую сейчас...
ты же не забудь ее на access прикрутить
... << RSDN@Home 1.2.0 alpha rev. 667>>
Я не умею быть злым, и не хочу быть добрым.
Re[10]: олюцернивание в избранное  новое    модер. 
От: Igor Sukhov rsdn 
Дата: 20.11.06 14:46
Здравствуйте, akasoft, Вы писали:

A>Я нашёл некоторые рекомендации на сайте zend, они люценовский движок используют.

A>По умолчанию SetMaxBufferedDocs выставлен в 10, что приводит к частому сбросу мелких порций на диск, надо выставить больше, например 4096. Тогда индекс строится существенно быстрее, но и память требует порядка 100 — 200 МБ. Это всё актуально при обработке (индексировании) большого массива данных. Поиск и на 10 вполне шустр.

Ну 200 мегабайт это не много — а "существенно быстрее" — во сколько раз быстрее ?

A>Прикрутил я Люську к Янусу, вроде даже работает , тестирую сейчас...

Давно пора
... << RSDN@Home 1.2.0 alpha rev. 0>>
* thriving in a production environment *
Re[11]: олюцернивание в избранное  новое    модер. 
От: akasoft 
Дата: 20.11.06 16:42
Оценка:45 (4)
Здравствуйте, Igor Sukhov, Вы писали:

IS>Ну 200 мегабайт это не много — а "существенно быстрее" — во сколько раз быстрее ?

(c) "Сколько вешать в граммах?".

Тестов не делал, всё на глаз.

На моих 1.7 млн. сообщений при 10 индекс строился порядка 6-7 часов, потому что компьютер (P4/3.0GHz/2Gb RAM/SATA RAID) буквально вешался: через 30 сек после начала построения процессы System и TSVNCache.exe начинали жрать процессорное время до 20 и до 55 соответственно, остальное шло на Janus.exe.

Я, конечно, понимаю, что SVN ведёт мониторинг файловой системы, но не до такой же степени. Ну а от имени System у меня "бьёт в барабаны" DrWeb.

Оказалось, что Люськин индексатор клепает мелкие файлы со скоростью звука, тут же их затирает, объединяет... В общем, пипец как мне это не понравилось, и полез я искать чего по оптимизации. На моё удивление, нашёл на русском у zend про php , они Люську используют для поиска.

Со второй попытки нашёл нужную комбинацию , при первой Янус сожрал 2 с лишним гига памяти ничего не сбрасывая на диск, словил OutOfMemory. Не советую менять MaxMergeDocs, пусть будет MaxInt.

Сейчас выставил MaxBufferedDocs 4096, менее чем за 1.5 часа можно проиндексировать мои 1.7 млн. сообщений, пропуск проиндексированного массива в 800 тыс. занял порядка 10 мин.

Итого: менее 1.5 часа параллельно работая против более 6 часов с полной вешалкой для 1.7 млн. , объём индекса — 388 МБ, ЛБД SQL 2005 Express — 3.4 ГБ, при индексации Janus.exe хапает местами до 450 МБ, потом отдаёт до 70-90 "обычных" МБ.
... << RSDN@Home 1.2.0 alpha rev. 667>> SQL Express 2005
Re[11]: олюцернивание в избранное  новое    модер. 
От: akasoft 
Дата: 21.11.06 16:05
Здравствуйте, ironwit, Вы писали:

I>ты же не забудь ее на access прикрутить

Это бесплатно прилагается к SQL Express.

Сегодня испытал, на Акцессе тоже работает. Испытывал на моей конца прошлого года 2Г .mdb, более 1.2 млн. сообщений. За 10 мин. проиндексировала более 340 тыс. сообщений (27%). Быстро индексирует, быстрее SQLE, видимо, можно чего-то в SQLE подкрутить ещё. Прервал.

Поиск даже быстрее, бо акцесс у меня шустрее SQLE, выборки результата из ЛБД идут за секунду, в то время как SQLE требует нескольких секунд. Ну, конечно у меня акцессовская ЛДБ сжата и всё такое.
... << RSDN@Home 1.2.0 alpha rev. 667>> SQL Express 2005
Re[12]: олюцернивание в избранное  новое    модер. 
От: ironwit 
Дата: 22.11.06 05:41
Оценка: +2 :)
Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, ironwit, Вы писали:

I>>ты же не забудь ее на access прикрутить

A>Это бесплатно прилагается к SQL Express.

точно издеваешься. Бинарник в студию точнее из студии в файлы на рсдн
... << RSDN@Home 1.2.0 alpha rev. 667>>
Я не умею быть злым, и не хочу быть добрым.
Re[5]: олюцернивание в избранное  новое    модер. 
От: nitr0 
Дата: 08.12.06 09:48
Здравствуйте, Igor Sukhov, Вы писали:

IS>Я бы мог поделиться своим exe-ник, но у меня в нем есть несколько хаккерских модификаций которые будут работать только на моем ноутбуке.

А что за модификации, если не секрет ?
Для производительности ?
Travian user
Re[6]: олюцернивание в избранное  новое    модер. 
От: Igor Sukhov rsdn 
Дата: 09.12.06 09:15
Оценка:2 (1)
Здравствуйте, nitr0, Вы писали:

IS>>Я бы мог поделиться своим exe-ник, но у меня в нем есть несколько хаккерских модификаций которые будут работать только на моем ноутбуке.
N>А что за модификации, если не секрет ?

Вот доделаю — и покажу и расскажу. А пока — неготово.
... << RSDN@Home 1.2.0 alpha rev. 0>>
* thriving in a production environment *
1 2