Комментарии 24
Не могли бы сказать, какую систему хранения данных вы собираетесь использовать&
0
Просто я сейчас занимаюсь чем-то подобным, и ищу платформу. Рассматриваю варианты MongoDB, какую-нибудь SQL БД в связке с Sphinx, или еще вот наткнулся на Apache Cassandra.
0
По хранению данных будет что послушать на РИТ++
www.ritconf.ru/news/366.html
Правда 16 тысяч как-то кусаче. но если они выложат хотя-бы презентации, уже достаточно пищи для размышлений.
www.ritconf.ru/news/366.html
Правда 16 тысяч как-то кусаче. но если они выложат хотя-бы презентации, уже достаточно пищи для размышлений.
0
Упорядоченные линейные списки. Отдельно файл данных, отдельно файл ключей. Данные могут быть переменной длины, ключи — фиксированной. Работа с ними аналогична двоичному дереву.
Еще можно рассмотреть хэш-списки, но они довольно прожорливы по памяти, надо быть осторожным.
В общем никаких классических SQL-систем.
Например когда я в течении 2-3 часов сделал и поднял индекс на линейном списке, те-же данные грузились в SQLite порядка 10 часов.
Для некоторых вещей мне понравилась BerkeleyDB. Точнее надстройка к ней memcacheDB (спасибо Хабру, где я прочитал про нее :)
Данные варианты хранения-поиска работают на нескольких индексах от гигабайта до 10-15 Гиг. Аналогичные объемы в SQL-базе займут в разы больший объем. Так что еще и диск экономим.
Еще можно рассмотреть хэш-списки, но они довольно прожорливы по памяти, надо быть осторожным.
В общем никаких классических SQL-систем.
Например когда я в течении 2-3 часов сделал и поднял индекс на линейном списке, те-же данные грузились в SQLite порядка 10 часов.
Для некоторых вещей мне понравилась BerkeleyDB. Точнее надстройка к ней memcacheDB (спасибо Хабру, где я прочитал про нее :)
Данные варианты хранения-поиска работают на нескольких индексах от гигабайта до 10-15 Гиг. Аналогичные объемы в SQL-базе займут в разы больший объем. Так что еще и диск экономим.
0
Я так понимаю, исходя их того что вы сами хотите создавать индекс, вы сами хотите написать систему поиска?
Честно говоря я слабо представляю поиск в key-value базе данных
Честно говоря я слабо представляю поиск в key-value базе данных
0
Чем-то сродни поиску в отдельной реляционной таблице.
Еще пример из жизни (довольно старый).
Надо было сделать выборку данных по нескольким таблицам. Работал на Paradox 4.0. У него был хороший графический интерфейс построения запросов QBE (такой графический аналог SQL, и кстати такие запросы работали порой шустрее, чем на его скриптовом языке, как-то он их там оптимизировал). В итоге склеенный многотабличный запрос после второго часа работы был убит и в течении следующего часа вся работа была сделана путем цепочки однотабличных запросов и обработки результатов где скриптами, где руками.
И я не собираюсь создавать ИНДЕКС. Мне нужна СХЕМА индекса, удовлетворяющая моим требованиям. А как ее воплотить в металле — будем смотреть по ходу, выбирая из имеющихся инструментов и глядя по сторонам, не появилось ли чего более подходящего.
Вот недавно (опять спасибо Хабру) была статья про один инструмент, одной из частей которого был функционал создания udp-тунелей. Вот лично мне эти тунели ну очень вовремя и к месту пришлись. Вот уже второй раз (как минимум) на глаза попадается информация о полезном софте именно тогда, когда она нужна.
Еще пример из жизни (довольно старый).
Надо было сделать выборку данных по нескольким таблицам. Работал на Paradox 4.0. У него был хороший графический интерфейс построения запросов QBE (такой графический аналог SQL, и кстати такие запросы работали порой шустрее, чем на его скриптовом языке, как-то он их там оптимизировал). В итоге склеенный многотабличный запрос после второго часа работы был убит и в течении следующего часа вся работа была сделана путем цепочки однотабличных запросов и обработки результатов где скриптами, где руками.
И я не собираюсь создавать ИНДЕКС. Мне нужна СХЕМА индекса, удовлетворяющая моим требованиям. А как ее воплотить в металле — будем смотреть по ходу, выбирая из имеющихся инструментов и глядя по сторонам, не появилось ли чего более подходящего.
Вот недавно (опять спасибо Хабру) была статья про один инструмент, одной из частей которого был функционал создания udp-тунелей. Вот лично мне эти тунели ну очень вовремя и к месту пришлись. Вот уже второй раз (как минимум) на глаза попадается информация о полезном софте именно тогда, когда она нужна.
0
А что-нибудь более масштабно, как делать планируете есть?
А то как-бы юзать как единицу сайт, и так понятно
А то как-бы юзать как единицу сайт, и так понятно
0
1. Возможность предоставления сервиса поиска отдельным сайтам. У крупных поисковиков есть ограничение поиска отдельным сайтом, но почему-то сами сайты этим не пользуются, предпочитая ставить локальные поисковики. По крайней мере данный рынок (локальных поисковиков) существует и этим можно пользоваться к взаимной выгоде — площадки для тестирования и обкатки функционала.
Обычно создатели — заказчики сайтов хотят какой нибуть сложный поиск. Либо если поиск простейший разработчик не предлагает такой возможности как поиск средствами поисковиков, а заказчик о такой возможности не знает.
Изобретение велосипедов это не плохой вариант для саморазвития. Но если что то делать не только для саморазвития, то что нового ваш проект привнесет в мир?
0
Но если что то делать не только для саморазвития, то что нового ваш проект привнесет в мир?
Один из вариантов — еще один локальный поиск.
Года три-четыре назад в личной беседе я говорил, что поиск — это не что-то замороженное, не просто сервис, это еще и лаборатория по обкатке технологий и идей.
Одно дело — катать все это по бумаге, другое — тестировать на опытных образцах.
Например год назад я поменял схему доступа к данным. Раньше на каждый индекс поднималась отдельная точка доступа, сейчас единый шлюз. Я использовал хранение фрагментов индекса в куче небольших файлов, потом отказался от этого в пользу монолита. В итоге я не только на словах, но и на деле знаю, какие плюсы получу от каждого из данных вариантов и какой геморрой за это приобрету.
Нет единственно правильного универсального решения. Возможно я не смогу решить всех стоящих передо мной проблем, а может какую-то решу лучше других. Не ввязываясь не узнаешь.
0
Может быть, вот эта ссылочка Вам чем-нибудь поможет: http://www.turtle.ru/db/architecture/turtle.html. Удачи!
0
Интернет делится на сайты, сайты на разделы. Чтоб можно было как весь сайт блокировать так и частично, так же по разделам хорошо ранжировать информацию на сайте. Словарь словоформ можно взять от OpenOffice. БД в идеале лучше использовать PostgreSQL (из свободных) — позволяет масштабировать БД по разным серверам средствами PostgreSQL. Язык программирования желательно компилирующий. Правила построения предложений описаны в учебнике по Русскому языку, семантика с лов в словаре например: толковый словарь русского языка Ушакова. Парсер сайтов написать несложно, главное не забывать про sitemap.xml и robot.txt. Алгоритм работы простого поисковика описан в книге — Программируем коллективный разум. Дальше читаем статьи на тему — 130 параметров алгоритма ранжирования сайтов от Google и подобные.
Голый поисковик пользователям не очень то нужен, многие поисковые машины интегрированны в порталы (тот же Яндекс — это сначала портал, а потом поисковик).
Голый поисковик пользователям не очень то нужен, многие поисковые машины интегрированны в порталы (тот же Яндекс — это сначала портал, а потом поисковик).
0
Голый поисковик пользователям не очень то нужен, многие поисковые машины интегрированны в порталы (тот же Яндекс — это сначала портал, а потом поисковик).
А вот Гугл до сих пор думает иначе. Имея множество сервисов никак не хочет сделать единую точку входа. Несколько ссылок и скромное «еще» вверху как-то резко контрастирует с главными страницами
Яхи или Яндекса.
0
Хорошая вещь, когда туда зайдешь и будешь пользоваться.
Вот только простой человек, попадающий на страницу Гугла видит перед собой поиск, ну и что-то еще боковым зрением. Попадающий на Яху или Яндекс видит много всего, ну еще и поиск плюс ко всему. Вопрос расстановки акцентов. В первом случае жестко на поиск, во втором — на многообразие сервисов.
Возможно на результат людских предпочтений влияет менталитет или какие другие ньюансы, но если в Штатах более поздний простой Гугл обошел порталообразную Яху, то в России порталообразный Яндекс не сдается так легко аскету Гуглу.
Вот только простой человек, попадающий на страницу Гугла видит перед собой поиск, ну и что-то еще боковым зрением. Попадающий на Яху или Яндекс видит много всего, ну еще и поиск плюс ко всему. Вопрос расстановки акцентов. В первом случае жестко на поиск, во втором — на многообразие сервисов.
Возможно на результат людских предпочтений влияет менталитет или какие другие ньюансы, но если в Штатах более поздний простой Гугл обошел порталообразную Яху, то в России порталообразный Яндекс не сдается так легко аскету Гуглу.
0
Спасибо.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
0
Очень рекомендую книгу: nlp.stanford.edu/IR-book/information-retrieval-book.html
0
Из собственного опыта (был свой поисковик):
— У нас атомом поисковой информации было слово-на-странице.
— Данных _очень_ много, мы их ужали. Например, слова превратились в идентификаторы слов. Размер индекса сайта чисто физически ни при каких обстоятельствах не должен превышать вычислительную мощность одного сервера.
— Поиск у нас по большей части происходил на этапе сбора информации (роботом), во время выполнения запроса делалось минимальное количество работа.
— Всё работало на MySQL — мы во многих местах упирались в его ограничения и ошибки, но жить вполне можно. За то не пришлось писать свою СУБД, а это реально дорого иногда.
— Важным моментом в развитии качества поиска является отслеживание свойств страниц, максимально определяющих вероятность клика юзера на результат поиска. Это такая обратная связь для технологий поиска.
— У нас атомом поисковой информации было слово-на-странице.
— Данных _очень_ много, мы их ужали. Например, слова превратились в идентификаторы слов. Размер индекса сайта чисто физически ни при каких обстоятельствах не должен превышать вычислительную мощность одного сервера.
— Поиск у нас по большей части происходил на этапе сбора информации (роботом), во время выполнения запроса делалось минимальное количество работа.
— Всё работало на MySQL — мы во многих местах упирались в его ограничения и ошибки, но жить вполне можно. За то не пришлось писать свою СУБД, а это реально дорого иногда.
— Важным моментом в развитии качества поиска является отслеживание свойств страниц, максимально определяющих вероятность клика юзера на результат поиска. Это такая обратная связь для технологий поиска.
0
Есть некоторые наработки по выборке данных из больших массивов. СУБД сразу не рассматривалась по причине больших объемов (до пары сотен гиг в настоящее время).
В основе лежат упорядоченные списки с ключевым файлом. Структура довольно простая и неплохо работает.
Замена слов (и ссылок на страницы тоже) на числовые идентификаторы не только сокращает объем индекса, но и позволяет использовать записи фиксированной длины, что удобней и быстрее.
Основная работа делается на этапе обработки информации — для ускорения процесса приходится поддерживать приличную избыточность. Но оно себя окупает.
Главное ограничение — наращиваемость функционала. Что забил в структуру, с тем и живи. Желание добавить бантик как правило влечет за собой поход по всей цепочке обработки. Поэтому десять раз подумаешь, прежде чем за что-то браться.
В основе лежат упорядоченные списки с ключевым файлом. Структура довольно простая и неплохо работает.
Замена слов (и ссылок на страницы тоже) на числовые идентификаторы не только сокращает объем индекса, но и позволяет использовать записи фиксированной длины, что удобней и быстрее.
Основная работа делается на этапе обработки информации — для ускорения процесса приходится поддерживать приличную избыточность. Но оно себя окупает.
Главное ограничение — наращиваемость функционала. Что забил в структуру, с тем и живи. Желание добавить бантик как правило влечет за собой поход по всей цепочке обработки. Поэтому десять раз подумаешь, прежде чем за что-то браться.
0
У нас стогигабайтные индексы жили в БД и ничё =)
0
Да я и не спорю, что они могут там жить. Сам пользовался такими базами (держали трафик крупного телекома за несколько месяцев). Спору нет, это удобно, когда нужен нестандартный запрос и есть время подождать. Но когда от трети до половины такого индекса требует ежедневного обновления — нужны приличные ресурсы. Плюс тысячи однотипных запросов в сутки с требованием по времен ожидания не превышающем секунды (для одного запроса).
Я не являюсь ярым противником универсальных СУБД. Где можно — пользуюсь ими. Это позволяет ускорить разработку и сделать данную часть продукта более универсальной. Но когда с ростом нагрузок приходится выбирать — я выбираю в пользу специализированных, узко заточенных решений.
Я не являюсь ярым противником универсальных СУБД. Где можно — пользуюсь ими. Это позволяет ускорить разработку и сделать данную часть продукта более универсальной. Но когда с ростом нагрузок приходится выбирать — я выбираю в пользу специализированных, узко заточенных решений.
0
Ну так у нас такая база отрабатывала по несколько десятков поисковых запросов в секунду почти не напрягаясь.
Это я к тому, что оверхед от базы небольшой, ибо вообще-то она как раз и заточена под очень быстрые выборки на больших объёмах данных. Другое дело, что бывают нужны ОЧЕНЬ быстрые выборки на ОЧЕНЬ больших объёмах данных, но здесь больше спасает партицирование и масштабирование, чем замена БД на самописное key-value хранилище.
Это я к тому, что оверхед от базы небольшой, ибо вообще-то она как раз и заточена под очень быстрые выборки на больших объёмах данных. Другое дело, что бывают нужны ОЧЕНЬ быстрые выборки на ОЧЕНЬ больших объёмах данных, но здесь больше спасает партицирование и масштабирование, чем замена БД на самописное key-value хранилище.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
Пишу поисковик (virtual project). Ч.1. Первые кирпичи