Голый поисковик пользователям не очень то нужен, многие поисковые машины интегрированны в порталы (тот же Яндекс — это сначала портал, а потом поисковик).
А вот Гугл до сих пор думает иначе. Имея множество сервисов никак не хочет сделать единую точку входа. Несколько ссылок и скромное «еще» вверху как-то резко контрастирует с главными страницами
Яхи или Яндекса.
Спасибо.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
Не туда нажал и ответ пошел в общую ленту.
Спасибо.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
Чем-то сродни поиску в отдельной реляционной таблице.
Еще пример из жизни (довольно старый).
Надо было сделать выборку данных по нескольким таблицам. Работал на Paradox 4.0. У него был хороший графический интерфейс построения запросов QBE (такой графический аналог SQL, и кстати такие запросы работали порой шустрее, чем на его скриптовом языке, как-то он их там оптимизировал). В итоге склеенный многотабличный запрос после второго часа работы был убит и в течении следующего часа вся работа была сделана путем цепочки однотабличных запросов и обработки результатов где скриптами, где руками.
И я не собираюсь создавать ИНДЕКС. Мне нужна СХЕМА индекса, удовлетворяющая моим требованиям. А как ее воплотить в металле — будем смотреть по ходу, выбирая из имеющихся инструментов и глядя по сторонам, не появилось ли чего более подходящего.
Вот недавно (опять спасибо Хабру) была статья про один инструмент, одной из частей которого был функционал создания udp-тунелей. Вот лично мне эти тунели ну очень вовремя и к месту пришлись. Вот уже второй раз (как минимум) на глаза попадается информация о полезном софте именно тогда, когда она нужна.
Но если что то делать не только для саморазвития, то что нового ваш проект привнесет в мир?
Один из вариантов — еще один локальный поиск.
Года три-четыре назад в личной беседе я говорил, что поиск — это не что-то замороженное, не просто сервис, это еще и лаборатория по обкатке технологий и идей.
Одно дело — катать все это по бумаге, другое — тестировать на опытных образцах.
Например год назад я поменял схему доступа к данным. Раньше на каждый индекс поднималась отдельная точка доступа, сейчас единый шлюз. Я использовал хранение фрагментов индекса в куче небольших файлов, потом отказался от этого в пользу монолита. В итоге я не только на словах, но и на деле знаю, какие плюсы получу от каждого из данных вариантов и какой геморрой за это приобрету.
Нет единственно правильного универсального решения. Возможно я не смогу решить всех стоящих передо мной проблем, а может какую-то решу лучше других. Не ввязываясь не узнаешь.
сайт — обкатка низового уровня и базовых технологий.
Следующий этап — обкатка на нескольких сайтах коллег-друзей-знакомых.
Надеюсь к тому моменту, как упрусь в потолок имеющегося в наличии железа, будет ясно, стоит ли развиваться дальше и в каком направлении.
По хранению данных будет что послушать на РИТ++ www.ritconf.ru/news/366.html
Правда 16 тысяч как-то кусаче. но если они выложат хотя-бы презентации, уже достаточно пищи для размышлений.
Упорядоченные линейные списки. Отдельно файл данных, отдельно файл ключей. Данные могут быть переменной длины, ключи — фиксированной. Работа с ними аналогична двоичному дереву.
Еще можно рассмотреть хэш-списки, но они довольно прожорливы по памяти, надо быть осторожным.
В общем никаких классических SQL-систем.
Например когда я в течении 2-3 часов сделал и поднял индекс на линейном списке, те-же данные грузились в SQLite порядка 10 часов.
Для некоторых вещей мне понравилась BerkeleyDB. Точнее надстройка к ней memcacheDB (спасибо Хабру, где я прочитал про нее :)
Данные варианты хранения-поиска работают на нескольких индексах от гигабайта до 10-15 Гиг. Аналогичные объемы в SQL-базе займут в разы больший объем. Так что еще и диск экономим.
Да. Я представляю порядок чисел.
Но разве я сказал, что собираюсь сразу охватить весь интернет и с ходу вступать в конкуренцию с Гуглом. Ну или как минимум с Яндексом в рунете?
Мне в первую очередь нужна работающая модель. Нужна лично мне. Для моих текущих нужд.
Так что я не собираюсь сразу принимать на грудь аналогичную Яндексу и тем более Гуглу нагрузку.
Но что касается высоких нагрузок и больших объемов данных — я знаю, что это такое и имею возможность потрогать руками. Так что если дело дойдет до технической реализации — надеюсь результат будет достаточно работоспособен.
Ни в коем случае не обиделся. Наоборот, довольно лестное замечание насчет велосипедов.
Кстати советую найти несколько вело-интернет-магазинов и посмотреть, сколько сейчас красивых и разных велосипедов. Если бы люди не изобретали их, катались бы и сейчас на палке с парой колес и без педалей.
Так и в данной области. При наличии крупных систем, тем не менее живут и развиваются небольшие поисковики. И на мой взгляд они тоже нужны. Это своеобразные лаборатории по обкатке новых идей.
Ну не будете же вы экспериментировать на Гугле?
Возможно я повторю чьи-то чужие идеи. Это неизбежные издержки, поскольку в информационном плане данный сегмент закрыт. Я собираюсь свои мысли и идеи проговаривать вслух. Ни от кого не таясь.
Наверняка я в сотый раз открою америку. Ну и что?
Главная задача затеваемой писанины — облегчить жизнь себе, потому-что некоторые из задач нужны мне в настоящее время для текущей работы.
По-моему это личный блог. Если он кому-то мешает — это его личные проблемы.
Для писанины про любимую собаку, про погоду и как я провел лето у меня есть аккаунт на ЖЖ.
А тут я собираюсь хранить свои рабочие мысли и заметки. Администрация вроде не против. В главную ленту Хабра я лезть не собираюсь. Рейтинг не позволяет. Да и не нужно мне это. Не та тема, чтобы ее пихать в массы.
Ко всем, кто случайно увидел мои посты единственная просьба — не интересно — не читай.
Очевидно вопросами снабжения ведует соответствующая служба, как оно по уму и положено. А если комп поставлен на стол, подключен к сети и на него установлен стандартный офисный комплект ПО для данной организации — оно просто будет работать безо всяких заморочек. Работа службы IT в данном случае сводится к мониторингу корпоративных серверов с почтой и т.п. — тут и одного человека зватит. А два — чтобы иногда один мог сходить в отпуск, согласно КЗоТу :).
При работе в одном крупном телекоме с айтишником общался всего раз, при получении служебного ноута. И пару раз по телефону, когда понадобилось установить дополнительный софт (причем в процессе общения его и поставили, из корпоративного репозитория). А в качестве эникейщика по кампании ходил тот самый айтишник, с которым я визуально раз общался, работающий по договору.
Сказал бы кто, стоит ли ждать их ноут пробук 6440b или уже плюнуть, и поискать из имеющегося реально в продаже? Техподдержка по телефонам на hp.ru даже не знает, куда посылать с такими идиотскими вопросами.
Периодически пользуюсь аналогичной схемой. Но при первой возможности отказываюсь.
Основной минус — сильно ест диск. Если много небольших блоков данных — приличный объем съедается впустую.
Удобство — когда постоянно нужно модифицировать отдельные блоки. В одном проекте перешел на файлы, дисковые расходы терплю, пока не нашел достойной альтернативы.
В другом проекте, где несколько индексов ежедневно обновлялись целиком и по-новой разворачивались в кучу мелких файлов ушел от кучи к одному большому файлу с индексом. Сэкономил не только диск, но и время развертывания данных.
Такой список составить сложнее.
Дизайнерам надо одно, программистам — другое, причем каждому свое :)
Можно попробовать подобрать какой-то базовый, азбучный список, а далее уже в зависимости от выбранной тропинки — что и на чем делать.
Хотя смежные темы знать тоже полезно.
А вообще интересно было бы предложить Коллективному разуму заняться данной темой.
В научный раздел добавил бы «Феномен науки» В.Ф.Турчин.
Есть тут — www.refal.net/turchin/phenomenon/ и на ЛибРусЕк-е видел в djvu
«В этой книге В.Ф.Турчин излагает свою концепцию метасистемного перехода и с ее позиций прослеживает эволюцию мира от простейших одноклеточных организмов до возникновения мышления, развития науки и культуры.»
Лично мне было интересно узнать, как развивалась математика с древнейших времен. Т.е. как люди учились считать.
Сейчас урывками читаю «Атака битов...» Абельсон, Ледин, Льюис — www.books.ru/shop/books/694840
Довольно интересный взгляд на окружающие нас технологии. Книга скорее написана для не технических специалистов, но читается с интересом.
Полторы сотни — это не предел. У меня в ежедневной работе несколько таблиц от пары сотен миллионов до миллиарда записей.
Говорят у физиков-ядерщиков после экспериментов данные некуда складывать. Метеорологи уже без суперкомпьютеров не могут. А ведь раньше всю их погоду предсказывал сосед-радикулитик :)
А вот Гугл до сих пор думает иначе. Имея множество сервисов никак не хочет сделать единую точку входа. Несколько ссылок и скромное «еще» вверху как-то резко контрастирует с главными страницами
Яхи или Яндекса.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
Не туда нажал и ответ пошел в общую ленту.
Я уважаю Дмитрия Крюкова, как одного из первых (а возможно и первого российского) разработчиков системы поиска в интернете. Жаль что его уже нет. А его Черепаха — хороший образец обобщения накопленного ранее опыта.
http://bit.habrahabr.ru/blog/89483/#comments
Еще пример из жизни (довольно старый).
Надо было сделать выборку данных по нескольким таблицам. Работал на Paradox 4.0. У него был хороший графический интерфейс построения запросов QBE (такой графический аналог SQL, и кстати такие запросы работали порой шустрее, чем на его скриптовом языке, как-то он их там оптимизировал). В итоге склеенный многотабличный запрос после второго часа работы был убит и в течении следующего часа вся работа была сделана путем цепочки однотабличных запросов и обработки результатов где скриптами, где руками.
И я не собираюсь создавать ИНДЕКС. Мне нужна СХЕМА индекса, удовлетворяющая моим требованиям. А как ее воплотить в металле — будем смотреть по ходу, выбирая из имеющихся инструментов и глядя по сторонам, не появилось ли чего более подходящего.
Вот недавно (опять спасибо Хабру) была статья про один инструмент, одной из частей которого был функционал создания udp-тунелей. Вот лично мне эти тунели ну очень вовремя и к месту пришлись. Вот уже второй раз (как минимум) на глаза попадается информация о полезном софте именно тогда, когда она нужна.
Один из вариантов — еще один локальный поиск.
Года три-четыре назад в личной беседе я говорил, что поиск — это не что-то замороженное, не просто сервис, это еще и лаборатория по обкатке технологий и идей.
Одно дело — катать все это по бумаге, другое — тестировать на опытных образцах.
Например год назад я поменял схему доступа к данным. Раньше на каждый индекс поднималась отдельная точка доступа, сейчас единый шлюз. Я использовал хранение фрагментов индекса в куче небольших файлов, потом отказался от этого в пользу монолита. В итоге я не только на словах, но и на деле знаю, какие плюсы получу от каждого из данных вариантов и какой геморрой за это приобрету.
Нет единственно правильного универсального решения. Возможно я не смогу решить всех стоящих передо мной проблем, а может какую-то решу лучше других. Не ввязываясь не узнаешь.
Следующий этап — обкатка на нескольких сайтах коллег-друзей-знакомых.
Надеюсь к тому моменту, как упрусь в потолок имеющегося в наличии железа, будет ясно, стоит ли развиваться дальше и в каком направлении.
www.ritconf.ru/news/366.html
Правда 16 тысяч как-то кусаче. но если они выложат хотя-бы презентации, уже достаточно пищи для размышлений.
Еще можно рассмотреть хэш-списки, но они довольно прожорливы по памяти, надо быть осторожным.
В общем никаких классических SQL-систем.
Например когда я в течении 2-3 часов сделал и поднял индекс на линейном списке, те-же данные грузились в SQLite порядка 10 часов.
Для некоторых вещей мне понравилась BerkeleyDB. Точнее надстройка к ней memcacheDB (спасибо Хабру, где я прочитал про нее :)
Данные варианты хранения-поиска работают на нескольких индексах от гигабайта до 10-15 Гиг. Аналогичные объемы в SQL-базе займут в разы больший объем. Так что еще и диск экономим.
Но разве я сказал, что собираюсь сразу охватить весь интернет и с ходу вступать в конкуренцию с Гуглом. Ну или как минимум с Яндексом в рунете?
Мне в первую очередь нужна работающая модель. Нужна лично мне. Для моих текущих нужд.
Так что я не собираюсь сразу принимать на грудь аналогичную Яндексу и тем более Гуглу нагрузку.
Но что касается высоких нагрузок и больших объемов данных — я знаю, что это такое и имею возможность потрогать руками. Так что если дело дойдет до технической реализации — надеюсь результат будет достаточно работоспособен.
Кстати советую найти несколько вело-интернет-магазинов и посмотреть, сколько сейчас красивых и разных велосипедов. Если бы люди не изобретали их, катались бы и сейчас на палке с парой колес и без педалей.
Так и в данной области. При наличии крупных систем, тем не менее живут и развиваются небольшие поисковики. И на мой взгляд они тоже нужны. Это своеобразные лаборатории по обкатке новых идей.
Ну не будете же вы экспериментировать на Гугле?
Возможно я повторю чьи-то чужие идеи. Это неизбежные издержки, поскольку в информационном плане данный сегмент закрыт. Я собираюсь свои мысли и идеи проговаривать вслух. Ни от кого не таясь.
Наверняка я в сотый раз открою америку. Ну и что?
Главная задача затеваемой писанины — облегчить жизнь себе, потому-что некоторые из задач нужны мне в настоящее время для текущей работы.
Для писанины про любимую собаку, про погоду и как я провел лето у меня есть аккаунт на ЖЖ.
А тут я собираюсь хранить свои рабочие мысли и заметки. Администрация вроде не против. В главную ленту Хабра я лезть не собираюсь. Рейтинг не позволяет. Да и не нужно мне это. Не та тема, чтобы ее пихать в массы.
Ко всем, кто случайно увидел мои посты единственная просьба — не интересно — не читай.
При работе в одном крупном телекоме с айтишником общался всего раз, при получении служебного ноута. И пару раз по телефону, когда понадобилось установить дополнительный софт (причем в процессе общения его и поставили, из корпоративного репозитория). А в качестве эникейщика по кампании ходил тот самый айтишник, с которым я визуально раз общался, работающий по договору.
Основной минус — сильно ест диск. Если много небольших блоков данных — приличный объем съедается впустую.
Удобство — когда постоянно нужно модифицировать отдельные блоки. В одном проекте перешел на файлы, дисковые расходы терплю, пока не нашел достойной альтернативы.
В другом проекте, где несколько индексов ежедневно обновлялись целиком и по-новой разворачивались в кучу мелких файлов ушел от кучи к одному большому файлу с индексом. Сэкономил не только диск, но и время развертывания данных.
Дизайнерам надо одно, программистам — другое, причем каждому свое :)
Можно попробовать подобрать какой-то базовый, азбучный список, а далее уже в зависимости от выбранной тропинки — что и на чем делать.
Хотя смежные темы знать тоже полезно.
А вообще интересно было бы предложить Коллективному разуму заняться данной темой.
Есть тут — www.refal.net/turchin/phenomenon/ и на ЛибРусЕк-е видел в djvu
«В этой книге В.Ф.Турчин излагает свою концепцию метасистемного перехода и с ее позиций прослеживает эволюцию мира от простейших одноклеточных организмов до возникновения мышления, развития науки и культуры.»
Лично мне было интересно узнать, как развивалась математика с древнейших времен. Т.е. как люди учились считать.
Сейчас урывками читаю «Атака битов...» Абельсон, Ледин, Льюис — www.books.ru/shop/books/694840
Довольно интересный взгляд на окружающие нас технологии. Книга скорее написана для не технических специалистов, но читается с интересом.
Говорят у физиков-ядерщиков после экспериментов данные некуда складывать. Метеорологи уже без суперкомпьютеров не могут. А ведь раньше всю их погоду предсказывал сосед-радикулитик :)