Параллельные вычисления можно организовать и в одном инстансе, используя функции Map и Reduce (условно), но это не станет моделью MapReduce. Почитайте на вики, там основное условие - несколько ПК в кластере. Суть в том, что если нужно обработать очень много данных, мы просто добавляем инстансы в кластер и все ускоряется. Это модель для горизонтального масштабирования. Конкретно то что вы имеете ввиду называется embarrassingly parallel (на рус. чрезвычайная параллельность), это задачи которые могут быть распаралелены тупым циклом, и где не нужна синхронизация данных и результаты вычислений не зависят друг на друга (например, результат тиц для сайта site1.ru никак не влияет на результат для сайта site2.ru).
Да, можно поднять базу. Там есть индексы, можно спокойно писать, она будет расти на диске и не будет выжирать оперативку. Но удобно ли, если допустим я захочу запустить проверку на ноуте, но при этом там нету базы. Отталкиваться нужно от требований, которые есть. Готовые инструменты безусловно рулят, но в некоторых случаях можно отказаться от громоздких решений и написать что-то свое, уж опыта и знаний на выходе будет больше.
Это все круто конечно, но хоть убей не пойму зачем 7 млн. сайтов ТИц мониторить. Я даже не уверен что такое количество можно спарсить с яндекса, т.к. через 10 запросов начнутся капчи. И сколько прокси под это дело нужно?
Сортировка не требует выделения памяти. Но требует чтобы в памяти хранился слайс с данными, по которым мы сортируем.
В случае моего велосипеда, переписывать ничего не придется, так как я не представляю себе человека, загрузившего более 10 млн. урлов на проверку ТИЦ. Обработка миллиона записей займет 300 мб в оперативной памяти при самом печальном раскладе (хранить в памяти и сам URL). 10 млн. записей - 2 ГБ, а сортировка по нему займет аж целых 1.2 секунды). Я не знаю кому в здравом уме придет идея загрузить 10 млн. урлов на проверку. При желании можно сделать дисковую сортировку, а в памяти хранить только ТИЦ и номер байта с которого начинается строка. В последующем, мы просто переходим к n-ому байту в файле, и пишем его в файл отсортированный. С таким подходом мы выкинем строки из памяти, что снизит раз так в 10-15 количество потребляемой памяти, но увеличит время работы сортировки.
MapReduce это не тот инструмент, который применим в контексте данной задачи, т.к. для осуществления данного алгоритма, нужен ещё один ПК. Данные разбиваются на чанки и отправляются в кластер (Reduce), машины в кластере обрабатывают данные (Map).
Но что самое страшное в этом, это то что в данной задаче ничему особо не научишься, она скучная и не требует смекалки, все алгоритмы известны и все необходимые функции в ЯП уже есть. Открыть файл, прочитать ссылки, GET запрос, взять оттуда циферки (ТИЦ), записать в память, отсортировать, записать в файл, это скучнейшая задача которая практически ничему не учит. Ну кроме вызова функций для прям совсем новичка.---------- Добавлено 15.10.2017 в 18:11 ----------
Код в студию скиньте, если не стесняетесь.
Ещё можно было вытащить из API VK, как сейчас — не знаю.
При чем тут MapReduce? MapReduce это вообще не про это. Это про обработку в кластерах. В данном случае, файл можно читать построчно, в приложении держать слайс данных (ссылка + ТИЦ), в конце отсортировать и записать в файл. Но сама идейка скучная.
Если не из полезного, но из интересного:
Напишите скрипт симулирующий работу банкомата. У банкомата есть баланс, есть купюры и количество, например:
1$ - 8
5$ - 5
10$ - 2
100$ - 4
Сделайте так, чтобы банкомат выдавал сумму за наименьшее количество шагов, и/или выдавал купюрами с наибольшим количеством в запасе (если есть 100 купюр по 50$, и только одна 100$ купюра, а клиент хочет снять 150$, ему нужно выдать 3 по 50$).
Привет, нормализация. Именно поэтому я дроблю свои таблицы настолько, насколько это возможно. Зато какие потом возможности по работе с данными.
Если запрос разовый, или где-то в бекенде, запускающийся раз в день/неделю, то да, можно регулярками. Если это где-то в приложении будет делаться, и при этом часто, то лучше так не делать, и подробить данные.
Это не то. Кеширование для статики - это хранитить стили и JS в браузере после их загрузки, и не качать с сервера.
Кеширование в статику, это когда результат работы PHP скрипта (сгенерированная html страница) сохраняется на диске или даже в оперативной памяти. Т.е., таким образом при запросе страницы у вас до PHP и базы данных дело вообще не доходит, у вас сразу отдается HTML страница.
Можете погуглить nginx fastcgi_cache
Реальный кейс, на сайте интернет-магазина делал такую фишку, время генерации страницы со 120 мс., упало до 8 мс (пинг не учитывается, учитывается только время генерации страницы). Но там большой спектр работ по адаптации по работу в этом режиме, поэтому на продакшн так и не выкатили.
Глазом не заметили или сухие цифры не изменились? Глазом вообще сложно заметить ускорение менее чем на 10-15%.
Если у вас сайт блог или новостной, и там нету личных кабинетов и прочего, можно включить кеширование nginx, это делается намного проще, чем те же редисы и прочее, и работает намного эффективнее. Тогда ускорение сложно будет не заметить)
Написал тут за пол часа прогу:
- добавляете список сайтов (url, частота проверки, тип проверки (пока только HTTP))
- запускаете
- мониторит в соответствии с выбранным типом проверки
- если что-то упало (для HTTP если ответ сервера не 200 ОК), то запишет в лог и отправит Email
- если что-то поднялось, то запишет в Email во сколько поднялось, какой был downtime, и уведомит по Email (100500 уведомлений присылать не будет)
Если кому-то надо, то могу допилить до вменяемого вида, немного расширить функционал, и выложу у себя на сайте, для скачивания, а также исходники на GitHub.
$ ./pinger 2017/10/07 00:56:26 Start watching 2 sites 2017/10/07 00:56:52 https://quasar.cc down at 2017-10-07 00:56:52 +0300 MSK 2017/10/07 00:57:47 https://quasar.cc up at 2017-10-07 00:57:48 +0300 MSK, downtime 56s
Конечно есть. Zabbix, Nagios, Munin, Cacti, Spiceworks. Был ещё где-то софт который мониторит и шлет мыло, как раз пингуя, но не могу найти. Ещё есть всякие пингдомы и хост-треккеры.
Это позволит загрузится странице, как поведет себя карта с 1к маркерами - другой вопрос.
