- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
1. Каждая строка может быть представлена как конкатенация двух своих половин ...
"Половины" - можно понимать не как ТОЧНОЕ деление пополам, но как "приблизительное" деление, - с тем, чтобы - по возможности - не "разбивать" ни слова (если строка состоит из нескольких словоформ), ни "предложения" (если строка состоит из нескольких предложений) ...
Каждая из двух половин - тоже является строкой, и даже - как правило - более-менее осмысленной.
2. В процессе последовательного деления любой конкретной строки мы рано или поздно придем к "алфавиту" - к "терминальным символам", понимаемым (в зависимости от задачи) или как буквы, или как словоформы, или как комбинации букв - части слова ...
3. Пусть мы обрабатываем некоторый "большой контент", понимаемый как набор "текстов" (=строк) ...
При помощи некоторого алгоритма хеширования мы составляем "индекс", понимаемый как список уникальных (!) хеш-ключей всех текстов, входящих в данный контент.
Этот индекс представляет собой таблицу из трех числовых полей (key,key1,key2), каждая строка которой описывает одну уникальную текстовую строку.
Значения полей:
key - хеш-ключ описываемой текстовой строки (= уникальный идентификатор строки таблицы!),
key1 - хеш-ключ ее "левой половины",
key2 - хеш-ключ ее "правой половины".
При этом - наряду с "исходной" ("длинной") текстовой строкой - в данный индекс мы заносим (если они еще не занесены!) также обе ее "половины" ... так, чтобы значения key1 и key2 всегда указывали на РЕАЛЬНЫЕ строки таблицы ...
4. Понятно, что строки индекса, описывающие "терминальные символы" (см. п. 2), будут иметь ПУСТЫЕ значения полей key1 и key2 (поскольку терминальный символ не имеет "подстрок") ... или, например, - в соответствии со СПЕЦИАЛЬНЫМ СОГЛАШЕНИЕМ - одно из этих полей может иметь пустое значение, а другое - указывать "вовне индекса" на специальную таблицу используемых нами "терминальных символов".
5. Возвращаясь к subj-у, - понятно, почему там значится "хранилище": потому, что используя подобный индекс мы можем ЛЕГКО восстановить каждую исходную строку (текст!) по ее уникальному хеш-ключу.
_____________________________________
Очень хотелось бы услышать содержательные комментарии ... в частности, - делает ли кто-нибудь подобные индексы?
Если имеются ввиду поисковики... яндекс точно не так делает.
был хороший пример с полгода назад приведен Мастерицей - честно сказать я тогда был очень удивлен .. там приводился контент величиной наверное мега под полтора...
был хороший пример с полгода назад приведен Мастерицей ...
- что-то не могу его найти ...
"Мастерица" - это ник?
Поиск - ни по "астери", ни по "asteri" - ничего не дает ...
А что вы хотите делать с помощью этой структуры? Она не будет ни маленькой, ни быстрой по поиску. Зачем она нужна?
"ни маленькой, ни быстрой по поиску" - все в мире относительно ... мне так кажется, что НА БОЛЬШИХ "ЧЕЛОВЕЧЕСКИХ" контентах она как раз будет "сравнительно маленькой", а по сравнению с "обычными" архиваторами может оказаться "относительно быстрой" ...
Впрочем, не могу сказать, чтобы я был в этом "настойчиво" уверен ... потому и хотел бы обсудить тему со специалистами.
"Что хочу делать" - хранить и обрабатывать "БОЛЬШИЕ "ЧЕЛОВЕЧЕСКИЕ контенты" ... более подробно - опять же - пока не знаю , чего я хочу ... ;-)
Вы бы, прежде чем обсуждать проблему со специалистами, сначала сами попробовали ее как-то сформулировать. Иначе в этом ничего не понимает даже
Google. :)
От нашего стола - вашему столу:
Результаты 1 - 10 из примерно 16 100 000 для large content.
Результаты 1 - 10 из примерно 16 100 000 для large content
Шутки шутками, но без постановки задачи никто ничего умного не скажет. :)