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