- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Стоит задача выпустить в свет поисковик. Все подсистемы хорошо распараллеливаются для размещения на отдельных серверах: индексатор, статистика, поисковая часть, клиентская часть, биллинг. Основные параметры такие. Количество данных до 1Гб. Индекс до 1 Гб, хранится в своей базе. Используется Беркли для хранения пар "основа слова" - "идентификатор слова". Используется MySQL для работы с количеством запросов до 50 000 запросов/сутки, нет кластера. Биллинг на отдельном сервере, распараллеливаться не может, но действий на нём минимум.
Основная нагрузка на поисковую часть: пройтись по 2-3 индексам размером до 100 тыс. идентификаторов слов, найти схожие записи, схожие записи отсортировать. Запросов со стороны сёрферов будет от 1 тыс. в час в начале до 100 тыс. в час через год. Поисковая часть хорошо может масштабироваться на сервера. Поэтому стоит задача минимизации стоимости процессорной мощности системы.
Насколько я понимаю, в данной ситуации можно брать слабенькую дешёвую дисковую подсистему. Хочется понять, в каких условиях будет минимальна стоимость железа+поддержки системы. Стали ли бы вы ориентироваться на пару-тройку мощных надёжных серверов или лучше ориентироваться на много дублирующихся слабеньких? Насколько критично дублирование системы в другом датацентре Москвы?
Какую стратегию лучше избрать во время бурного роста для минимизации затрат: аренда серверов или покупка?
Слава Шевцов, Вы изначально допустили ошибку связывая слова Mysql и поисковая система, тут Вам никакой кластер не поможет.
Слава Шевцов, Вы изначально допустили ошибку связывая слова Mysql и поисковая система, тут Вам никакой кластер не поможет.
Если использовать MySQL только для хранения данных о рекламодателях контекстной рекламы (клиентах), а всю информацию для работы поисковика выгружать в собственную БД, то поможет.
Слава, а поподробнее можно? У меня тут есть один проект самописный (см подпись)... может удастся скооперироваться? Если интересно, пиши в личку. В эту тему я редко заглядываю...
После проработки вопроса пришёл к такой архитектуре:
1. Выделенный сервер для обслуживания рекламодателей. Крутится nginx + fastcgi + php. Слабенькие диски для данных, мало памяти.
2. Сервер Mysql. Хорошие диски, много памяти.
3. Нужное количество полностью идентичных серверов под поисковый движок. На каждом в памяти хранится реплика всех данных. Слабенькие диски для данных, много памяти, древние процессоры. При смерти каждой из машин система остаётся работоспособной.
4. На отдельной машине биллинг кликов с быстрой отработкой запросов. Данные с неё снимаются раз в минуту, но копия хранится сутки. Эта же машинка является вспомогательным прокси. Мало памяти, слабые диски.
5. Прокси-сервер. Роутит запросы на сервера и балансирует нагрузку.
6. Сервер для переиндексации данных. Слабенькие диски для данных, мало памяти.
7. Сервер под бекап. Слабенькая машинка с большим диском. Здесь находится копия всех данных.
8. Сервер управления системой: перенос данных из MySQL в индексатор, репликация обратных индексов на сайты поисковых серверов, пренос данных из сервера биллинга в MySQL. Здесь же в свободное время крутится система обработки статистики. Надёжность машины и диски не критичны.
В дополнительном хостинге ожидают копии серверов 3, 4 и 5. Хотя если есть датацентры, при падении которых рушится интернет в Москве, то в таком дублировании нет необходимости.
У меня есть опыт работы с мультиагентами и вообще с параллельными задачами. Что сразу заметил - главное это жирный канал в инет и процессор. Жесткого диска нынче всегда хватает, а вот даже поисковые боты жрут проц нормально. + еще важно на чем написаны боты.
Вот в Вашем случае вы на чем хотите ботов сделать?
Я уже писал что портал http://tvoibilet.ru разрабатывал(500к билетов) на своем софте для граббинга, который и граббером то не назовешь - он может и индексить и даже обрабатывать данные. Вот он написан на java и на С-ях. Вот java версия кушает проц сильновато, а на винде все ок. Так что это палка о 2-х концах.
Если хотите сотрудничать - пишите в личку или в асю сразу.