Давайте рассуждать о вкусе устриц, предварительно их попробовав. Вот Вы лично разработали хоть один вебпроект на С++? Если да, то какими технологиями пользовались? Если нет, на основании чего Вы допускаете столь смелое утверждение?
C++ (как и вообще любой язык) очень плохо подходит для разработки чего-либо вообще.
Для разработки всегда используется тот или иной фреймворк. Это могут быть модули PERL, PHP-extensions + PEAR или что-либо другое.
Очевидно ведь, что та же Java, не будь для нее разработаны сервера приложений, очень плохо подходила бы для Web-разработок.
Поэтому весь вопрос, собственно, в том, есть ли подходящие фреймворки для того или иного языка. Для С++ они есть.
В сущности, интерпретируемые языки - не что иное как прослойка между вебсервером и низкоуровневыми библиотеками, тот же "P" в LAMP - не более чем описатель логики взаимодействия "A" с "M" на платформе "L". Примеров описателей бизнес-логики очень много: Java, Python, PHP, PERL, TCL, CL, С++ и т.д. Критерий интерпретации, как видим, здесь не главный.
Касаемо разработки больших проектов, то вообще сам вопрос о компиляции/интерпретации не принципиален - ведь все равно никто на рабочих серверах правки кода в консоле не делает. Есть определенный порядок выкатки кода, тестирования и сдачи проекта в эксплуатацию. И процесс непосредственно разработки занимает не самый большой процент времени.
Гораздо важнее - соответствие выдвигаемым бизнес-требованиям. Если проект им соответствует, совершенно не важно, на чем он написан.
Лично меня "плюсы" и "минусы" не волнуют совершенно. Словесным недержанием в блогах я не страдаю и от факта забанивания или падения рейтинга меня не коробит ничуть.
Могу лишь добавить, что слив любой информации (а тем более - откровенного вранья (см. ответ http://habrahabr.ru/blog/rumor_has_it/35440.html#comment645628 ) является показателем отношения к коллективу и работодателю.
Как следствие, даже если бы мне был *очень* нужен программист PERL, кандидатура устроившего слив perl-разработчика из СУПа, "крутого и высокооплачиваемого" не рассматривалась бы вовсе, ибо он - мудак.
Здесь важен не принцип "всё или ничего", а принцип Оккама, а именно: "не следует плодить одинаковые сущности". На мой взгляд, подобный "поиск", при наличии аналогов в MySQL/PostgreSQL/MSSQL - сущность лишняя.
Хорошо бы сделать то, чего нет в существующих свободных поисковых системах, например, поиск по кворуму (http://company.yandex.ru/articles/romip2004.xml), правильное ранжирование документа и т.п.
Поверьте, в рамках одного сайта все это не так уж и сложно.
Ну, начнем с того, что задача Яндексом решена, а именно - выбран некий лучший на их взгляд результат, а во-вторых, кроме Яндекса есть и другие системы коррекции опечаток, например
http://go.mail.ru/search?lfilter=y&q=%E2%EA%EB%FE%F7%E5%ED%EE%EE+%F1%E2%E5%F9%E5%ED%E8%E5
Неправильно. "aффтар" нельзя менять ни на "автор", а на "авто". Ответ на вопрос "почему" есть на блоге разработчиков Яндекса; там эта проблема описана исчерпывающе и пересказывать своими словами я не вижу смысла.
В догонку.
"свещение"
Какой _наиболее_ правильный ответ?
"сведение"? "свечение", "освещение"?
"свещание"
Какой правильный ответ?
"совещание"? "вещание"?
Подобных слов очень и очень много; "почти" правильных вариантов - еще больше, и сама по себе функция soundex ничего определенного о лучшем варианте сказать не может.
Функция только высчитывает похожесть, корреляцию двух слов. Но то, что два слова похожи, не говорит о том, что одно слово является следствием ошибки, допущенной во втором.
Тем более это важно, когда рассматривается не одно слово, а несколько слов с пропущенными или вставленными пробелами. Опечаткой какого рода является выражение "включеноо свещение"?
"включено освещение" или "включено свечение"/"включено сведение"? Функцией soundex это, увы, не решается.
Ну а если так, то во-первых, стоило бы заменить претнциозное название "Яндекс-like поиск своими руками" на что-то более подходящее по смыслу, а во-вторых, подобный "наивный" поиск давно реализован в проектах типа Sphinx, Lucene и т.п.
Касаемо именно "небольшого сайта", то я не вижу смысла городить подобные вещи, когда есть поиск, встроенный в MySQL, PostgreSQL и т.д.
По мне - так это отлично, что Вы занялись изучением тематики поисковых систем, но современный поиск, даже по своему сайту - система, достаточно сложная как алгоритмически, так и ресурсно.
P.S. Если мне не изменяет память, то нечто подобное было сделано для форума PHPbb. И очень сильно тормозило при вставках текста.
Это - так называемый "псевдопоиск".
К Яндексу или другим действительно полнотекстовым поисковым системам не имеет никакого отношения.
Сам по себе факт наличия слов в документе не отражает полезности документа как результата поиска. Пример: мы ищем документы, в которых говорится о матче между Динамо и Спартаком. Логично задать запрос "матч Динамо - Спартак".
Если мы ищем этим алгоритмом документы со вхождениями слов "матч", "Динамо" и "Спартак", то релевантность документа "на матче Динамо-Спартак окончательный счет 3:0" будет такая же как у документа "Спартак приобрел игрока, ранее игравшего матчи за Динамо".
Поэтому, для релевантной выдачи результатов поиска, недостаточно просто выяснить частоту вхождения слов документ. Важно знать их расположение друг относительно друга, положение внутри документа, их словоформу и т.д.
Касаемо поиска опечаток, то функция soundex не подходит вовсе. Почему? Потому, что ей не решаются основные задачи по поиску опечаток. Я приведу их вкратце:
- орфографические ошибки ("посвищение" -> "посвящение")
- опечатки набора слова ("констптуция" -> "конституция")
- пропуск буквы в слове ("гастрном" -> "гастроном")
- вставка лишней буквы в слово ("моллоко" -> "молоко")
- перестановка букв в слове ("разарботка" -> "разработка")
- пропуск пробела между словами ("масломашинное" -> "масло машинное")
- вставка лишнего пробела в слово ("пров еренный" -> "проверенный")
- неправильная кодировка ("БНОПНЯ" -> "вопрос")
- неправильная раскладка клавиатуры ("ghjdthrf" -> "проверка")
- ввод URL или названия домена в строку поиска ("mail.ru" -> http://mail.ru)
Кроме этого, есть дополнительные трудности в правильном определении опечаток, а именно -
цельные слова, которые можно представить как выражения с пропусками пробелов:
"отмелькала", "эпоха ельцинизма" и т.п.
Еще один важный момент - это учет несловарных слов, жаргонизмов и арго.
Касаемо стеммеров. Стеммеры - это очень и очень плохо. Сейчас в свободном доступе есть библиотеки с работающей морфологией русского, английского и других языков.
Поэтому вывод простой: то, что автор заинтересовался подобной темой - это очень и очень хорошо. Но для написания действительно нормального поиска нужны знания и большой труд, причем труд, гораздо бОльший чем то, что описано в статье.
За время бета-тестирования на базе Ning созданы более 30 000 социальных приложений. Трафик превысил 20 млн показов страниц в месяц, а количество уникальных посетителей достигло 5 млн в месяц.
Стартап Ning, основанный два года назад, финансируется лично Марком Андрессеном, который вложил в дело уже более $9 млн. Штат компании за два года вырос до 27 человек.
-------------
20 миллионов хитов в _месяц_; 9 миллионов баксов затрат.
Все изобретено еще в прошлом веке.
В Гугле полно материалов по теме «Дифракция электронов». Для детей, конечно, все упрощено до невозможности.
Давайте рассуждать о вкусе устриц, предварительно их попробовав. Вот Вы лично разработали хоть один вебпроект на С++? Если да, то какими технологиями пользовались? Если нет, на основании чего Вы допускаете столь смелое утверждение?
C++ (как и вообще любой язык) очень плохо подходит для разработки чего-либо вообще.
Для разработки всегда используется тот или иной фреймворк. Это могут быть модули PERL, PHP-extensions + PEAR или что-либо другое.
Очевидно ведь, что та же Java, не будь для нее разработаны сервера приложений, очень плохо подходила бы для Web-разработок.
Поэтому весь вопрос, собственно, в том, есть ли подходящие фреймворки для того или иного языка. Для С++ они есть.
В сущности, интерпретируемые языки - не что иное как прослойка между вебсервером и низкоуровневыми библиотеками, тот же "P" в LAMP - не более чем описатель логики взаимодействия "A" с "M" на платформе "L". Примеров описателей бизнес-логики очень много: Java, Python, PHP, PERL, TCL, CL, С++ и т.д. Критерий интерпретации, как видим, здесь не главный.
Касаемо разработки больших проектов, то вообще сам вопрос о компиляции/интерпретации не принципиален - ведь все равно никто на рабочих серверах правки кода в консоле не делает. Есть определенный порядок выкатки кода, тестирования и сдачи проекта в эксплуатацию. И процесс непосредственно разработки занимает не самый большой процент времени.
Гораздо важнее - соответствие выдвигаемым бизнес-требованиям. Если проект им соответствует, совершенно не важно, на чем он написан.
Могу лишь добавить, что слив любой информации (а тем более - откровенного вранья (см. ответ http://habrahabr.ru/blog/rumor_has_it/35440.html#comment645628 ) является показателем отношения к коллективу и работодателю.
Как следствие, даже если бы мне был *очень* нужен программист PERL, кандидатура устроившего слив perl-разработчика из СУПа, "крутого и высокооплачиваемого" не рассматривалась бы вовсе, ибо он - мудак.
Всем спасибо.
Проверьте, если не верится.
Касаемо LIKE %text%, то комментировать здесь нечего: для поиска в массивах текста, LIKE бесполезен.
Хорошо бы сделать то, чего нет в существующих свободных поисковых системах, например, поиск по кворуму (http://company.yandex.ru/articles/romip2004.xml), правильное ранжирование документа и т.п.
Поверьте, в рамках одного сайта все это не так уж и сложно.
Вопросы того, почему в вебпрограммисты большинства сайтов идут все те, кто не сумел найти более приличную работу, мы ведь не обсуждаем, не так ли?
http://go.mail.ru/search?lfilter=y&q=%E2%EA%EB%FE%F7%E5%ED%EE%EE+%F1%E2%E5%F9%E5%ED%E8%E5
В догонку.
"свещение"
Какой _наиболее_ правильный ответ?
"сведение"? "свечение", "освещение"?
"свещание"
Какой правильный ответ?
"совещание"? "вещание"?
Подобных слов очень и очень много; "почти" правильных вариантов - еще больше, и сама по себе функция soundex ничего определенного о лучшем варианте сказать не может.
Функция только высчитывает похожесть, корреляцию двух слов. Но то, что два слова похожи, не говорит о том, что одно слово является следствием ошибки, допущенной во втором.
Тем более это важно, когда рассматривается не одно слово, а несколько слов с пропущенными или вставленными пробелами. Опечаткой какого рода является выражение "включеноо свещение"?
"включено освещение" или "включено свечение"/"включено сведение"? Функцией soundex это, увы, не решается.
Что делать со словами типа "аффтар"?
Касаемо именно "небольшого сайта", то я не вижу смысла городить подобные вещи, когда есть поиск, встроенный в MySQL, PostgreSQL и т.д.
По мне - так это отлично, что Вы занялись изучением тематики поисковых систем, но современный поиск, даже по своему сайту - система, достаточно сложная как алгоритмически, так и ресурсно.
P.S. Если мне не изменяет память, то нечто подобное было сделано для форума PHPbb. И очень сильно тормозило при вставках текста.
К Яндексу или другим действительно полнотекстовым поисковым системам не имеет никакого отношения.
Сам по себе факт наличия слов в документе не отражает полезности документа как результата поиска. Пример: мы ищем документы, в которых говорится о матче между Динамо и Спартаком. Логично задать запрос "матч Динамо - Спартак".
Если мы ищем этим алгоритмом документы со вхождениями слов "матч", "Динамо" и "Спартак", то релевантность документа "на матче Динамо-Спартак окончательный счет 3:0" будет такая же как у документа "Спартак приобрел игрока, ранее игравшего матчи за Динамо".
Поэтому, для релевантной выдачи результатов поиска, недостаточно просто выяснить частоту вхождения слов документ. Важно знать их расположение друг относительно друга, положение внутри документа, их словоформу и т.д.
Касаемо поиска опечаток, то функция soundex не подходит вовсе. Почему? Потому, что ей не решаются основные задачи по поиску опечаток. Я приведу их вкратце:
- орфографические ошибки ("посвищение" -> "посвящение")
- опечатки набора слова ("констптуция" -> "конституция")
- пропуск буквы в слове ("гастрном" -> "гастроном")
- вставка лишней буквы в слово ("моллоко" -> "молоко")
- перестановка букв в слове ("разарботка" -> "разработка")
- пропуск пробела между словами ("масломашинное" -> "масло машинное")
- вставка лишнего пробела в слово ("пров еренный" -> "проверенный")
- неправильная кодировка ("БНОПНЯ" -> "вопрос")
- неправильная раскладка клавиатуры ("ghjdthrf" -> "проверка")
- ввод URL или названия домена в строку поиска ("mail.ru" -> http://mail.ru)
Кроме этого, есть дополнительные трудности в правильном определении опечаток, а именно -
цельные слова, которые можно представить как выражения с пропусками пробелов:
"отмелькала", "эпоха ельцинизма" и т.п.
Еще один важный момент - это учет несловарных слов, жаргонизмов и арго.
Касаемо стеммеров. Стеммеры - это очень и очень плохо. Сейчас в свободном доступе есть библиотеки с работающей морфологией русского, английского и других языков.
Поэтому вывод простой: то, что автор заинтересовался подобной темой - это очень и очень хорошо. Но для написания действительно нормального поиска нужны знания и большой труд, причем труд, гораздо бОльший чем то, что описано в статье.
Стартап Ning, основанный два года назад, финансируется лично Марком Андрессеном, который вложил в дело уже более $9 млн. Штат компании за два года вырос до 27 человек.
-------------
20 миллионов хитов в _месяц_; 9 миллионов баксов затрат.
Что-то дорогой какой-то проектец получается.