Здравствуйте, EugenF, Вы писали:
EF>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Занимаюсь похожей системой, идей и литературы перелопачено — тьма ЗХ>>Можем обсудить подробнее, вот только с чего начать? можно мылом zverok@kengu.ru
EF>Можно и мылом, только наверное основные идеи всё же выкладывать будем сюда, иначе форум начнёт терять смысл.
EF>К чему я пришёл за время прошедшее с момента написания сообщения. Задача условно разбивается на две практически непересекающиеся. EF>1) Непосредственное хранение документов и поиск по контенту. EF>2) Описание атрибутов документов и различные поиски по атрибутам — правда это только в случае, если необходимо обеспечить универсальность с-мы (т.е. в моём )
EF>По первому пункту. Необходимо хранить разбивку документа на разделы и дальше на абзацы, для абзаца хранится его текст с сохранением базового форматирования. Это необходимо для обеспечения контекстного поиска. Структура таблицы может быть примерно такой EF>
EF>Т.е. я храню уровень раздела в иерархии и ссылки на следующий и предидущий разделы. Востановить структуру док. по подобной таблице довольно таки просто.
тут, наверное, стану спорить. коль скоро мы храним и оригинал документа и его копию, оптимизированную для поиска (что, ИМХО, правильно), то оптимизировать для поиска нужно конкретно и хитро, а не просто разбить документ на слова. По этому поводу есть горы всяческих теорий, начиная от каких-то простейших словарей (типа "слово"-"в каких документах встречается") заканчивая семантическими сетями и проч.
Едем дальше. По твоему начальному сообщению не вполне понятно следующее — а) должны ли докУменты ка-то организовываться (в разделы, подразделы, и пр.) или просто храниться все скопом? б) должен ли поиск искать по текстам всех документов за раз? (ежли нет, то в предыдущем абзаце я чушь написал).
Дальше. Документы, выходит, имеют подозрительно иерархическую структуру (документ->раздел->абзац). Не стоит ли тут задуматься об XML ?
В общем, задачу хранения контента, ИМХО, не стоит решать в лоб, хранением здоровенных кусков текста в базе
EF>Также необходимо хранить оригинал документа, с которым никаких операций проводить нельзя кроме как скачать его на комп. пользователя. Поначалу я планировал написать для этой цели своё хранилище, потом отказался от этой идеи и собираюсь оригиналы также держать в базе. EF>Интересно насколько это оправдано ?
а who его знает... не могу назвать себя большим специалистом по базам данных (вот тут в меня полетять гнилые помидоры...). в моем случае, поскольку документы поступают в различных форматах, я предпочел хранить файлы на диске, зажатые zip'ом
EF>По второму пункту, по атрибутам, я думаю позднее
ок.
Во! Я поймал живого специалиста. Щаз я его буду спросить!
1) Где-то в старых ветках ты хвастался, что ободрал CHM как липку для дискметы. Можно поподробнее? И вообще по поводу форматов файлов ты небось немало знаешь? (интересуют .doc .chm .hlp .rtf .pdf и пр. распространенные текстовые форматы). Интересует добыча из оных тексту, ну и структуры по возможности (не в смысле форматирования, а иерархической структуры типа раздел-подраздел и т.п.)
2) Наверняка же знаешь кучу всякого умного про технологии полнотестового индексирования. В этом контексте интересно. что ты можешь сказать плохого/хорошего про семантические сети.
3) Какова эффективная структура для хранения всех данных ДИПС? Автор этой ветки собирается юзать БД, а ты, насколько я успел заметить, считаешь, что БД здесь нехороша (реляционная в шмысле). Что же тогда?
Может ли кто-нибудь подсказать ресурсы или поделиться собственным опытом по проектированию сабжа. Более конткретно — нужна с-ма предназначенная для хранения больших объемов докуметов. Только хранение и поиск — никакой модификации. Хранится должна именно струкура документа, с разделами, абзацами и т.п. Поиск возможен как по реквизитам описывающим весь документ в целом, так и контекстный по документу. В таком случае навигация будет вестись не по документам, а по структуре отдельного документа (перейти на следующий раздел, следующий абзац, ...). С-ма клиен-сервер. Среда функционирования — Windows 2000.
Интересует буквально все аспекты построения подобных с-м. Какую архитектуру избрать двух- или трёх-уровневую. Наброски структуры БД. Языки/средства разработки/СУБД.
Здравствуйте, EugenF, Вы писали:
EF>Приветствую уважаемое сообщество !
EF>Может ли кто-нибудь подсказать ресурсы или поделиться собственным опытом по проектированию сабжа. Более конткретно — нужна с-ма предназначенная для хранения больших объемов докуметов. Только хранение и поиск — никакой модификации. Хранится должна именно струкура документа, с разделами, абзацами и т.п. Поиск возможен как по реквизитам описывающим весь документ в целом, так и контекстный по документу. В таком случае навигация будет вестись не по документам, а по структуре отдельного документа (перейти на следующий раздел, следующий абзац, ...). С-ма клиен-сервер. Среда функционирования — Windows 2000.
EF>Интересует буквально все аспекты построения подобных с-м. Какую архитектуру избрать двух- или трёх-уровневую. Наброски структуры БД. Языки/средства разработки/СУБД.
EF>Заранее признателен за любую помощь.
Занимаюсь похожей системой, идей и литературы перелопачено — тьма
Можем обсудить подробнее, вот только с чего начать? можно мылом zverok@kengu.ru
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Занимаюсь похожей системой, идей и литературы перелопачено — тьма ЗХ>Можем обсудить подробнее, вот только с чего начать? можно мылом zverok@kengu.ru
Можно и мылом, только наверное основные идеи всё же выкладывать будем сюда, иначе форум начнёт терять смысл.
К чему я пришёл за время прошедшее с момента написания сообщения. Задача условно разбивается на две практически непересекающиеся.
1) Непосредственное хранение документов и поиск по контенту.
2) Описание атрибутов документов и различные поиски по атрибутам — правда это только в случае, если необходимо обеспечить универсальность с-мы (т.е. в моём )
По первому пункту. Необходимо хранить разбивку документа на разделы и дальше на абзацы, для абзаца хранится его текст с сохранением базового форматирования. Это необходимо для обеспечения контекстного поиска. Структура таблицы может быть примерно такой
Т.е. я храню уровень раздела в иерархии и ссылки на следующий и предидущий разделы. Востановить структуру док. по подобной таблице довольно таки просто.
Также необходимо хранить оригинал документа, с которым никаких операций проводить нельзя кроме как скачать его на комп. пользователя. Поначалу я планировал написать для этой цели своё хранилище, потом отказался от этой идеи и собираюсь оригиналы также держать в базе.
Интересно насколько это оправдано ?
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, EugenF, Вы писали:
EF>>Заранее признателен за любую помощь.
M>В своё время была у нас подобная система, построенная на основе Lotus Notes. Всё работало как часы, и ничего самому придумывать не надо.
Как это не надо ? В Лотусе подобную с-му нужно написать ещё Или купить... И нужно купить сам Лотус, а это очень даже немалые деньги.
ЗХ>тут, наверное, стану спорить. коль скоро мы храним и оригинал документа и его копию, оптимизированную для поиска (что, ИМХО, правильно), то оптимизировать для поиска нужно конкретно и хитро, а не просто разбить документ на слова. По этому поводу есть горы всяческих теорий, начиная от каких-то простейших словарей (типа "слово"-"в каких документах встречается") заканчивая семантическими сетями и проч.
Документы бьются не на слова, а на абзацы Связано это с некоторыми особенностями с-мы, например при контекстном поиске нужно показывать АБЗАЦ в котором найдено слово.
О "всяческих теориях" — я и собираюсь использовать одну из них, а именно механизм MS Indexing Services Зачем изобретать велосипед ? Пусть часть работы за меня выполняет служба, написанная людьми, которые рзбираются в поиске лучше.
ЗХ>Едем дальше. По твоему начальному сообщению не вполне понятно следующее — а) должны ли докУменты ка-то организовываться (в разделы, подразделы, и пр.) или просто храниться все скопом? б) должен ли поиск искать по текстам всех документов за раз? (ежли нет, то в предыдущем абзаце я чушь написал). ЗХ>Дальше. Документы, выходит, имеют подозрительно иерархическую структуру (документ->раздел->абзац). Не стоит ли тут задуматься об XML ? ЗХ>В общем, задачу хранения контента, ИМХО, не стоит решать в лоб, хранением здоровенных кусков текста в базе
Документы организовываются в группы, но об этом я собирался поговорить позже. Контекстный поиск — всегда по всем.
По поводу XML — какую я получаю выгоду кроме осознания своей крутости от использования моднейшей технологии ? Предположим — есть конкретные задачи
1) Поиск по документу слова, показывать абзац в котором слово найдено, должны быть доступны команды Next, Previous.
2) Показать структуру документа
Чем мне поможет XML ? Лёгкость программирования ? Нет. Скорость работы ? Смешно просто.
Я не вижу не одной выгоды от его использования кроме вышеупомянутой.
EF>>Также необходимо хранить оригинал документа, с которым никаких операций проводить нельзя кроме как скачать его на комп. пользователя. Поначалу я планировал написать для этой цели своё хранилище, потом отказался от этой идеи и собираюсь оригиналы также держать в базе. EF>>Интересно насколько это оправдано ?
ЗХ>а who его знает... не могу назвать себя большим специалистом по базам данных (вот тут в меня полетять гнилые помидоры...). в моем случае, поскольку документы поступают в различных форматах, я предпочел хранить файлы на диске, зажатые zip'ом
А как ты решаешь проблемы транзакционности, бекапа ?
EF>>По второму пункту, по атрибутам, я думаю позднее ЗХ>ок.
[покусано]
EF>О "всяческих теориях" — я и собираюсь использовать одну из них, а именно механизм MS Indexing Services Зачем изобретать велосипед ? Пусть часть работы за меня выполняет служба, написанная людьми, которые рзбираются в поиске лучше.
тады, конечно, ой... в смысле, не нужно заморачиваться с хранением структур для эффективного поиска.
[покусано]
EF>По поводу XML — какую я получаю выгоду кроме осознания своей крутости от использования моднейшей технологии ? Предположим — есть конкретные задачи EF>1) Поиск по документу слова, показывать абзац в котором слово найдено, должны быть доступны команды Next, Previous. EF>2) Показать структуру документа EF>Чем мне поможет XML ? Лёгкость программирования ? Нет. Скорость работы ? Смешно просто. EF>Я не вижу не одной выгоды от его использования кроме вышеупомянутой.
скажем так — по поводу ХМЛ, я, наверное, погорячился, но суть-то в чем — в извечной проблеме хранения иерархической структуры в реляционной БД. т.е. я выбрал его, родимого (ХМЛ), оскольку он является естественным способом хранения иерархических структур. Ну не радует меня отчего-то хранение всех разделов в одной таблице с указанием левела. ну и извечное стремление к свеженькой модели велосипеда, само собой...
EF>>>Также необходимо хранить оригинал документа, с которым никаких операций проводить нельзя кроме как скачать его на комп. пользователя. Поначалу я планировал написать для этой цели своё хранилище, потом отказался от этой идеи и собираюсь оригиналы также держать в базе. EF>>>Интересно насколько это оправдано ?
ЗХ>>а who его знает... не могу назвать себя большим специалистом по базам данных (вот тут в меня полетять гнилые помидоры...). в моем случае, поскольку документы поступают в различных форматах, я предпочел хранить файлы на диске, зажатые zip'ом
EF>А как ты решаешь проблемы транзакционности, бекапа ?
вот тут меня точно забросают гнилыми помидорами . Руками я эти проблемы решаю. Исключительно руками. (ну в смысле, файлы, зажатые зипом, куда-то там переписываются для бакапа, при транзакциях тож самое и пр.). Общаюсь вот с умными людьми и все больше начинаю подозревать, что пора открывать собственный клуб изобретателей велосипедов
а если серьезно, я сейчас тоже на этапе проектирования, но у меня как бы ТЗ предусматривает не просто хранение отвлеченных "текстовых документов", а доков в разных форматах (ворд, пдф, тхт, цхм и пр.), отчего и родилось (согласен, несколько неуклюжее) решение с зазипованными файлами.
dixi.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>скажем так — по поводу ХМЛ, я, наверное, погорячился, но суть-то в чем — в извечной проблеме хранения иерархической структуры в реляционной БД. т.е. я выбрал его, родимого (ХМЛ), оскольку он является естественным способом хранения иерархических структур. Ну не радует меня отчего-то хранение всех разделов в одной таблице с указанием левела. ну и извечное стремление к свеженькой модели велосипеда, само собой...
Ну хоть убей не понимаю я выгод от использования XML в данном случае. Для передачи данных — да, очень удобно, но для хранения... Хотя не буду навязывать свою точку зрения
ЗХ>вот тут меня точно забросают гнилыми помидорами . Руками я эти проблемы решаю. Исключительно руками. (ну в смысле, файлы, зажатые зипом, куда-то там переписываются для бакапа, при транзакциях тож самое и пр.). Общаюсь вот с умными людьми и все больше начинаю подозревать, что пора открывать собственный клуб изобретателей велосипедов ЗХ>а если серьезно, я сейчас тоже на этапе проектирования, но у меня как бы ТЗ предусматривает не просто хранение отвлеченных "текстовых документов", а доков в разных форматах (ворд, пдф, тхт, цхм и пр.), отчего и родилось (согласен, несколько неуклюжее) решение с зазипованными файлами. ЗХ>dixi.
Я тоже подумывал писать своё Тем более что я всё же больше системщик, а не специалист по базам Но время, время... Да и вариант с хранением файлов в БЛОБах может быть не так и плох.
Здравствуйте, EugenF, Вы писали:
EF>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>скажем так — по поводу ХМЛ, я, наверное, погорячился, но суть-то в чем — в извечной проблеме хранения иерархической структуры в реляционной БД. т.е. я выбрал его, родимого (ХМЛ), оскольку он является естественным способом хранения иерархических структур. Ну не радует меня отчего-то хранение всех разделов в одной таблице с указанием левела. ну и извечное стремление к свеженькой модели велосипеда, само собой...
EF>Ну хоть убей не понимаю я выгод от использования XML в данном случае. Для передачи данных — да, очень удобно, но для хранения... Хотя не буду навязывать свою точку зрения
ну хрен с ним, с ХМЛём.
но все же хочется какого-то ИЕРАРХИЧЕСКОГО хранилища
ЗХ>>вот тут меня точно забросают гнилыми помидорами . Руками я эти проблемы решаю. Исключительно руками. (ну в смысле, файлы, зажатые зипом, куда-то там переписываются для бакапа, при транзакциях тож самое и пр.). Общаюсь вот с умными людьми и все больше начинаю подозревать, что пора открывать собственный клуб изобретателей велосипедов ЗХ>>а если серьезно, я сейчас тоже на этапе проектирования, но у меня как бы ТЗ предусматривает не просто хранение отвлеченных "текстовых документов", а доков в разных форматах (ворд, пдф, тхт, цхм и пр.), отчего и родилось (согласен, несколько неуклюжее) решение с зазипованными файлами. ЗХ>>dixi.
EF>Я тоже подумывал писать своё Тем более что я всё же больше системщик, а не специалист по базам Но время, время... Да и вариант с хранением файлов в БЛОБах может быть не так и плох.
ок, будем считать это вопросом идеологии. тем более, что я тоже не специалист по базам (ща набегут специалисты и навешают нам по ушам )
Давай мыслить конструктивно. В сухом остатке имеем: а) необходимость все же какого-то иерархического хранилища абзацев б) необходимость эффективного (с одной стороны для транзакций, с другой — по размеру) хранилища докУментов целиком. с формулировкой согласен?
Кстати, может чуть больше расскажешь о своей системе — может, какие-то требования понятней станут? (я не настаиваю )
Написал такую простыню, и Янус навернулся. Поэтому повторно ооочень кратко:
EF>... подсказать ресурсы или поделиться собственным опытом по проектированию сабжа.
* searchengines.ru форум "Поисковые технологии" и другие. Особо уделить внимание ссылкам, даденым Ильей Сегаловичем (Yandex).
* Море всего на CiteSeer
* Ветка здесь
+ все ссылки с нее.
EF> Более конткретно — нужна с-ма предназначенная для хранения больших объемов докуметов. EF>Только хранение и поиск — никакой модификации.
Статический индекс на инвертированных файлах.
EF> Хранится должна именно струкура документа, с разделами, абзацами и т.п. Поиск возможен как по реквизитам описывающим весь документ в целом, так и контекстный по документу. В таком случае навигация будет вестись не по документам, а по структуре отдельного документа (перейти на следующий раздел, следующий абзац, ...).
Реконструкция текста подойдет? Так сделано у нас (meta.ua) и на Апорте. В таком случае в морфообраз (прямой индекс, в отличие от инвертированниго) стоит помещать признаки разметки, а также протаскивать запросы о разметке в сам поиск (тут я сильно сомневаюсь).
EF>С-ма клиен-сервер. Среда функционирования — Windows 2000.
Эти все навороты начинаются при требованиях в десятки тысяч поисковых запросов и огромных индексах. Тогда прийдется и демонов писать, и свой протокол обмена поверх сокетов, и распределять нагрузку на несколько серверов, и балансировать и много еще всякой пурги. Для 100 запросов в час вполне хватит одного поискового CGI-шника без всяких сложностей.
EF>Интересует буквально все аспекты построения подобных с-м.
Аспекты любой разработки становятся понятны только после публикации требований. Выше не хватает минимум определения требуемого быстродействия, основных операций (приоритет), требование к распределенности, т.д.
я рассказал, где искать. Ничего нового сказать не могу. Все парсеры я писал руками (без всяких грамматик и прочего), поэтому очень подолгу.
* Structured Storage based:
** doc
** xls
** (?) планируется (пока нету) ppt
* pdf — до момента выдирания букв текста из страниц. Дальше я не продвинулся с прошлого ноября.
* chm — сперто с сайта CodeProject (кажется), но они особо не в обиде.
С остальными понятия не имею. Тестовый парсер без мозгов для rtf делал (первая версия — за 2 дня, т.е. ничего сложного), но он сдох с моим прошлым винтом на пару, бо бэкапа нигде не было.
ЗХ>2)что ты можешь сказать плохого/хорошего про семантические сети.
Я не очень знаток поисковых технологий и тесно знаком только с одной. Однако, наши лингвисты очень критически относятся к применению семантики в построении поисковых систем общего назначения. Для примера, можно почитать высказывания Ашманова на searchengines.ru по этому поводу. Они соответствуют действительности, или, по крайней мере, почти всем представлениям, которые есть у наших специалистов (опробованы на практике). Про семантические сети должен уметь рассказать Александр Митрошин: их поисковая машина использует семантику при поиске. На его скорость это судя по этому сказывается сильно и не в лучшую сторону.
ЗХ>3) Какова эффективная структура для хранения всех данных ДИПС? Автор этой ветки собирается юзать БД, а ты, насколько я успел заметить, считаешь, что БД здесь нехороша (реляционная в шмысле). Что же тогда?
Есть разные данные. СУБД разработаны для хранения чисел. При всем к ним уважении это не то, что нужно для полнотекстового индексирования. Так-что, те части, что должны выполняться без потерь, на SQL-based базах не делают. За подробностями — searchengines.ru, форум "Поисковые технологии". Там много уважаемого народу, есть что почитать, ссылки хорошие дадены.
" тут есть теоретический предел: при приближении объёмов простого текста к 10-12 Гбайт, поисковики с хранением индекса в реляционных базах перестают работать."
Эффективная структура же зависит от большого кол-ва факторов. Способов построения инвертированных индексов много:
"Размеры разные — надо мерять".
Короче, надо смотреть на свои задачи.
А вообще, вот статья есть, в которой про построение все разжевано, а список литературы там — вообще сказочный. Пользуйтесь. Также, о своих технологиях много писали AltaVista и Google.
Здравствуйте, Kaa, Вы писали:
Kaa>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>1) И вообще по поводу форматов файлов ты небось немало знаешь? Kaa>Здесь
я рассказал, где искать. Ничего нового сказать не могу. ЗХ>>2)что ты можешь сказать плохого/хорошего про семантические сети.
Виноват, ветка моя, но поскольку в первые несколько дней практически ничего не ответили, я порешил. что тема никому не интересна и перестал туды возвращаться.
А вообще — спасибо преогромное. Я покуда удовлетворён
Здравствуйте, Mishka, Вы писали:
M>Здравствуйте, EugenF, Вы писали:
EF>>Заранее признателен за любую помощь.
M>В своё время была у нас подобная система, построенная на основе Lotus Notes. Всё работало как часы, и ничего самому придумывать не надо.
В свое время, в соседнем отделе (банк) забабахали док.ор. систему для клиентов... Поголовно все столкнулись с проблемой настройки и администрирования этого l.notes (нет нормальных специалистов, или может дорогие очень) — система умерла. Переписали под .Net.
Здравствуйте, Mishka, Вы писали:
M>В своё время была у нас подобная система, построенная на основе Lotus Notes. Всё работало как часы, и ничего самому придумывать не надо.
Судя по моему работы с Lotus Notes 4/5, там
отвратительный скрипт
неприятно продумана объектная модель (например, COM сервер клиента запускается через зад)
тупой отладчик
некрасивый гуй
ограничены типы данных для хранения в документах (хранить всё нестандартное в RTF-полях?????)
Для своего времени, может, и соответствовал, но IMHO, сейчас за эти деньги — полный
Хотя я ещё 6-ки не видел — может, круто...
Здравствуйте, Kaa, Вы писали:
Kaa>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>1) И вообще по поводу форматов файлов ты небось немало знаешь? Kaa>Здесь
я рассказал, где искать. Ничего нового сказать не могу. Все парсеры я писал руками (без всяких грамматик и прочего), поэтому очень подолгу. Kaa>* Structured Storage based: Kaa>** doc Kaa>** xls Kaa>** (?) планируется (пока нету) ppt Kaa>* pdf — до момента выдирания букв текста из страниц. Дальше я не продвинулся с прошлого ноября. Kaa>* chm — сперто с сайта CodeProject (кажется), но они особо не в обиде.
Kaa>С остальными понятия не имею. Тестовый парсер без мозгов для rtf делал (первая версия — за 2 дня, т.е. ничего сложного), но он сдох с моим прошлым винтом на пару, бо бэкапа нигде не было.
Есть еще способ — использовать объектную модель программ, которые умеют парсить нужные тебе форматы, получается дешево и сердито Правда скорость понижается раз в 50, но зато за неделю получешь парсеры ко всем форматам, а потом потихоньку их меняешь на свои . Главное — быстро получаешь результат
ЗХ>>2)что ты можешь сказать плохого/хорошего про семантические сети. Kaa>Я не очень знаток поисковых технологий и тесно знаком только с одной. Однако, наши лингвисты очень критически относятся к применению семантики в построении поисковых систем общего назначения. Для примера, можно почитать высказывания Ашманова на searchengines.ru по этому поводу. Они соответствуют действительности, или, по крайней мере, почти всем представлениям, которые есть у наших специалистов (опробованы на практике). Про семантические сети должен уметь рассказать Александр Митрошин: их поисковая машина использует семантику при поиске. На его скорость это судя по этому сказывается сильно и не в лучшую сторону.
Ну, насчет семантики, это сильно Пока используется только синтаксис. На скорости действительнго сказывается не лучшим образом, ибо каждое предложение надо по очереди анализировать Но тут есть свои меры повышения производительности, так что со временем есть надежда выйти на приемлимые скорости даже на очень больших объемах
Kaa>Вот, к примеру, из ветки "Поисковые движки": Kaa>
Kaa>" тут есть теоретический предел: при приближении объёмов простого текста к 10-12 Гбайт, поисковики с хранением индекса в реляционных базах перестают работать."
Ну, это зависит от того, как этот индекс в базу запихивать, если базу использовать как хранилище бинарных данных (куски индекса хранить), то все не настолько страшно. Хотя действительно, если нужна максимальная производительность, лучше от БД отказаться, ибо при переводе Б-дерева (к примеру) в таблицы неизбежны некоторые потери . Дейтсвительно, 5-10 Гб некоторый предел, но не потому, что работать не будет (работать будет), просто среднее время поиска по ключевым слова будет недопустимо большим — десятки секунд. Но для начального этапа -самое оно, ибо с базой работать проще.
Здравствуйте, Митрошин Александр, Вы писали:
МА>Есть еще способ — использовать объектную модель программ, которые умеют парсить нужные тебе форматы, получается дешево и сердито Правда скорость понижается раз в 50, но зато за неделю получешь парсеры ко всем форматам, а потом потихоньку их меняешь на свои . Главное — быстро получаешь результат
не, так я умею, но не хочу — подводит стремление к совершенству, к тому же система пишется не на заказ, а как бы "для себя", т.е. без ожидания немедленных продаваемых результатов...
МА>Ну, насчет семантики, это сильно Пока используется только синтаксис. На скорости действительнго сказывается не лучшим образом, ибо каждое предложение надо по очереди анализировать Но тут есть свои меры повышения производительности, так что со временем есть надежда выйти на приемлимые скорости даже на очень больших объемах
а все же — как насчет семантических сетей (которые, в общем-то, не имеют прямого отношения к семантике, а есть механизм организации данных)? кто-нибудь пробовал их заюзать для таких задач?
МА>Ну, это зависит от того, как этот индекс в базу запихивать, если базу использовать как хранилище бинарных данных (куски индекса хранить), то все не настолько страшно. Хотя действительно, если нужна максимальная производительность, лучше от БД отказаться, ибо при переводе Б-дерева (к примеру) в таблицы неизбежны некоторые потери . Дейтсвительно, 5-10 Гб некоторый предел, но не потому, что работать не будет (работать будет), просто среднее время поиска по ключевым слова будет недопустимо большим — десятки секунд. Но для начального этапа -самое оно, ибо с базой работать проще.
опять же. не флейма ради, а для выяснения нюансов — если не рел. БД, то что?
ЗХ>а все же — как насчет семантических сетей (которые, в общем-то, не имеют прямого отношения к семантике, а есть механизм организации данных)? кто-нибудь пробовал их заюзать для таких задач?
Насколько я знаю, сама идея семантических сетей не особенно сложна — это просто граф, где узлы — это некие слова либо другие сущности, а ребрами являются отношения между ними, которые ты хочешь учитывать. Вопрос в трудоемкости заполнения этих сетей, ибо на каждую тему нужна своя сеть. В общем, тут основная сложность именно в неоднозначности контекста, ибо одни и те же слова (и синтаксические отношения) в разных контекстах могут означать совершенно разные вещи. Так что эими вещами можно до бесконечности заниматься Важно определить, чего ты хочешь от своей системы. Может, тебе достаточно будет занести в словарь некие семантические характеристики для важных в твоей специфики тем (место, время, объект, действие и т.д) и сварганить простенькую экспертную систему, которая будет определять из вопроса, что пользователю нужно, к примеру, на вопрос "где находится машина?" ему необходимо некая сущность с характеристикой "место", связанная со словами запроса определенными отношениями, ну и так далее. Часть из нужных данных можно вытащить даже из морфологических характеристик через синтакис, а иногда даже без него, пример — кто такие депутаты, в данном случае без всякого синтаксиса можно определить, что ответом должен являться одушевленный объект.
ЗХ>опять же. не флейма ради, а для выяснения нюансов — если не рел. БД, то что?
Берешь и пишешь ручами модуль, который будет работать напрямую с файлам, то бишь записывать твой индекс в файлы, а затем осуществлять поиск по ним. Перед этим можно посмотреть, как устроен MSSQL, для общего развития , либо какой-нибудь опен-сурсный проект, типа mnogosearch
)
? 
. Руками я эти проблемы решаю. Исключительно руками. (ну в смысле, файлы, зажатые зипом, куда-то там переписываются для бакапа, при транзакциях тож самое и пр.). Общаюсь вот с умными людьми и все больше начинаю подозревать, что пора открывать собственный клуб изобретателей велосипедов 
)
Написал такую простыню, и Янус навернулся. Поэтому повторно ооочень кратко:
