[lorien] Error: Cannot found any index for you query.
Раньше база была маленькая, поэтому непосредственный просмотр ее осуществлялся быстро. Теперь база большая и полный поиск по ней работает долго. Основная проблема в том, что база не влезает в оперативную память, а при каждом поиске читать сотни мегабайт с диска нереально.
Поэтому для ускорения поиска применяются индексы. Соответственно, иногда возникает ситуация, что для какого-то слова индекс найти не удается (например mp3 или gif - наиболее часто используемы слова). В таких случаях выдается указанное сообщение.
Это техническое ограничение (в том смысле, что это не случайная ошибка, а так было задумано). Я пока не придумал как составлять индексы для слов с цифрами. Дело в том, что слов сейчас ~600 тысяч, а если разрешить цифры то будет ~1200 тысяч. Это ведет к сильному разбуханию словаря, индексов.
Вернуть все на место нельзя, так как база не влезает в память, старые безиндексовые алгоритмы более не работоспособны.
Поэтому для ускорения поиска применяются индексы. Соответственно, иногда возникает ситуация, что для какого-то слова индекс найти не удается (например mp3 или gif - наиболее часто используемы слова). В таких случаях выдается указанное сообщение.
Это техническое ограничение (в том смысле, что это не случайная ошибка, а так было задумано). Я пока не придумал как составлять индексы для слов с цифрами. Дело в том, что слов сейчас ~600 тысяч, а если разрешить цифры то будет ~1200 тысяч. Это ведет к сильному разбуханию словаря, индексов.
Вернуть все на место нельзя, так как база не влезает в память, старые безиндексовые алгоритмы более не работоспособны.
Мммм. А сколько не хватает памяти и какой?
Мб стоит попропросить админов всех сетей сброситься на гиг-другой.
ресурс, по-любому, этого стоит.
Мб стоит попропросить админов всех сетей сброситься на гиг-другой.
ресурс, по-любому, этого стоит.
Это конечно, может помочь, но только кратковременно.
База постоянно растет: http://lorien.local/mrtg/netsize.html (yearly graph)
Скоро наверное будет поиск по FTP, это еще увеличит базу раза в 1.5
Если так подходить то придется каждые пару месяцев покупать по планке памяти
imho это не правильный способ.
я хочу провести оптимизацию на уровне алгоритмов - строить более правильные индексы, в другом порядке хранить данные, не требуя увеличения объема занятой памяти. возможно это потребует некоторого времени на сбор статистики (какие запросы остаются без индекса) и теоретическое рюхание.
можно обсудить методы построения индексов прямо здесь. если кто-то выскажет идеи как улучшить работу - буду очень признателен.
База постоянно растет: http://lorien.local/mrtg/netsize.html (yearly graph)
Скоро наверное будет поиск по FTP, это еще увеличит базу раза в 1.5
Если так подходить то придется каждые пару месяцев покупать по планке памяти
imho это не правильный способ.
я хочу провести оптимизацию на уровне алгоритмов - строить более правильные индексы, в другом порядке хранить данные, не требуя увеличения объема занятой памяти. возможно это потребует некоторого времени на сбор статистики (какие запросы остаются без индекса) и теоретическое рюхание.
можно обсудить методы построения индексов прямо здесь. если кто-то выскажет идеи как улучшить работу - буду очень признателен.
а грузить с HDD сжатые индексы, распаковывая на лету не получится?
сами по себе индексы маленькие (~160 Mb в то время как информация о файлах занимает ~540 Mb. Индексы все время лежат в памяти и с ними все ок. Основная проблема - чтение с диска самого массива записей о файлах (или выборка записей с нужными id если нашелся индекс).
Глупый вопрос наверное задам. А информацию о файлах сжимать? Насколько я понимаю, проблемы именно со скоростью считывания информации.
Как ещё один вариант "железного" решения вопроса - RAID 0.
Как ещё один вариант "железного" решения вопроса - RAID 0.
> А информацию о файлах сжимать? Насколько я понимаю, проблемы именно со скоростью считывания информации.
Интересная мысль! Надо подумать. Строковую информацию, наверное, можно хорошо сжать (lzw какое-нибудь). Здесь явно будет выигрыш. Информация о дате/размере наверное хуже сожмется (все-таки более случайна).
Единственная трабла - сейчас доступ к таким структурам сделан "явно", с использованием C++ - указателей. При паковке/распаковке такое не применимо - придется как-то менять организацию доступа к данным.
Интересная мысль! Надо подумать. Строковую информацию, наверное, можно хорошо сжать (lzw какое-нибудь). Здесь явно будет выигрыш. Информация о дате/размере наверное хуже сожмется (все-таки более случайна).
Единственная трабла - сейчас доступ к таким структурам сделан "явно", с использованием C++ - указателей. При паковке/распаковке такое не применимо - придется как-то менять организацию доступа к данным.
развернуть эти явные указатели в IO-потоки. тогда какой-нить guzip покатит через | наверное.
Delete
TAS>Может посмотреть как что-то подобное реализовано в поисковиках (инетовских)?
Может хуйню скажу полную, но типа стандартные средства не катят? Не скажу, что у меня совсем уж много файлов на машине (~60000 но slocate ищет совершенно незаметно для глаза даже если использовать regexp-ы... База весит что то около 6 мегов правда Но машинка у меня слабенькая и оперативы всего 64 мега было когда то а результат был тот же. Есть подозрение, что байда типа glimpse еще круче с подобными задачами справится. Типа нужно просто создать на серваке фс, копирующую структуру сети, те сохраняющую папки (типа в корне папки V gz-v, hackers... дальше имена компов, шар,...) . А для файлов создать их двойников текстового вида с записями типа "типа" , размера, даты, айди 3 тега в конце концов... Затем по поисковому запросу прошерстить locate или glimpse эту псевдо сеть, получить сравнительно небольшое число текстовых файлов. Ну а дальше grep / fgrep / awk - наш лучший друг Можно даже просто оговорить, что первая строчка значит то то итд - тогда вообще просто...
По идее должно работать довольно быстро, особенно если использовать какуюнить шуструю фс типа reiser4, а базу в оперативе - она там кстати зипованая ( в slocate - точно можно сделать). Я так понимаю в данном случае база эта выступает в роли индексов скорее, размер не шибко большой должен получиться.
ps я понимаю, что это наполовину новый поисковик получится, но все же
Но машинка у меня слабенькая и оперативы всего 64 мега было когда то а результат был тот же. Есть подозрение, что байда типа glimpse еще круче с подобными задачами справится. Типа нужно просто создать на серваке фс, копирующую структуру сети, те сохраняющую папки (типа в корне папки V gz-v, hackers... дальше имена компов, шар,...) . А для файлов создать их двойников текстового вида с записями типа "типа" , размера, даты, айди 3 тега в конце концов... Затем по поисковому запросу прошерстить locate или glimpse эту псевдо сеть, получить сравнительно небольшое число текстовых файлов. Ну а дальше grep / fgrep / awk - наш лучший друг Можно даже просто оговорить, что первая строчка значит то то итд - тогда вообще просто... По идее должно работать довольно быстро, особенно если использовать какуюнить шуструю фс типа reiser4, а базу в оперативе - она там кстати зипованая ( в slocate - точно можно сделать). Я так понимаю в данном случае база эта выступает в роли индексов скорее, размер не шибко большой должен получиться.
ps я понимаю, что это наполовину новый поисковик получится, но все же
с какого века 60000 файлов уже много? у меня не меньше 600000 
Свежий линух, + мастдай в урезаном варианте и то и другое На 12 гигах шибко не разгуляешся
Да, я ща кстати на работе - на тутошней машинке 4 диска по 160 Гб почти полностью забиты, но тем не менее - всего ~ 600000 файлов и есть... Правда довольно много больших файлов, но все равно... А slocate ищет тоже ~ 0.01 s real time-a...
На 12 гигах шибко не разгуляешся Да, я ща кстати на работе - на тутошней машинке 4 диска по 160 Гб почти полностью забиты, но тем не менее - всего ~ 600000 файлов и есть... Правда довольно много больших файлов, но все равно... А slocate ищет тоже ~ 0.01 s real time-a...
на unix.hackers: 1868378 файлов 
Интересно, скока файлов пошарено в сетке? На лориене в статистике че то не нашел...
всего то 13 милионов * 2 если фтп еще будет Думаю намально будет работать...
Думаю намально будет работать...здесь, мягко говоря, совсем не те размеры чтобы работали стандартные средства.
взять тот же slocate - у него база 6 мегов. а тут база 540 мегов, в 90 раз больше.
создать на диске 13 миллионов файлов - тоже гиблое занятие. На каждый файл ведь хранится куча информации, типа владелец, дата, inode итп. Когда 13 миллионов файлов каждые дополнительные 4 байта оборачиваются 52 мегабайтами. Я думаю, файловая система загнется (или будет работать очень медленно).
grep/sed/awk - в топку, потому что grep-ать 540 мегабайт - это долго, при таких размерах просто необходимо использовать индексы.
Единственное, что представляет интерес - это glimpse. Он решает в некотором роде подобную задачу, и масштабы данных у него тоже большие. Я не знаю как он работает. Почитаю на досуге его сырцы. Думаю, там должны быть нетривиальные вещи.
взять тот же slocate - у него база 6 мегов. а тут база 540 мегов, в 90 раз больше.
создать на диске 13 миллионов файлов - тоже гиблое занятие. На каждый файл ведь хранится куча информации, типа владелец, дата, inode итп. Когда 13 миллионов файлов каждые дополнительные 4 байта оборачиваются 52 мегабайтами. Я думаю, файловая система загнется (или будет работать очень медленно).
grep/sed/awk - в топку, потому что grep-ать 540 мегабайт - это долго, при таких размерах просто необходимо использовать индексы.
Единственное, что представляет интерес - это glimpse. Он решает в некотором роде подобную задачу, и масштабы данных у него тоже большие. Я не знаю как он работает. Почитаю на досуге его сырцы. Думаю, там должны быть нетривиальные вещи.
Слушай, а ты можешь расшарить какой-нибудь дамп всех файлов сетки? Просто построчный. Хочу попробовать состыковать все это дело с уже существующими поисковиками.
не, грепать 540 мегов без мазы это факт. но я ведь ничего такого и не предлагал касательно же locate - если поиск по базе в 6 мегов занимает <0,01 секунды, то поиск по базе в 90 раз большей - это 1 секунда. На самом деле - я думаю, что сильно быстрее (кроме того - сам сказал индексы весят 160) . Насчет 13 миллионов файлов это ты не прав - на unix.hackers - 1,8 и все работает тип топ Я 100% уверен, что и 10^8 файлов не шибко большая проблема. У меня в лабе сервак сановский стоит с прикрученным дисковым массивом - дык там 24 ТБ данных со средним размером файла 100 кб. Там конечно не одна фс, но не 1000 по любому Крутится все это дело на xfs - не самая плохая файл система, но все же... reiser4 круче. Особенно если ее настроить именно под такую задачу. А глимпс - это тот же греп по сути, но переделанный сильно ( он сделан на основе powergrep, который на основе agrep, который на основе fgrep, a что это такое все и так знают Работает он, кстати довольно медленно. Идея была в том, чтобы использовать в качестве БД саму файловую систему (чем она и является по сути а в качестве таблицы индексов быстро работающую и к тому же сжатую базу slocate ( точнее даже просто locate, поскольку на права на файлы в данном случае положить ). Ща попробую создать 13 миллионов файлов и посмотреть, что из этого выйдет
касательно же locate - если поиск по базе в 6 мегов занимает <0,01 секунды, то поиск по базе в 90 раз большей - это 1 секунда. На самом деле - я думаю, что сильно быстрее (кроме того - сам сказал индексы весят 160) . Насчет 13 миллионов файлов это ты не прав - на unix.hackers - 1,8 и все работает тип топ Я 100% уверен, что и 10^8 файлов не шибко большая проблема. У меня в лабе сервак сановский стоит с прикрученным дисковым массивом - дык там 24 ТБ данных со средним размером файла 100 кб. Там конечно не одна фс, но не 1000 по любому Крутится все это дело на xfs - не самая плохая файл система, но все же... reiser4 круче. Особенно если ее настроить именно под такую задачу. А глимпс - это тот же греп по сути, но переделанный сильно ( он сделан на основе powergrep, который на основе agrep, который на основе fgrep, a что это такое все и так знают Работает он, кстати довольно медленно. Идея была в том, чтобы использовать в качестве БД саму файловую систему (чем она и является по сути а в качестве таблицы индексов быстро работающую и к тому же сжатую базу slocate ( точнее даже просто locate, поскольку на права на файлы в данном случае положить ). Ща попробую создать 13 миллионов файлов и посмотреть, что из этого выйдет Процесс пошел - уже миллион есть
Ну вот видишь как медленно создаются. Средняя скорость сканирования - 1 комп в минуту. Представь себе что тебе придется каждую минуту стирать/создавать тысячи файлов.
Конечно, можно создать 13 миллионов файлов, но по-моему накладные расходы при таком подходе будут просто чудовищные. Учти что создание каждого файла требует кучу системных вызовов.
Конечно, можно создать 13 миллионов файлов, но по-моему накладные расходы при таком подходе будут просто чудовищные. Учти что создание каждого файла требует кучу системных вызовов.
среднее число файлов на компе? Учти я все выводил в xterm, потому как заломало еще и условие туда приписывать и остановил просто по ctrl-c, когда 2 милиона стало. создает он легко ~100000 файлов в минуту. у тебя по сети полюбе больше инфы идет, а диск полюбе быстрее. ща график сделаю. Но первая индексация долго идет - эт без вопросов...
А как часто у тебя индексы перестраиваются?
В общем довел я число файлов до девяти миллионов с лишним ( с инкрементом в полтора) - дальше спать пора И построил графики зависимости от числа файлов всех интересующих меня величин - потом сделал оценку по линейному МНК (все зависимости очень линейны, кооф кореляции >0.99 ) и для 13 миллионов файлов получил следующие вещи:
1) Объем базы данных slocate.db = 42(1) Mb
2) Среднее время получения из файла инфы ( time cat `slocate filename`) - 0,891(8)
3) Ожидаемое время полной индексации всего дерева 60(5) минут.
Машина - p4 2,8Ghz без ht, 256mb с очень галимыми таймингами. hdd - хрен знает какой, но выдает на hdparm -T ~ 42 Mb/s
Файловая система - reiserfs3.6.
Жесткий диск 1 - те свап тоже на нем же, во время индексации проц загружен процентов на 80, в основном из за интенсивного своппинга ( машина не моя - поэтому на не gnome, gdesklets и все такое, памяти не хватает савсем.). Во время поиска использования процессора замечено не было Говорят, можно не индексировать заново, а обновлять только новые файлы, при этом время индексации должно сильно сократиться (до пары минут) . Как это сделать я пока не рюхнул. Для уменьшения времени поиска базу надо засунуть в оперативку - пробовать не стал - прав не хватает. Уменьшить накладные затраты на disk i/o можно если юзать SCSI диски и\или Reiser4fs. Создание и чтение миллионов мелких файлов - ее конек - тут она в ~1.5 раза быстрее и во столько же раз менее требовательна к процу. (поищи бенчмарки в инете). Еще было замечено, что время поиска не слишком сильно зависит от размера db - при 240000 файлов - это 0.099 с , при 13000000 - 0.891 - типа прямая. В общем ищет быстро и не навязчиво, индексирует долго и навязчиво 
Хотя повторюсь нужно только обновлять базу а не строить заново - тогда все будет очень даже пучком. Такие дела Кстати файловая система не тормозит при прибавлении такого числа файлов - я каждый раз мерял время копирования папки с 1.5 млн файлов - оно оставалось постоянным - около 25 минут, или примерно 1000 файлов в секунду - врядли лориен столько файла в секунду сканирует.... Содержание файла - текст "file is the #XXXXX" - те что то около 20 символов). Отожрали все эти файлы где то ГБ на миллион файлов. все.
PS не все - ядро 2.6.9 nitro 4 - то есть чисто десктопное, в котором как раз io функции и прибиты маленько. Так что я думаю - покатит такая тема в плане скорости, если толково все сделать....
И построил графики зависимости от числа файлов всех интересующих меня величин - потом сделал оценку по линейному МНК (все зависимости очень линейны, кооф кореляции >0.99 ) и для 13 миллионов файлов получил следующие вещи:1) Объем базы данных slocate.db = 42(1) Mb
2) Среднее время получения из файла инфы ( time cat `slocate filename`) - 0,891(8)
3) Ожидаемое время полной индексации всего дерева 60(5) минут.
Машина - p4 2,8Ghz без ht, 256mb с очень галимыми таймингами. hdd - хрен знает какой, но выдает на hdparm -T ~ 42 Mb/s
Файловая система - reiserfs3.6.
Жесткий диск 1 - те свап тоже на нем же, во время индексации проц загружен процентов на 80, в основном из за интенсивного своппинга ( машина не моя - поэтому на не gnome, gdesklets и все такое, памяти не хватает савсем.). Во время поиска использования процессора замечено не было
Говорят, можно не индексировать заново, а обновлять только новые файлы, при этом время индексации должно сильно сократиться (до пары минут) . Как это сделать я пока не рюхнул. Для уменьшения времени поиска базу надо засунуть в оперативку - пробовать не стал - прав не хватает. Уменьшить накладные затраты на disk i/o можно если юзать SCSI диски и\или Reiser4fs. Создание и чтение миллионов мелких файлов - ее конек - тут она в ~1.5 раза быстрее и во столько же раз менее требовательна к процу. (поищи бенчмарки в инете). Еще было замечено, что время поиска не слишком сильно зависит от размера db - при 240000 файлов - это 0.099 с , при 13000000 - 0.891 - типа прямая. В общем ищет быстро и не навязчиво, индексирует долго и навязчиво Хотя повторюсь нужно только обновлять базу а не строить заново - тогда все будет очень даже пучком. Такие дела Кстати файловая система не тормозит при прибавлении такого числа файлов - я каждый раз мерял время копирования папки с 1.5 млн файлов - оно оставалось постоянным - около 25 минут, или примерно 1000 файлов в секунду - врядли лориен столько файла в секунду сканирует.... Содержание файла - текст "file is the #XXXXX" - те что то около 20 символов). Отожрали все эти файлы где то ГБ на миллион файлов. все. PS не все - ядро 2.6.9 nitro 4 - то есть чисто десктопное, в котором как раз io функции и прибиты маленько. Так что я думаю - покатит такая тема в плане скорости, если толково все сделать...
.Был немножко изменен метод выделения слов для построения индексов. Теперь индексируются такие слова, как win2k, j2re, m2m (взято из реальных запросов, которые раньше не работали).
Все кто сталкивался с такой ошибкой - убедительная просьба проверить снова, ищется ли сейчас и написать сюда (или мне в приват/мыло).
Все кто сталкивался с такой ошибкой - убедительная просьба проверить снова, ищется ли сейчас и написать сюда (или мне в приват/мыло).
Оставить комментарий
helpall
Раньше поиск в лориене всегда выдавал результаты. А сейчас часть появляется ошибка вроде Error: Cannot found any index for you query., когда, как я понимаю, я использую в поиске слишком частоупотребимую последовательность символов. Или если её нет вообще.Нельзя ли всё вернуть на место? Очень неудобно получается, если, например, я пытаюсь искать что-то вроде "2004 \\ 01 mp3".