Промежуточные итоги
Давайте подведем промежуточные итоги.
Цель
Организовать упорядоченное локальное хранение частной коллекции материалов. Позволить быстро находить требуемые материалы.
Основная идея состоит в том, что каждый документ имеет определенную ценность для человека, и он после ознакомления с ним соотносит его в определенную собственную систему категорий и оценок. Эта система трудно формализуема, постоянно находится в процессе измененний и пересмотра. Она не может однозначна сведена к иерархической системе, скорее это сеть со сложными взаимосвязями.
Поэтому было решено использовать классический подход на основании использования ключевых слов, присваиваемых документу. Поиск, таким образом выгляди как задание набора ключевых слов, которым должен удовлетворять искомый документ.
Методология работы
Окончательно еще не прояснена. Но в общем случае: работа состоит из двух стадий:
1) помещение документа на жесткий диск
2) поиск нужного докуммента и его открытие
Задача 1. Помещение документа. Учет.
1) документ размещается где-то на диске
2) в индекс вносится путь к этому документу и набор ключевых слов, которым он соответсвует.
Задача 2. Поиск документа. Просмотр. Чтение.
1) сформировать набор ключевых слов
2) получить набор ссылок на документы
3) Уточнить запрос и с п. 1.
4) Если набор небольшой -- просмотр документов, для поиска нужной информации.
Ключевые слова
По классике, использование разрешается только ключевых слов из тезариуса -- специального тематического словаря. Это правильно. Но трудоемко. Как в реализации. Так и для пользователя. К тому же требует определенной культуры работы, которой нет.
Поэтому, разрешается использовать любые ключевые слова, которые сочтет нужными пользователь. Ключевое слово мы трактуем шире, фактически, это любая фраза, достаточно точно отражающая смысл (назначение) документа. Поиск, с целью упрощения работы, производится без учета регистра, в том числе и для национальных символов.
Предоставим пользователю инструмент для управления ключевыми словами, как-то:
-- список всех ключевых слов;
-- работа с ключевыми словами без учета регистра;
-- разрешены ключ. слова с любыми символами (ну, за некоторым исключением);
-- удаление указанного ключевого слова;
-- исправление указанного ключевого слова;
-- автодополненение ключевых слов при вводе;
-- добавление ключевого слова к группе документов.
Что храним. Формат хранения.
Храним:
1) Описание документа. Его краткое резюме. Чтоб можно было бы не открывая документ определить его содержимое.
2) Cсылку на сам документ (локальный путь);
3) Ссылку на первоисточник. Особенно актуально для материалов, найденных в сети.
4) Дата помещения в индексатор.
5) иконка для документа. Это более аткуально чем тип -- он может определяться по расширению документа, а иконка может служить как визуальным признаком, скажем, важности документа.
6) список ключевых слов.
На первый раз достаточно.
Все ресурсы храняться в иекстовом виде. Желательно, конечно, использовать кодировку Юникод (UTF-8). Но еще много в работе ПО, которое не умеет его поддерживать. Поэтому остановимся на кодировке ср-1251, потому что:
-- там есть национальные символы славянских языков;
-- самая распространенная.
Весь идекс хранится в плоском текстовом файле. Каждое поле -- одна строка, если поле ничего не содержит, то строка пустая. Файлов может быть несколько, но лучше один.
Дальше, замечания по форматам представления полей, в порядке их упоминания:
1) простой текст. Вместо симолов перевода строк используем подстроку '<p>'. В случае ввода пустой строки, обязательно добавляется один пробел. Первый символ предназначен для признака "удален".
Например:
Путеводитель по opennet.ru, заметки на полях.
2) считаем его относительным путем относит. заданной директории. Внутри путей выкидываем все подстроки '/../' Т.е. путь всегда должен быть абсолютным.
Например:
web/opennet/pages/guide.shtml
3) строка, как ее ввели
Например:
http://www.opennet.ru/guide.shtml
4) Дата в формате ГГГГ-ММ-ДД чч:мм (24 часовой формат)
Например:
2005-01-26 18:30
5) название файла иконки. Все доступные иконки лежат в одной директории, скажем ICONS
Например:
impotant.gif
6) список ключевых слов (фраз), разделенных точкой с запятой. Дойные пробелы заменяются на одинарные, все непечатные символя заменяются на пробел. Все ключевые слова преобразуются к нижнему регистру и упорядочиваются.
Например:
;ключевые слова;ипс;поисковые системы;
Оценка объема
Для начала попробуем оценить примерное количество документов, которое способен накопить отдельно взятый индивид. Вот несколько вариантов прикидок.
- Воспользумеся статистикой opennet.ru по состоянию на начало февраля.
Документов -- 14571
Новостей -- 4371
Ссылок -- 3768
Итого записей -- 22710
- По статистики с lib.ru она содержит
текстов -- 21200
проч. файлов -- 37000
Итого -- 58200
- На моем 120 Гб винте накопилось различных файлов 16674 шт. - это на тот случай, если мне вдруг захотелось проиндексировать все мои файлы.
- За вчера (средний день по активности) я нашел для себя полезными в какойто мере 17 страниц в инете. Берем из расчета 10 лет по 366 дней и каждый раз сохраняем порядка 20 документов. Итого -- 1244400 документов.
Резюмирую все вышесказанное, можно оценить верхнюю границу на уровне 2 млн. записей. В среднем бы я ориентровался на цифру порядка 30 тыс. документов.
Для человека такая цифра документов огромна, но не для современных БД и ФС. Отсюда важный практический вывод -- проблема балансировки и проч. "ускоряющих" весчей неактуальна и не заслуживает тех ухищрений, которые составляют львиную долю реализации вашей системы.
Вывод второй -- нужно таки придерживаться выработанного годами процесса проектирвоания софта. Сначала спроектирвоать, а уже потом заниматься реализацией.
Прикинем объем индекса
Я пока буду исходить из цифры 30_000 документов. Пусть в среднем каждое поле содержит по 80 симолов (эту цифру для первого приближения взял по субъективным основаниям). Полей 6. Каждое поле добавляет 2 символа перевода строки. Тогда общий размер индекса (текстового файла будет):
30000 * 6 * (80 + 2) = 14_760_000
Округляя, 15 Мб. Или, каждая 1000 документов, возможно(!), будет занимать 5Мб. Это приемлемо. Потом можно будет заняться оптимизацией, например, работать с упакованным индексом, разнести поля по разням файла и т.д.
Но, еще раз подчеркну, что этим нужно будет заниматься, когда выдвинутая идея докажет свою работоспособность!!!!!
Алгоритм основных операций
- Добавление новой записи
Тривиальный, выполняем проверку введенных строк на известные ограничения, и дописываем в конец файла
- Алгоритм поиска
Считаем что ключевые слова в поисковом запросе объеденены операцией "И". Тогда чтобы документ попал в выборку, у него должны присутствовать все ключевые слова. Т.к. ключевые слова в индексей отсортированы, то мы поискового запроса довольно просто строим регулярное выражение, которое и применяем ко всем наборам ключевых слов.
Например, пусть задано поисковое выражение: НТИ; биология
Тогда, наши действия:
1) Упорядочиваем ключевые слова в поисковой фразе. Теперь это будет так: биология; НТИ
2) Строим шаблон поиска (регулярное выражение). В нашем случае он примет вид (синтаксис Perl):
=~/.*;НТИ;.*;биология;.*/o
шаблон, правда не учитывает случай ";НТИ;биология;". Но это обходится.
3) Если найшли больше лимита (скажем больше 100 документов) поиск прерываем. И так очевидно, что запрос нужно уточнять.
- Составление списка всех ключевых слов
Сканируем весь индекс, и каждое ключевое слово рассматриваем как ключ хэша. Заоодно считаем частоту его употребления. Потом, из хэша достаем все ключи, сортируем и получаем список всех ключевых слов. На Perl это будет выглядеть примерно так:
undef %KeyWords;
# составляем список ключевых слов
while ( NextDocInIndex() ) {
foreach $i ( split(';', $KEYWORDS) ) {
next if $i eq '';
$KeyWords{$i}++ ;
} ;
} ;
# выводим этом спсиок
foreach $word (sort keys %KeyWords) {
print "$words ($KeyWords{$word})\n" ;
};
- Удаление документа
В силу того, что фактически мы имеем плотный файл, то будем использовать механизм "обелисков" или "признаков". В первом поле, в первой позиции для для таких документов будем писать определенный символ, скажем \b.
- Правка полей индекса.
Мы будем ее рассматривать как комбинацию двух уже реализованных операций -- добавление новой записи и удаление предыдущей. В добавок мы получаем возможность восстановления предыдущих значений.
Как отрицательный момент -- это необходимость выполнения периодически реорганизации. Т.е. фактически перезаписи старого в новый файл, пропуская помеченные записи.
Вот такие несложные алгоритмы.