Вот только объем информации, которая на него поместится, будет на порядок/порядки меньше, чем на обычную флэшку. Да и доступ к бумаге — более хлопотный процесс.
Т.е. теперь китайцы могут ставить Андроид на свои поделки вполне легально :)
Гугл хорошо умеет монетизировать сопутствующие сервисы и с таким решением по Андроиду они фактически вернулись к своей любимой модели.
90 тысяч приложений в маркете будет или 300 тыс. — лично для меня не важно, всеравно все просмотреть не смогу :) А то, что лично мне необходимо для работы и удовольствия — присутствует.
Наверное в сфере потребительства надо вводить другой критерий качества. Не качество, как синоним хорошо сделанной вещи, где все красиво и радует глаз и душу. А качество, как максимальную вписанность продукта в потребности целевой аудитории. В этом ключе китайско-въетнамский ширпотреб — именно качественный продукт, поскольку он лучше всех (судя по голосованию кошельками) удовлетворяет потребности масс — дешево и сердито.
Для меня основной критерий — удовлетворяет ли меня результат работы этого кода. Если в основном удовлетворяет, значит хороший.
Ну а когда лезу в дебри этого кода, смотрю, как бы это сделал я. Если удается сделать более эффективный код, значит исходный не очень удачен, а если «вау! я бы до этого не додумался!» — значит в данном вопросе автор сильнее меня и у него не стыдно поучиться. Изучение чужого опыта и чужих ошибок — более быстрый способ роста, чем набивать на том-же месте свои шишки :) Шрамы, даже виртуальные, украшают мужчину, когда их количество разумно. Когда их слишком много — получается уродство.
Ну насчет «Владыки Кода» — это не всегда так. Если код открытый и тебе понятен смысл его работы — ты просто используешь его и для этого уже не нужен автор. Если нужно доработать этот код — опять-же при открытости и понятности — не вижу особых проблем.
А к данной статье я бы еще добавил пожелание периодически копаться в чужих текстах программ. Тоже в плане самообразования. Грамотно написанный код может быть неплохим учебным пособием и источником новых приемов программирования…
Ну а разбирая плохой код (если нужда заставила) учишься, как не надо делать :)
Я за разработку собственных колес.
Но в жизни бывают разные ситуации. Иногда пишу свое, хотя что-то уже есть, иногда использую готовые решения. В каждом случае решаю из ситуации. Иногда работа стороннего продукта меня не устраивает по каким-то причинам (как правило — большая ресурсоемкость, медленная скорость работы), тогда пытаюсь найти свое решение. Иногда не заморачиваюсь и беру готовое — когда нужно быстро получить и оценить результат или самостоятельно ваять слишком долго и дорого. В процессе жизни кода, бывает, переделываю отдельные участки, когда с ростом нагрузок становятся более заметны узкие места или просто вижу способ улучшить результат.
В общем правда, как обычно, где-то посередине. Но в любом случае, понимание, как работает используемая вами сторонняя программа позволяет добиться лучших результатов. Иногда для этого совсем не обязательно параллельно писать свое. Достаточно хорошенько подумать, как это может крутиться внутри.
Гугл, как и Яндекс, не раскрывает реальных структур хранения данных. Весьма поверхностно в одной статье описывается общая структура их инверсного индекса, да еще то, какой монстр — их распределенная файловая система.
Все подробности — думаю они охраняются не хуже гостайн.
Кстати я слышал, что Яндекс еще и Berkeley DB использует.
Я видел, как разные люди одинаковым молотком пользуются — один бил по пальцам, а другой двумя ударами вгонял трехдюймовый гвоздь :)
приведены сумбурные сведения, которые практически не использовать.
Это сумбурное изложение результатов работы последних пяти лет. Бегло приведенные объемы обрабатываемой информации — один из кусочков данной реальности.
Плюс несколько скриптов, с которых все это начиналось, до сих пор работают в одном из наших телеком-монстров. Для решения той задачи их просто нечем заменить — дорого. Собственно они и были разработаны из-за того, что не было нормальных ресурсов и было жесткое требование по времени предоставления результатов. В общем, чтобы выжить (я был на испытательном сроке), пришлось вывернуться наизнанку. Это удалось.
Структуры данных и схемы их хранения — сердце поисковика (как и любой системы обработки данных). Просто владея данной информацией можно оценить возможности системы, в том числе расширяемость и, что не менее важно — энергозатратность. При нынешних о.юъемах информации в сети последнее — важнейший показатель жизнеспособности.
К счастью мне сейчас данные приносят на блюдечке.
Для парсинга — я потестировал библиотеку libxml2 — мне понравилось.
А насчет сбора данных с сайтов — кратко опишу, какие грабли нам попадались, когда решали подобную задачу. Надо было обежать много-много страниц и выкусить с них нужную информацию.
Нету у меня нескольких серверов.
В настоящий момент один сервер на обработке, второй — поиск по результатам.
Плюс специфика текущей задачи — гигантские словари. В реальном поиске вряд ли будут словари на сотни миллионов записей — десятки тысяч. А это уже другая специфика работы.
По хранению и частично обработке написал отдельный топик: http://bit.habrahabr.ru/blog/91828/
Вопрос получения данных — дело вкуса. На мой взгляд — должны присутствовать все варианты. Точнее, должен быть универсальный шлюз, принимающий данные в заданном формате (xml или что-то другое, главное достаточно простое для разбора и понятное для чтения человеком). А уж откуда берут данные программы, закладывающие их в этот шлюз — какая разница?
Составной индекс — результат склейки двух и более моно-индексов. По-моему проще данного велосипеда изобрести сложно. В качестве эксперимента я пробовал делать моноиндексы по двум и трем словам — объемы растут немерянно.
Есть рабочие варианты по построению инверсных индексов. Они опробованы и работают по достаточно большим объемам данных. По данным результатам можно судить о преимуществах и недостатках выбранных моделей. В общем есть практическое представление, как такое хозяйство работает и каких пакостей от него можно ждать :)
Да я и не спорю, что они могут там жить. Сам пользовался такими базами (держали трафик крупного телекома за несколько месяцев). Спору нет, это удобно, когда нужен нестандартный запрос и есть время подождать. Но когда от трети до половины такого индекса требует ежедневного обновления — нужны приличные ресурсы. Плюс тысячи однотипных запросов в сутки с требованием по времен ожидания не превышающем секунды (для одного запроса).
Я не являюсь ярым противником универсальных СУБД. Где можно — пользуюсь ими. Это позволяет ускорить разработку и сделать данную часть продукта более универсальной. Но когда с ростом нагрузок приходится выбирать — я выбираю в пользу специализированных, узко заточенных решений.
Есть некоторые наработки по выборке данных из больших массивов. СУБД сразу не рассматривалась по причине больших объемов (до пары сотен гиг в настоящее время).
В основе лежат упорядоченные списки с ключевым файлом. Структура довольно простая и неплохо работает.
Замена слов (и ссылок на страницы тоже) на числовые идентификаторы не только сокращает объем индекса, но и позволяет использовать записи фиксированной длины, что удобней и быстрее.
Основная работа делается на этапе обработки информации — для ускорения процесса приходится поддерживать приличную избыточность. Но оно себя окупает.
Главное ограничение — наращиваемость функционала. Что забил в структуру, с тем и живи. Желание добавить бантик как правило влечет за собой поход по всей цепочке обработки. Поэтому десять раз подумаешь, прежде чем за что-то браться.
Хорошая вещь, когда туда зайдешь и будешь пользоваться.
Вот только простой человек, попадающий на страницу Гугла видит перед собой поиск, ну и что-то еще боковым зрением. Попадающий на Яху или Яндекс видит много всего, ну еще и поиск плюс ко всему. Вопрос расстановки акцентов. В первом случае жестко на поиск, во втором — на многообразие сервисов.
Возможно на результат людских предпочтений влияет менталитет или какие другие ньюансы, но если в Штатах более поздний простой Гугл обошел порталообразную Яху, то в России порталообразный Яндекс не сдается так легко аскету Гуглу.
Гугл хорошо умеет монетизировать сопутствующие сервисы и с таким решением по Андроиду они фактически вернулись к своей любимой модели.
90 тысяч приложений в маркете будет или 300 тыс. — лично для меня не важно, всеравно все просмотреть не смогу :) А то, что лично мне необходимо для работы и удовольствия — присутствует.
Ну а когда лезу в дебри этого кода, смотрю, как бы это сделал я. Если удается сделать более эффективный код, значит исходный не очень удачен, а если «вау! я бы до этого не додумался!» — значит в данном вопросе автор сильнее меня и у него не стыдно поучиться. Изучение чужого опыта и чужих ошибок — более быстрый способ роста, чем набивать на том-же месте свои шишки :) Шрамы, даже виртуальные, украшают мужчину, когда их количество разумно. Когда их слишком много — получается уродство.
А к данной статье я бы еще добавил пожелание периодически копаться в чужих текстах программ. Тоже в плане самообразования. Грамотно написанный код может быть неплохим учебным пособием и источником новых приемов программирования…
Ну а разбирая плохой код (если нужда заставила) учишься, как не надо делать :)
Но в жизни бывают разные ситуации. Иногда пишу свое, хотя что-то уже есть, иногда использую готовые решения. В каждом случае решаю из ситуации. Иногда работа стороннего продукта меня не устраивает по каким-то причинам (как правило — большая ресурсоемкость, медленная скорость работы), тогда пытаюсь найти свое решение. Иногда не заморачиваюсь и беру готовое — когда нужно быстро получить и оценить результат или самостоятельно ваять слишком долго и дорого. В процессе жизни кода, бывает, переделываю отдельные участки, когда с ростом нагрузок становятся более заметны узкие места или просто вижу способ улучшить результат.
В общем правда, как обычно, где-то посередине. Но в любом случае, понимание, как работает используемая вами сторонняя программа позволяет добиться лучших результатов. Иногда для этого совсем не обязательно параллельно писать свое. Достаточно хорошенько подумать, как это может крутиться внутри.
Все подробности — думаю они охраняются не хуже гостайн.
Кстати я слышал, что Яндекс еще и Berkeley DB использует.
Я видел, как разные люди одинаковым молотком пользуются — один бил по пальцам, а другой двумя ударами вгонял трехдюймовый гвоздь :)
Это сумбурное изложение результатов работы последних пяти лет. Бегло приведенные объемы обрабатываемой информации — один из кусочков данной реальности.
Плюс несколько скриптов, с которых все это начиналось, до сих пор работают в одном из наших телеком-монстров. Для решения той задачи их просто нечем заменить — дорого. Собственно они и были разработаны из-за того, что не было нормальных ресурсов и было жесткое требование по времени предоставления результатов. В общем, чтобы выжить (я был на испытательном сроке), пришлось вывернуться наизнанку. Это удалось.
Для парсинга — я потестировал библиотеку libxml2 — мне понравилось.
А насчет сбора данных с сайтов — кратко опишу, какие грабли нам попадались, когда решали подобную задачу. Надо было обежать много-много страниц и выкусить с них нужную информацию.
В настоящий момент один сервер на обработке, второй — поиск по результатам.
Плюс специфика текущей задачи — гигантские словари. В реальном поиске вряд ли будут словари на сотни миллионов записей — десятки тысяч. А это уже другая специфика работы.
http://bit.habrahabr.ru/blog/91828/
Вопрос получения данных — дело вкуса. На мой взгляд — должны присутствовать все варианты. Точнее, должен быть универсальный шлюз, принимающий данные в заданном формате (xml или что-то другое, главное достаточно простое для разбора и понятное для чтения человеком). А уж откуда берут данные программы, закладывающие их в этот шлюз — какая разница?
Составной индекс — результат склейки двух и более моно-индексов. По-моему проще данного велосипеда изобрести сложно. В качестве эксперимента я пробовал делать моноиндексы по двум и трем словам — объемы растут немерянно.
Я не являюсь ярым противником универсальных СУБД. Где можно — пользуюсь ими. Это позволяет ускорить разработку и сделать данную часть продукта более универсальной. Но когда с ростом нагрузок приходится выбирать — я выбираю в пользу специализированных, узко заточенных решений.
В основе лежат упорядоченные списки с ключевым файлом. Структура довольно простая и неплохо работает.
Замена слов (и ссылок на страницы тоже) на числовые идентификаторы не только сокращает объем индекса, но и позволяет использовать записи фиксированной длины, что удобней и быстрее.
Основная работа делается на этапе обработки информации — для ускорения процесса приходится поддерживать приличную избыточность. Но оно себя окупает.
Главное ограничение — наращиваемость функционала. Что забил в структуру, с тем и живи. Желание добавить бантик как правило влечет за собой поход по всей цепочке обработки. Поэтому десять раз подумаешь, прежде чем за что-то браться.
Вот только простой человек, попадающий на страницу Гугла видит перед собой поиск, ну и что-то еще боковым зрением. Попадающий на Яху или Яндекс видит много всего, ну еще и поиск плюс ко всему. Вопрос расстановки акцентов. В первом случае жестко на поиск, во втором — на многообразие сервисов.
Возможно на результат людских предпочтений влияет менталитет или какие другие ньюансы, но если в Штатах более поздний простой Гугл обошел порталообразную Яху, то в России порталообразный Яндекс не сдается так легко аскету Гуглу.
Пытаюсь читать.