Как хранить документацию программ, библиотек и языков, которые вы используете

Поскольку я часто работаю без быстрого или даже любого интернет-соединения, у меня есть веб-сервер, который обслуживает обычно используемую документацию, например:

Различные языки программирования (php, Python, Java,...)
Различные библиотеки (например, pthreads)
Различные открытые книги
РЛК
Проекты IETF
Википедия (только для текста, несжатый английский дамп файл весит 20 ГБ!)
Галерея клипартов

Я использую их, даже когда я в сети, - меньше необходимости поиска, и я могу grep файлы, если это необходимо. Однако эта коллекция занимает много места, около 30 ГБ, поэтому я бы хотел сжать ее.

Кроме того, я ищу хороший способ найти весь этот материал. В прошлый раз, когда я пытался, настольные поисковые системы не могли справиться с тысячами или очень, очень большими файлами - и я предполагаю, что любой значащий индекс будет больше, чем часть исходного текста. Поэтому я хотел бы индексировать только определенные области (например, только название Википедии, или только заголовок и первый абзац, или только краткое описание функции).

Есть ли такое решение, которое позволяет искать в нем, распаковать нужную часть сжатого файла и форматировать? it?

¹, например, сохранение ссылок в документации HTML, преобразование PDF в HTML

Ответ 1

Думали ли вы об использовании Apache Lucene для этой цели? Легко индексировать только то, что вы хотите, и вы также можете подумать о написании собственного анализатора для определенного формата файлов, который не управляется изначально Lucene.

EDIT: вы должны действительно подумать о таком решении, поскольку Lucene предлагает довольно простой API для запроса индексов, он достаточно хорошо документирован, и вы можете найти много ресурсов об этом в Интернете. Также, поскольку ваша проблема может заинтересовать многих людей, возможно, это может быть хорошим началом для проекта с открытым исходным кодом для создания персональной поисковой системы. Это может быть сложным и интересным для огромного количества людей, которых я предполагаю.

Почему я выбрал этот ответ: я собираюсь написать приложение, которое делает именно то, что задается, возможно, используя Lucene. Я ожидаю, что две основные проблемы будут выбирать, что индексировать (например, только <title> в дампе википедии) и индексировать сжатые файлы, не распаковывая их полностью (или индексировать при сжатии). Как только я выпущу его, я добавлю ссылку здесь. Спасибо за все ваши ответы! --phihag

Ответ 2

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

Однако для вашего случая 30 ГБ данных действительно не так много. С точки зрения соотношения усилий/затрат и выгод правильное решение, вероятно, "купит новый жесткий диск". Приводы 1TB составляют менее 100 долларов США, разработка качественного решения для этого, вероятно, потребует огромных усилий. Если вы не цените свое время много (или просто наслаждаетесь работой над проблемой), гораздо проще просто купить больше места.

Ответ 3

В зависимости от того, какую ОС вы используете, Microsoft Compiled HTML Help файлы могут быть хорошим вариантом. PHP имеет документацию, доступную как CHM. Вы можете получить компилятор здесь.

Ответ 4

(Этот ответ предполагает, что вы находитесь на Linux или аналогичном.)

Для части сжатия вы можете попробовать что-то вроде FuseCompress, что позволит вам смонтировать каталог как сжатый файловая система. Сжатие происходит при записи, декомпрессия происходит при чтении. Я никогда не использовал это, но в прошлом я использовал другие файловые системы на основе плавких предохранителей без проблем. Некоторые поисковые системы Google использовали некоторые другие варианты с плавным предохранителем.

Это сохраняет читаемость/разборчивость/возможность поиска в качестве стандартного текста через точку крепления плавкого предохранителя, но может обеспечить значительную экономию места. Однако доступ будет медленнее, чем просто доступ к необработанному тексту.

Что касается возможности поиска, если вы сохраняете доступность как сырой текст, у вас есть тонна опций. Beagle и Tracker приходят на ум.

Ответ 5

Если это сервер Windows, включите сжатие NTFS. Он работает достаточно хорошо для текста. Что касается очень, очень больших файлов - вы имеете в виду дамп Википедии? Попытайтесь разделить его на более мелкие куски и попробуйте другие программы поиска на рабочем столе. Copernic Desktop Search работал очень хорошо для меня. Он имеет множество настроек, которые могут помочь вам оптимизировать индексирование "глубина" и производительность.

Ответ 6

Во-первых, как утверждают другие, 30 ГБ не так много. Просто купите другой или более жесткий жесткий диск. Вы также можете сжать его в ОС Windows, используя опцию файла сжатия. Щелкните правой кнопкой мыши по папке/файлу и щелкните свойства. Нажмите "Дополнительно". Проверьте "Сжать содержимое, чтобы сохранить дисковое пространство". Нажмите "Применить".

Для поиска я не уверен, что ваша ОС, или если вы можете ее изменить, но Microsoft Search Server Express (БЕСПЛАТНО) может быть вашим лучшим вариантом, если он хранится в одном из многих форматов, которые Search Search может искать. Поскольку он также использует ifilters, вы также можете создать свой собственный ifilter. Если вы не можете перейти на ОС Windows Server, то используйте Desktop Search. Я предпочитаю разрабатывать на ОС сервера, поэтому для меня это не мешает мне, однако, в какой-то момент службе поиска потребуется индексировать всю эту информацию.

Ответ 7

Одна интересная концепция, которую я нашел, - это способ использования архива wikipedia bzip offline: http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.html

этот метод может быть адаптирован к любой документации, которую вы хотите

Ответ 8

Кросс-платформа (ну, как минимум, Linux/Windows):

Храните документы в оригинале формат (будь то текст, html, pdf...), поэтому вы не теряете форматирование.
Сжимайте их, используя ваш любимый алгоритм сжатия и помещать их в меньшие (возможно, тематические?) архивы...
Используйте Xapian (Python, Perl, С++...) для создания полнотекстового индекса по всем вашим документам. Если это всего 30Gb, вероятностный поиск текста будет невероятно быстрым. Обязательно сохраните ссылку на путь отдельных файлов в ваших индексах Xapian.

Ссылки:

http://www.xapian.org/
Вы можете найти пример того, как создать быстрый автономный википедический считыватель с Xapian здесь, что может дать вам некоторые идеи о том, как начать: http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.html

Ответ 9

У меня была эта же проблема

Не записывайте ничего. его было сделано:)

doxmentor4j позволяет переносить библиотеку транспорта (взять с собой ваш репозиторий и использовать его в любом месте) и использовать lucene в качестве своего движка. chm файлы, которые вы называете, lucene ест это

наслаждайтесь!

Ответ 10

Debian (и ubuntu, я уверен) имеет пакеты с именем debhelp и dhtml, который представляет веб-интерфейс поиска (включая логический поиск) и может использоваться для индексации всех документов в /usr/share/doc - PDF файлы, HTML, PS и т.д., А также man-страницы, документы texinfo и т.д. Я полагаю, что не так сложно подключить дополнительные файлы; возможно, просто поместите их в каталог, возможно, с текстовым индексным файлом. Я также создал тонкие обертки вокруг некоторых debian других пакетов поисковых систем (namazu, для одного) и получил хорошие результаты.

Ответ 11

поисковые устройства Google, а поддерживающие приложения несколько дороги, возможно, для вашего приложения (может быть?), но они замечательные, и они знают как обращаться с файлами в сотнях разных форматов. В целом, для хранения данных в 30 ГБ на самом деле это не так много места, и избежать сжатия будет намного проще индексировать, получать доступ и поддерживать.

Ответ 12

i хранят их в текстовой форме.

не привязаны к какой-либо конкретной компании (солнце, мс, google)

на любом языке компьютера или os

неотъемлемо читаемый человеком

низкие накладные расходы

никакой серьезный человек не согласится