Введення
Сучасний етап розвитку цивілізації характеризується переходом найбільш розвиненої частини людства від індустріального суспільства до інформаційного. Одним з найбільш яскравих явищ цього процесу є виникнення і розвитку глобальної інформаційної комп'ютерної мережі. У даній роботі розглядаються теоретичні основи інформаційного пошуку, класифікація та різновиди інформаційно пошукових систем. При появі мережі Інтернет проблема пошуку ставала більш актуальною. Інтернет - всесвітня комп'ютерна мережа, що є єдине інформаційне середовище і дозволяє отримати інформацію в будь-який час. Але з іншого боку в Інтернеті зберігатися дуже багато корисної інформації, але для пошуку її потрібно витрачати багато часу. Ця проблема стала приводом до появи пошукових машин. Інформаційні системи є основним засобом, інструментарієм рішення задач інформаційного забезпечення різних видів діяльності і найбільш бурхливо розвивається галуззю індустрії інформаційних технологій. Структура інформаційної системи.
1 Постановка завдання
Основною метою даної дослідницької роботи є аналіз існуючих інформаційно-пошукових систем. Їх призначення та застосування, а також етапи розробки систем.
У процесі дослідження необхідно вирішити такі завдання:
- Проаналізувати можливі особливості пошукових систем;
- Провести класифікацію пошукових систем;
- Розкриття особливостей пошукових систем;
- Опис основних етапів розробки.
2 Інформаційно-пошукові системи
2.1 Розвиток пошукових систем
Історичні передумови розвитку пошукових систем. Звернімося до історії виникнення мережі Internet, яка була створена у зв'язку з виниклою необхідністю спільного використання інформаційних ресурсів, розподілених між різними комп'ютерними системами. Більшість перших додатків, включаючи FTP і електронну пошту, були розроблені виключно для обміну даними між хост-комп'ютерами Internet. Інші програми, такі як Telnet, створювалися для того, щоб користувач отримав можливість доступу не тільки до інформації, але і до робочих ресурсів віддаленої системи. У міру розвитку Internet (збільшення користувачів і хост-комп'ютерів) колишні методи обміну даними перестали відповідати зростаючим потребам користувачів. Виникла необхідність розробки нових способів пошуку мережевих ресурсів і доступу до них, які дозволяли б використовувати інформацію незалежно від її формату і розташування. Для задоволення таких потреб спочатку були створені Пошукова система Archie, що розв'язує задачу локалізації ресурсів на FTP-сервер, і система Gopher, що спрощує доступ до різних мережевих ресурсів. Потім були розроблені мережеві інформаційні системи WWW і WAIS, що пропонують абсолютно нові методи отримання інформації. Принципи роботи цих систем дозволяють легко орієнтуватися у величезній кількості інформаційних ресурсів без необхідності надання механізмів роботи самої мережі Internet. Такий підхід дозволяє говорити вже не просто про ресурси взаємопов'язаних комп'ютерних систем, а про особливі інформаційних просторах мережі. Система Archie представляє собою комплекс програмних засобів, що працюють із спеціальними базами даних. У цих базах даних є постійно поновлена інформація про файли, до яких можна отримати доступ через сервіс FTP. Користуючись послугами системи Archie, можна здійснити пошук файлу за шаблоном його імені. При цьому користувач отримає список файлів з точним зазначенням місця їх зберігання в мережі, а також з інформацією про тип, часу створення і розмір файлів. Доступ до інформаційно-пошуковій системі Archie може здійснюватися різними шляхами, починаючи від запитів по електронній пошті і за допомогою сервісу Telnet і закінчуючи використанням графічних Archie-клієнтів. Система Gopher була розроблена для спрощення процесу локалізації FTP-ресурсів Internet і для більш зручного подання відомостей про зміст зберігаються на FTP-серверах файлів. Система Gopher дає можливість в зручній формі (у вигляді меню) представляти користувачам про наявні файлах і їхній зміст. Меню Gopher-серверів можуть містити посилання на інші Gopher-і FTP-сервери. Таким чином, користувач отримує можливість "подорожувати" по Internet, не звертаючи уваги на місцезнаходження цікавлять його ресурсів, і отримувати доступ до цих ресурсів. Під інформаційною системою надалі розуміється - організована сукупність програмно - технічних і інших допоміжних засобів, технологічних процесів і функціонально - певних груп працівників, які забезпечують збір, уявлення і накопичення інформаційних ресурсів в певній предметній області, пошук і видачу відомостей, необхідних для задоволення інформаційних потреб встановленого контингенту користувачів - абонентів системи.
2.2 Особливості пошукових систем
Особливості пошукових систем. У роботі пошуковий процес представлений чотирма стадіями: формулювання (відбувається до початку пошуку); дію (що починається пошук); огляд результатів (результат, який користувач бачить після пошуку); та удосконалення (після огляду результатів і перед поверненням до пошуку з іншою формулюванням тієї ж потреби). Більш зручна нелінійна схема пошуку інформації складається з наступних етапів:
- Фіксація інформаційної потреби на природній мові;
- Вибір потрібних пошукових сервісів мережі і точна формалізація запису інформаційної потреби на конкретних інформаційно-пошукових мовами (ІПМ);
- Виконання створених запитів;
- Попередня обробка і вибірка отриманих списків посилань на документи;
- Звернення за обраними адресами за шуканими документами;
- Попередній перегляд вмісту знайдених документів;
- Збереження релевантних документів для подальшого вивчення;
- Витяг з релевантних документів посилань для розширення запиту;
- Вивчення всього масиву збережених документів;
- Якщо інформаційна потреба не повністю задоволена, то повернення до першого етапу.
3 Будова пошукової системи
3.1 Архітектура пошукової системи
Розглянемо класичну архітектуру, яка найчастіше реалізована на корпоративних сайтах та інформаційних порталах. Така архітектура зображена на малюнку 3.1
Малюнок 3.1 Архітектура пошукової системи
Розберемо по частинах те, що зображено на малюнку. Існує клієнтська обчислювальна машина під управлінням ОС Windows і існує Web-сервер під управлінням UNIX-подібної ОС. На стороні клієнта запущений типовий браузер, такий як Netscape. На стороні сервера запущений web сервер, який обслуговує запити від браузера, передаючи запити презентаційного шару розуміючому CGI. Презентаційний шар передає запити до пошукового механізму в разі виклику послуги пошуку або відображає наповнення (content) сайту. При роботі адміністратора презентаційний шар також може передавати запити на ініціалізацію механізму індексації нового контенту, який ще не індексований. Це необхідно з тієї причини, що поки текст не індексований, пошук у ньому за допомогою пошукової машини неможливий.
Ідея полягає в наступному. Існують мегабайти текстової інформації, і швидкість пошуку документів містять задані ключові слова забирає дуже багатопроцесорного часу. Припустимо, в 10 мегабайтах текстової інформації ключове слово буде перебувати протягом 10 секунд. І ось заходить відвідувач на Ваш сайт, задає ключові слова, викликає послугу пошуку та чекає 10 секунд, поки ваш сервер не видасть йому результат. Припустимо, сталося так, що одночасно запросило пошук 5 осіб. Природно, час відповіді збільшиться в 5 разів. Виходить, що в середньому по 50 секунд користувач буде чекати відповіді від вашого сервера. Це не прийнятно, особливо якщо у Вас сотні мегабайт текстової інформації і час реакції системи буде катастрофічно велике. Необхідно використовувати інший підхід при пошуку ключових слів у текстовій інформації - час відповіді скоротити до мілісекунд.
3.2 ER-модель пошукового механізму
Існує така гарна характеристика реляційних баз даних, як дуже маленький час вибірки конкретного запису з мільйонів інших. Це досягається створенням, так званого, індексу до таблиці на якесь із полів цієї таблиці. Зазвичай індекси реалізуються із застосуванням алгоритму збалансованого двійкового дерева. Припустимо, у нас є таблиця, в якій всього один стовпець і в кожному записі таблиці зберігається прізвище людини. Припустимо, ми загнали в таку таблицю 1 млн прізвищ. Нам необхідно перевірити чи існує в цій таблиці прізвище Ігумнов. Припустимо, що ми ще ніяких індексів на цю таблицю не зробили, так само прізвище Ігумнов стоїть посередині таблиці. Коли ми пошлемо ось такий запит: select surname from ourtable where surname = 'Ігумнов' база даних перебере пів мільйона записів поки не дійде до прізвища Ігумнов і не видасть результат. Виходить занадто повільно. Але як тільки ми зробимо індекс на полі нашої таблиці, як відразу всі наші запити будуть оброблятися за мілісекунди, чого ми і добиваємося. Природно, однієї таблиці буде мало для вирішення нашої проблеми. Класична структура бази даних, яка дозволить вирішити нашу проблему, зображена на малюнку 3.2:
Малюнок 3.2 Класична структура бази даних
Почнемо з таблиці document. У цій таблиці зберігаються імена файлів або URL'и сторінок і кожної такого запису сопоставлен унікальний ключ id. У таблиці dictionary зберігаються всі слова, які можуть зустрітися в наших документах, і кожному слову сопоставлен унікальний id. Природно, створюються індекси на полі word в таблиці dictionary і на полі id у таблиці document. У нашому прикладі існує відношення багато до багатьох. Це необхідно, тому що в таблиці match ми зберігаємо відповідність слова і документа. Іншими словами, в таблиці match зберігається інформація про те, які слова є в кожному документі. На таблицю match створюють індекс, на полі dict_id.
3.3 Індексний механізм
Перш ніж ваші документи будуть доступні для пошуку, їх необхідно проіндексувати. Обсяг індексної інформації, отриманої з тексту, може бути в два рази більше ніж сам тексті. А може ще більше, у випадку якщо ви будете не оптимально використовувати пам'ять. Алгоритм виглядає наступним чином:
1. одержуємо документ для індексування;
2. реєструємо його в таблиці document, запам'ятовуємо отриманий його унікальний id і будемо його називати doc_id;
3. розбиваємо документ на окремі слова;
4. дізнаємося унікальні id цих слів з таблиці dictionary і будемо їх називати dict_id;
5. потім заносимо запису з нашим одним doc_id і різними dict_id (для кожного слова в документі) в таблицю match.
3.4 Пошуковий механізм
Після того як ми проіндексували наші документи, потрібно зрозуміти які запити посилати в базу, що б шукати ці документи за ключовими словами. Припустимо, є пошукова фраза "ріка об'єк". Користувачеві необхідно отримати всі документи містять ці два слова. Спочатку потрібно звернутися до таблиці dictionary і дізнатися унікальні id цих слів, далі будемо їх називати $ dict_id1 і $ dict_id2. Потім необхідно надіслати такий запит до таблиці match, який видає тільки ті номери документів, які містять ці два слова. Ось приклад цього запиту: SELECT doc_id FROM match where dict_id = $ dict_id1 group by doc_id INTERSECT SELECT doc_id FROM match where dict_id = $ dict_id2 group by doc_id. У разі якщо користувач введе три слова, то вам доведеться додати ще раз INTERSECT і третю частину SQL запиту. За отриманими в результаті запиту doc_id можна витягти інформацію про ім'я файлу документа з таблиці document.
3.5 Комплексне функціонування
Що б побачити загальне уявлення механізму взаємодії з пошуковою системою потрібно поглянути на малюнок 3.3:
Малюнок 3.3 Механізм взаємодії з пошуковою системою
Як видно з малюнка, існує три потоки управління. Перший обслуговує запити користувача, другий виконує пошукові запити, а третій займається індексуванням нових документів вступників до системи. Перший потік - це скрипт на Perl, Servlet, ASP або PHP, який з ключових слів користувача формує пошукові SQL запити. Другий потік - це СУ базою даних, яка підтримує цілісність даних, індексний механізм і обслуговує SQL запити. Третій потік - це теж скрипт, який працює з новими документами, індексує їх і посилає запити до бази даних на внесення нової індексної інформації.
4 Принципи роботи пошукової машини Рамблер
Інтернет постійно зростає, так само як росте і число користувачів, які звертаються із запитами до пошукових систем. Збільшення обсягу інформації та кількості запитів, у свою чергу, призводить до підвищення вимог до швидкості роботи пошукових машин, якості пошуку та наочності представлення результатів. Так, для того, щоб користувач залишився задоволений результатом, на сьогоднішній день пошуковій системі потрібно зібрати, обробити, оновити, знайти і відсортувати в два рази більше документів, ніж рік тому. А основне завдання пошуку як раз і полягає в тому, щоб користувач був задоволений його результатами.
Коли користувач звертається із запитом до пошукової машини, він хоче знайти те, що йому потрібно, максимально швидко і просто. Отримуючи результат, він оцінює роботу системи, керуючись декількома основними параметрами. Чи знайшов він те, що шукав? Якщо не знайшов, то скільки разів йому довелося переформулювати запит, щоб знайти шукане? Наскільки актуальну інформацію він зміг знайти? Наскільки швидко обробляла запит пошукова машина? Наскільки зручно були представлені результати пошуку? Чи був шуканий результат першим або сота? Як багато непотрібного сміття було знайдено нарівні з корисною інформацією? Чи зможе він, повернувшись завтра і давши той самий запит, отримати ті ж результати?
Для того, щоб відповіді на ці питання залишалися хоч трохи задовільними, розробники пошукових машин постійно вдосконалюють алгоритми і принципи пошуку, додають нові функції, прискорюють роботу системи. У цій статті ми звернемося до механізму роботи пошукової машини Рамблер, і на прикладі її пристрою продемонструємо, як досягається підвищення якості та швидкості пошуку умовах постійного зростання обсягу інформації в мережі Інтернет.
Повнота - це одна з основних характеристик пошукової системи, яка представляє собою відношення кількості знайдених за запитом документів до загального числа документів в Інтернеті, що задовольняють даному запиту.
Повнота пошуку у великій мірі залежить від роботи системи збору і обробки інформації. У зв'язку з постійним зростанням кількості документів у мережі, ця система в першу чергу повинна бути масштабованої. У Рамблері масштабованість досягається за рахунок паралельного виконання завдання будь-якою кількістю машин.
Збором інформації займається робот-павук, який обходить сторінки з заданими URL і завантажує їх в базу даних, а потім повертати та перекладає у сховище добовими порціями. Робот розміщується на декількох машинах, і кожна з них виконує своє завдання. Так, робот на одній машині може качати нові сторінки, які ще не були відомі пошуковій системі, а на іншій - сторінки, які раніше вже були завантажені не менше місяця, але й не більше року тому. Сховище у всіх машин Одно. При необхідності роботу можна розподілити іншим способом, наприклад, розбивши список URL на 10 частин і роздавши їх 10 машин. Паралельна робота програми дозволяє легко витримувати додаткове навантаження: при збільшенні кількості сторінок, які потрібно обійти роботу, досить просто розподілити завдання на більше число машин.
Після того, як всі частини інформації оброблені, починається об'єднання (злиття) результатів. Завдяки тому, що часткові індексні бази і основна база, до якої звертається пошукова машина, мають однаковий формат, процедура злиття є простою і швидкою операцією, що не вимагає ніяких додаткових модифікацій часткових індексів. Основна база бере участь в аналізі як одна з частин нового індексу.
Збірка єдиної бази з часткових індексних баз являє собою простий і швидкий процес. Зіставлення сторінок не вимагає ніякої інтелектуальної обробки і відбувається зі швидкістю читання даних з диска. Якщо інформації, яка генерується на машинах-індексатора, виходить занадто багато, то процедура "зливання" частин проходить у кілька етапів. Спочатку часткові індекси об'єднуються в кілька проміжних баз, а потім проміжні бази та основна база попередньої редакції перетинаються. Таких етапів може бути скільки завгодно. Проміжні бази можуть зливатися в інші проміжні бази, а вже потім об'єднуватися остаточно. Поетапна робота незначно уповільнює формування єдиного індексу і не відбивається на якості результатів.
Точність - ще одна основна характеристика пошукової машини, яка визначається як ступінь відповідності знайдених документів запиту користувача. Наприклад, якщо на вимогу "Червона площа" знаходиться 150 документів, у 70 з них міститься словосполучення "Червона площа", а в інших просто присутні ці слова ("червона баба кричала на всю площу"), то точність пошуку вважається рівною 70/150 (~ 0,5). Чим точніше пошук, тим швидше користувач знаходить потрібні йому документи, тим менше "сміття" серед них зустрічається, тим рідше знайдені документи не відповідають запиту.
Спосіб підвищення точності пошуку - це виділення стійких позначень і пошук їх як окремих лексичних одиниць. На сьогоднішній день в Рамблері реалізована система розпізнавання таких конструкцій, наприклад C + +, б / в, п / п-к. Якщо за запитом С + + піднімати всі тексти, в яких присутні латинська літера С, а також знак +, то вийде величезна кількість документів, далеко не всі з яких відповідають запиту; крім того, це велика робота, значно збільшує час пошуку.
Крім автоматичних способів збільшення точності пошуку, існують різні засоби, за допомогою яких користувач сам може уточнити пошук за окремими запитами. У першу чергу до них відноситься спеціальна мова пошукового запиту, використовуючи який можна обмежувати кількість знайдених документів. Наприклад, запит або його частина, взяті в лапки, обробляються буквально, з урахуванням всіх стоп-слів, форм, порядку, розділових знаків. Це підвищує точність пошуку, але зменшує його повноту: якщо частина, укладена в лапки, неточна, потрібний документ знайдений не буде.
Актуальність - не менш важлива характеристика пошуку, яка визначається часом, який проходить з моменту публікації документів в мережі Інтернет, до занесення їх в індексну базу. Наприклад, на наступний день після теракту в Тушино величезна кількість користувачів звернулися до пошукової машини Рамблер з відповідними запитами. Об'єктивно з моменту публікації новинної інформації на цю тему пройшло менше доби. Однак основні документи вже були заіндексувати і доступні для пошуку, завдяки існуванню "швидкої бази", яка оновлюється двічі на день, а при необхідності може оновлюватися швидше.
Швидкість пошуку тісно пов'язана з його стійкістю до навантажень. На сьогоднішній день в робочі години до пошукової машини Рамблер приходить близько 60 запитів у секунду. Така завантаженість вимагає скорочення часу обробки окремого запиту. Тут інтереси користувачів та пошукової системи збігаються: відвідувач хоче отримати результати як можна швидше, а пошукова машина повинна відпрацьовувати запит максимально оперативно, щоб не гальмувати обчислення наступних. Схематично обробка пошукового запиту зображена на малюнку 4.1
Малюнок 4.1 Схематично обробка пошукового запиту
Запит надходить в пошукову систему через маршрутизатор Cisco 6000 series. Cisco передає його найменш завантаженої машині першого рівня - frontend (1.1 - 1.3, на рис. Машині 1.3). Frontend, у свою чергу, відправляє запит далі, на один з восьми proxy-серверів, також вибираючи найбільш вільний сервер (2.1 - 2.8, на рис. Машині 2.2). Одночасно frontend відправляє запит на машини, що здійснюють пошук по товарах (3.1 - 3.2, на рис. Машині 3.1) і по базі Тор 100 (4.1 - 4.2, на рис. Машині 4.1). На proxy проводиться пошук по посилальної індексу, і його результати разом з пошуковим запитом передаються на машини, які містять основну індексну базу, - backends (5.1.х - 5.7.х, на рис. Машинам 5.1.2, 5.2.11, 5.3. 1 і т.д.) Та ж інформація відправляється на машини з "швидкою базою" (6.1 - 6.2, на рис. 6.1).
На поточний момент в пошук включено 77 backend'ов. Вони згруповані по 11 машин, і кожна група містить копію однієї з частин пошукового індексу. Таким чином, інформація про сайти, умовно входять в червоний сектор Інтернету, знаходиться на backend'ах першої групи (5.1.1 - 5.1.11 на рис), помаранчевий сектор - на backend'ах другої групи (5.2.1 - 5.2.11 ) і т.д. Proxy-сервер вибирає найменш завантажений backend в кожній групі машин і відправляє на нього пошуковий запит з результатами посилального пошуку. На backend'ах здійснюється пошук по частинах індексної бази і ранжування з урахуванням результатів пошуку по посилальної індексу. При ранжируванні для всіх знайдених документів вираховуються ваги за конкретним запитом.
Після того, як запит оброблений на backend'ах, інформація про результати та ранжуванні віддається назад на proxy-сервер. Туди ж надходять відсортовані результати з машин "швидкої бази". Proxy інтегрує дані, отримані з восьми машин: клеїть дублі, об'єднує дзеркала сайтів, переранжірует документи у загальний список за вагами, розрахованим на backend'ах. Так, першим у списку знайденого може бути документ з машини 5.3.1, другим і третім - до 6.1, четвертим - з 5.5.2 і т.д. На proxy-сервері також реалізується побудова цитат до документів і підсвічування слів запиту в тексті. Отримані результати віддаються на frontend.
Крім інформації з proxy-сервера, frontend отримує результати з пошуку по товарах і з бази Тор 100, відсортовані, з цитатами і підсвічуванням слів запиту. Frontend здійснює остаточне об'єднання результатів, генерує html зі списком знайденого, вставляє банери і перев'язки (посилання на різні розділи Рамблера) і віддає html Cisco, який маршрутизує інформацію користувачеві.
Кожен з етапів обробки запиту багаторазово продубльований і захищений системою балансування навантаження. Завдяки дублювання інформації Пошукова система Рамблер є стійкою до збоїв на окремих ділянках, аварій, відмов обладнання. Якщо одна їхніх машин перестала функціонувати, навантаження перерозподіляється на інші машини, і випадання документів з пошуку не відбувається. Масштабованість досягається простим додаванням в систему машин відповідного рівня. До недавнього часу в Рамблері працювало 45 backend'а. У зв'язку з тим, що восени навантаження на пошукові системи зазвичай зростає, число backend'ов було збільшено до 77, що дозволило значно прискорити обчислення запитів.
Висновки
Висновок пишеться в кінці і передбачає кінцівку. Але зростання інформації нескінченний, а тому немає межі вдосконаленню пошукових машин. Найважливішим завданням розробників є поліпшення якості пошуку, рух у бік більшої ефективності та зручності у використанні системи. З цією метою постійно змінюються пошукові алгоритми, створюються додаткові сервіси, допрацьовується дизайн.
Однак для того, щоб вижити в світі динамічного Інтернету, при розробці необхідно закладати великий запас стійкості, постійно заглядати у завтрашній день і приміряти майбутню навантаження на сьогоднішній пошук. Такий підхід дозволяє займатися не тільки постійною боротьбою і пристосуванням пошукової машини до зростаючих обсягів інформації, але і реалізовувати щось нове, дійсно важливе і потрібне для підвищення ефективності пошуку в мережі Інтернет.
Список використаних джерел
Таненбаум Е. Комп'ютерні мережі. Спб.: «Пітер», 2002.
Довідкова інформація по мережах ЕОМ і телекомунікацій www. Index. Com
Закері К. Комп'ютерні мережі. Модернізація та пошук несправностей. Спб.: «БХВ-Петербург», 2002 р.