Многосерверность

У нас на работе одно время стоял дата-сервер на 4.3 терабайта 🙄

В тему:

http://www.mysql.com/products/database/cluster/

dkameleon, кластер Mysql для поисковика с большим кол-вом документов не поможет - не выгоден.

alexf2000, интернет индексируется самый обычный который есть у всех :) индексировался кусками, сейчас проиндексировано 100% байнета и ~35% укр-нэта.

dkameleon, Сервер на 4.3 терабайта это конечно круто, но как оно относится к тому что тут обсуждается?

snoopckuu, Какой средний размер документа? Если сервер нормальный, с обычным диском/RAID-ом, то при таком общем количестве документов он не может быть сильно больше 1к. А при таком среднем размере индексироваться могут разве что 404е страницы, либо от страницы отрезается только заголовок. То есть чувствуется какой-то мухлёж. :)

Отвечает на вопрос про 80 миллионов документов ;)

alexf2000, какой мухлёж? Да вы что? :) Я разрабатываю поисковые механизмы уже больше 6 лет, но дело не в этом, обманывать мне не интересно да и не имеет смысла, рассказываю подробно берём информацию из разных источников, берём вэбальту главная страница поисковика и видим

9.5 тб на 363 844 949 документа это чисто сколько весят документы, после индексирования и сжатия в индекс они занимают на 20% меньше.

Берём яндекс

так что физически хватит ~6 серверов по 4.3тб для того что бы поместить весь рунет проиндексированный яндексом без архивирования, но вам не хватит других мощностей для произведения поиска по этому индексу.

Более менее ясно?

Получаем средний размер документа в обоих случаях ~25к. Ровно как я написал в самом начале. :) То есть для хранения 80 миллионов документов нужно 2 тебарайта, что совсем не похоже на объём диска обычного сервера (200 Гб).

В принципе snoopckuu все абсолютно правильно сказал.

Единственное что стоит дополнительно заметить, что работа всегда идет не с оригинальными документами, а с результатами их анализа (индексами) и индексами этих индексов. Индекс по определенному параметру, величина ничтожная по сравнению с размером документа. Оригиналы обычно если и сохраняются, то архивируются достаточно эфективными методами чтоб существенно снизить размер.

Каждый сервер обычно хранит собственные данные (наиболее критичные целиком загоняются в память) и методы работы с этими данными. Т.е. грубо говоря быстродействие заключается в том, что за момент пока один сервер обрабатывает индекс по кейворду, второй обработает индекс по тематике, третий по ссылкам, и т.д.

Средний веб-документ порядка 2-5 к тексту. Полный его размер 10-20к. Если исключить всякие доки с пдф будет еще меньше. Сжатый инвертированный индекс вполне себе влезает в 50% от размера текста. Ну сжатый образА HTML примерно как текст или полтора текста.

100 млн доков x 5 k тексту = 500 гб диска, умножаем на 1.5 получаем 1.5 террабайта. Ну если образы не хранить на том же сервере получаем 250 гб диска, что соответствует обычному серверу. А HTML для отрисовки сниппетов или прямой индекс можно хранить на одной машинке ну с очень большим и быстрым диском.

Кстати, насчет эффективных методов. Это зависит от архитектуры. Если есть прямой индекс, по которому отрисовываются сниппеты, тогда да: можно жать по полной, потому что разархивировать нужно только по нажатию на ссылку: сохраненная копия.

А если прямой индекс не хранить, а сниппеты делать минимум по HTML тексту, то тут уже очень эффективные методы использовать нельзя, потому что они реально долго распаковывают. Причем до десяти раз медленее какого-нибудь LZ.