У меня похожий вопрос, но он касается количетва разрешенных запросов например к гуглу с одного Ай Пи. Оно вроде ограничено 1000-ю запросов в сутки.. Как быть?
Господа, я спорить с модераторами не буду. Тем более, не считаю себя профи по БД MySQL. Спасибо, trink, разъяснил. А для желающих действительно Выжать всё возможное из MySQL, рекомендую изучить документацию и её специальный раздел: "Оптимизация в MySQL" http://www.mysql.ru/docs/man/MySQL_Optimisation.html
Как показывает практика, каждый раз, когда думаешь что выжал всё возможное, через некоторое время придумываешь алгоритм ещё лучше и быстрее. Давайте лучше делиться не результатами "у кого тормознутее", а результатами "у кого быстрее".
Ну вот могу сказать что когда меня не удовлетворяли алгоритмы баз данных(например какая нибудь хитрая многомерная сортировка), я их реализовывал сам на уровне бизнес логики с применением классических подходов теории алгоритмов :) А вообще я думаю что у нас достастаточно разные задачи что бы мерятся в скорости...
ПС И кстати мне кажется что в том случае все таки индекс мог бы существенно ускорить выполнение запроса...
А вообще мне кажется что такая ситуация возможна, если где то используются разреженные структуры данных(имею в виду при разработке БД), для которых действительно можно не знать без полного пересчета числа записей. Но приведенный пример имхо не сильно критичен...
Попытаюсь высказать свое некоторое видиние проблемы.
На мой взгляд релляционная база данных безусловно нужна!
Почему?
Потому что в поисковой системе безусловно будут и другие компоненты кроме поискового индекса. В зависимости от области применения такой системы, разной будет и сложность таких компонентов.Все реализовывать с помощью собственноручно сделанных способов долговременного хранения информации по крайней мере не разумно.А насчет накладных рассходов, то они по моим иследованиям достаточно малы(в подавляющем большинстве баз данных есть механизмы прекомпиляции запросов к выше преведенному примеру).
Какую БД выбрать? Я остановился на MySQL. Я сравнивал его и с ораклом и с постгрессом и с файрбердом. Почему? Он мне показался наиболее управляемым, простым и быстрым. В случае с ораклом, я столкнулся с ситуациями когда у меня что то где то начинало очень медленно работать, и что бы выяснить причину уходило много времени.
В конечном итоге я пришел к схеме, в которой документы, и различные их атрибуты(источник, язык) находились в базе данных, а поисковый индекс был сделан в виде инвертированного файла с использованием BerkeleyDB.
Как писал Vyacheslav Tikhonov Бесконечное количество связей между субъектом и объектом... Очень интересно узнать, как же разрешается омонимия.
Так а в чем же состоит семантическая связь? В любом поисковике, построенном на классических принципах, это уже реализовано - в стандартной td*idf-метрике. Все это лишь статистические связи.
Ну ладно. Не буду спорить о терминологии. А на счет омонимии, то я пока не ставил себе задачу бороться с этим явлением. Я иследую другие области. К тому же моя система работает с новостями, где пользователю предположительно интересны конкретные персоналии, организации и события, и погрешность от омонимии не так уж и велика, как скажем в случае работы с художественными текстами.
Вообще насколько я понимаю та функциональность над которой я работаю выходит за рамки функциональности класических поисковых серверов А что по твоему такое семантическая сеть?
Ну вот в своем проекте я видимо использовал то что вы называете семантические сети. То есть сем сеть у меня -- это граф понятий и связей между ними. Он хранится в базе данных. Строится автоматически. Простейший случай -- это статистические связи -- то есть если два слова встречаются в одном предложении то между ними существует связь, силу которой я измеряю дополнительно. В более сложном я применяю синтаксические характеристики. То есть понятием может быть именная группа. Примером связи может быть например связь между подлежащим и дополнением как между субьектом и обьектом действия в с действием в виде сказуемого. У меня для этого реализован специальный язык синтаксических правил.Дальше хочу прийти к фреймовой модели и реалзиовать фактографический поиск. То есть например пользователь вводит в поле субьекта действия слово кучма, в поле действия слово подписал в поле обьекта знак вопроса, и получает новости в которых кучма что то подписал за определенный период. Думаю такое реализовать вполне возможно.
У меня похожий вопрос, но он касается количетва разрешенных запросов например к гуглу с одного Ай Пи. Оно вроде ограничено 1000-ю запросов в сутки.. Как быть?
Господа, я спорить с модераторами не буду. Тем более, не считаю себя профи по БД MySQL. Спасибо, trink, разъяснил. А для желающих действительно Выжать всё возможное из MySQL, рекомендую изучить документацию и её специальный раздел: "Оптимизация в MySQL" http://www.mysql.ru/docs/man/MySQL_Optimisation.html
Как показывает практика, каждый раз, когда думаешь что выжал всё возможное, через некоторое время придумываешь алгоритм ещё лучше и быстрее. Давайте лучше делиться не результатами "у кого тормознутее", а результатами "у кого быстрее".
Ну вот могу сказать что когда меня не удовлетворяли алгоритмы баз данных(например какая нибудь хитрая многомерная сортировка), я их реализовывал сам на уровне бизнес логики с применением классических подходов теории алгоритмов :) А вообще я думаю что у нас достастаточно разные задачи что бы мерятся в скорости...
ПС И кстати мне кажется что в том случае все таки индекс мог бы существенно ускорить выполнение запроса...
В таком запросе индексы некуда прикладывать. :)
Извиняюсь наверное неправильно понял ваше сообщение...
А вообще мне кажется что такая ситуация возможна, если где то используются разреженные структуры данных(имею в виду при разработке БД), для которых действительно можно не знать без полного пересчета числа записей. Но приведенный пример имхо не сильно критичен...
Максим, вообще-то при обработке запросов с функциями вроде count, avg, sum индексы никак не используются. ;)
Да ну, в запросе:
select count(*) from tablename where id > 134277; очень даже используются.
Попытаюсь высказать свое некоторое видиние проблемы.
На мой взгляд релляционная база данных безусловно нужна!
Почему?
Потому что в поисковой системе безусловно будут и другие компоненты кроме поискового индекса. В зависимости от области применения такой системы, разной будет и сложность таких компонентов.Все реализовывать с помощью собственноручно сделанных способов долговременного хранения информации по крайней мере не разумно.А насчет накладных рассходов, то они по моим иследованиям достаточно малы(в подавляющем большинстве баз данных есть механизмы прекомпиляции запросов к выше преведенному примеру).
Какую БД выбрать? Я остановился на MySQL. Я сравнивал его и с ораклом и с постгрессом и с файрбердом. Почему? Он мне показался наиболее управляемым, простым и быстрым. В случае с ораклом, я столкнулся с ситуациями когда у меня что то где то начинало очень медленно работать, и что бы выяснить причину уходило много времени.
В конечном итоге я пришел к схеме, в которой документы, и различные их атрибуты(источник, язык) находились в базе данных, а поисковый индекс был сделан в виде инвертированного файла с использованием BerkeleyDB.
Имелось ввиду, что в результате качественной реализации связи вроде "вождение" -> "серпуховский район" могут быть отфильтрованы как незначительные.
это Вы о чем?
О твоем последним на тот момент посте.
Ну эти погрешности могут варьироваться от реализации к реализации. Не секрет что есть хорошие продукты а есть плохие.
Бесконечное количество связей между субъектом и объектом... Очень интересно узнать, как же разрешается омонимия.
Так а в чем же состоит семантическая связь? В любом поисковике, построенном на классических принципах, это уже реализовано - в стандартной td*idf-метрике. Все это лишь статистические связи.
Ну ладно. Не буду спорить о терминологии. А на счет омонимии, то я пока не ставил себе задачу бороться с этим явлением. Я иследую другие области. К тому же моя система работает с новостями, где пользователю предположительно интересны конкретные персоналии, организации и события, и погрешность от омонимии не так уж и велика, как скажем в случае работы с художественными текстами.
Вообще насколько я понимаю та функциональность над которой я работаю выходит за рамки функциональности класических поисковых серверов А что по твоему такое семантическая сеть?
Ну вот в своем проекте я видимо использовал то что вы называете семантические сети. То есть сем сеть у меня -- это граф понятий и связей между ними. Он хранится в базе данных. Строится автоматически. Простейший случай -- это статистические связи -- то есть если два слова встречаются в одном предложении то между ними существует связь, силу которой я измеряю дополнительно. В более сложном я применяю синтаксические характеристики. То есть понятием может быть именная группа. Примером связи может быть например связь между подлежащим и дополнением как между субьектом и обьектом действия в с действием в виде сказуемого. У меня для этого реализован специальный язык синтаксических правил.Дальше хочу прийти к фреймовой модели и реалзиовать фактографический поиск. То есть например пользователь вводит в поле субьекта действия слово кучма, в поле действия слово подписал в поле обьекта знак вопроса, и получает новости в которых кучма что то подписал за определенный период. Думаю такое реализовать вполне возможно.