Content-pro: Там вроде основная фишка это параллельные вычисления, я особо не работал с большими данными, но немного работал с R, там векторизация работает довольно шустро, типа если знаем длину вектора, рубим, обрабатываем параллельно, потом склеиваем назад в один вектор.
Параллельные вычисления можно организовать и в одном инстансе, используя функции Map и Reduce (условно), но это не станет моделью MapReduce. Почитайте на вики, там основное условие - несколько ПК в кластере. Суть в том, что если нужно обработать очень много данных, мы просто добавляем инстансы в кластер и все ускоряется. Это модель для горизонтального масштабирования. Конкретно то что вы имеете ввиду называется embarrassingly parallel (на рус. чрезвычайная параллельность), это задачи которые могут быть распаралелены тупым циклом, и где не нужна синхронизация данных и результаты вычислений не зависят друг на друга (например, результат тиц для сайта site1.ru никак не влияет на результат для сайта site2.ru).
Content-pro: но она у вас чисто теоретически сейчас обоснована на практике будет сложней, собственно для больших данных лучше использовать специальные инструменты - ну это минимумом практичней.
Да, можно поднять базу. Там есть индексы, можно спокойно писать, она будет расти на диске и не будет выжирать оперативку. Но удобно ли, если допустим я захочу запустить проверку на ноуте, но при этом там нету базы. Отталкиваться нужно от требований, которые есть. Готовые инструменты безусловно рулят, но в некоторых случаях можно отказаться от громоздких решений и написать что-то свое, уж опыта и знаний на выходе будет больше.
Had: У меня на компе 16 гигов памяти физической + кеш. Ради интереса глянул базы свои, многие по 400-500 мегабайт, напомню это файлы тхт с ссылками. Глянул ради интереса одну из баз своих, 7 миллионов ссылок там. Но даже если ТС сделает прогу на 2-3 млн будет круто. Ну или меньше тоже.
Это все круто конечно, но хоть убей не пойму зачем 7 млн. сайтов ТИц мониторить. Я даже не уверен что такое количество можно спарсить с яндекса, т.к. через 10 запросов начнутся капчи. И сколько прокси под это дело нужно?
Content-pro: Можете конечно построчно работать, но уверены что у вас оперативки хватит к примеру для сортировки?
Сортировка не требует выделения памяти. Но требует чтобы в памяти хранился слайс с данными, по которым мы сортируем.
Content-pro: Вообще на миллионах лучше специальные инструменты использовать, ибо а а вдруг данные в два раза увеличатся с специальными инструментами у вас просто время обработки увеличиться, в случае вашего велосипеда, вполне возможно придется все переписывать)
В случае моего велосипеда, переписывать ничего не придется, так как я не представляю себе человека, загрузившего более 10 млн. урлов на проверку ТИЦ. Обработка миллиона записей займет 300 мб в оперативной памяти при самом печальном раскладе (хранить в памяти и сам URL). 10 млн. записей - 2 ГБ, а сортировка по нему займет аж целых 1.2 секунды). Я не знаю кому в здравом уме придет идея загрузить 10 млн. урлов на проверку. При желании можно сделать дисковую сортировку, а в памяти хранить только ТИЦ и номер байта с которого начинается строка. В последующем, мы просто переходим к n-ому байту в файле, и пишем его в файл отсортированный. С таким подходом мы выкинем строки из памяти, что снизит раз так в 10-15 количество потребляемой памяти, но увеличит время работы сортировки.
MapReduce это не тот инструмент, который применим в контексте данной задачи, т.к. для осуществления данного алгоритма, нужен ещё один ПК. Данные разбиваются на чанки и отправляются в кластер (Reduce), машины в кластере обрабатывают данные (Map).
Но что самое страшное в этом, это то что в данной задаче ничему особо не научишься, она скучная и не требует смекалки, все алгоритмы известны и все необходимые функции в ЯП уже есть. Открыть файл, прочитать ссылки, GET запрос, взять оттуда циферки (ТИЦ), записать в память, отсортировать, записать в файл, это скучнейшая задача которая практически ничему не учит. Ну кроме вызова функций для прям совсем новичка.
---------- Добавлено 15.10.2017 в 18:11 ----------
Tyrell: Вот это норм, попробую! Большое количество обрабатываемых урлов обещать не могу по причинам ресурсоемкости, но сама идея из разряда вот прям то что я ищу.
Content-pro: Ну вообщем если без миллионов то эксель справиться на раз. Для миллионов нужна хотя бы умение работать с map-reduce а это явно не для человека который только учиться скрипты писать.
При чем тут 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. Был ещё где-то софт который мониторит и шлет мыло, как раз пингуя, но не могу найти. Ещё есть всякие пингдомы и хост-треккеры.
Gagarin12: Это позволит вывести на карте 1000 маркеров со всей необходимой информацией (кроме координат там есть еще названия фирм, ссылки на карточки фирм)?
Это позволит загрузится странице, как поведет себя карта с 1к маркерами - другой вопрос.
Там вроде основная фишка это параллельные вычисления, я особо не работал с большими данными, но немного работал с R, там векторизация работает довольно шустро, типа если знаем длину вектора, рубим, обрабатываем параллельно, потом склеиваем назад в один вектор.
Параллельные вычисления можно организовать и в одном инстансе, используя функции Map и Reduce (условно), но это не станет моделью MapReduce. Почитайте на вики, там основное условие - несколько ПК в кластере. Суть в том, что если нужно обработать очень много данных, мы просто добавляем инстансы в кластер и все ускоряется. Это модель для горизонтального масштабирования. Конкретно то что вы имеете ввиду называется embarrassingly parallel (на рус. чрезвычайная параллельность), это задачи которые могут быть распаралелены тупым циклом, и где не нужна синхронизация данных и результаты вычислений не зависят друг на друга (например, результат тиц для сайта site1.ru никак не влияет на результат для сайта site2.ru).
но она у вас чисто теоретически сейчас обоснована на практике будет сложней, собственно для больших данных лучше использовать специальные инструменты - ну это минимумом практичней.
Да, можно поднять базу. Там есть индексы, можно спокойно писать, она будет расти на диске и не будет выжирать оперативку. Но удобно ли, если допустим я захочу запустить проверку на ноуте, но при этом там нету базы. Отталкиваться нужно от требований, которые есть. Готовые инструменты безусловно рулят, но в некоторых случаях можно отказаться от громоздких решений и написать что-то свое, уж опыта и знаний на выходе будет больше.
У меня на компе 16 гигов памяти физической + кеш. Ради интереса глянул базы свои, многие по 400-500 мегабайт, напомню это файлы тхт с ссылками. Глянул ради интереса одну из баз своих, 7 миллионов ссылок там. Но даже если ТС сделает прогу на 2-3 млн будет круто. Ну или меньше тоже.
Это все круто конечно, но хоть убей не пойму зачем 7 млн. сайтов ТИц мониторить. Я даже не уверен что такое количество можно спарсить с яндекса, т.к. через 10 запросов начнутся капчи. И сколько прокси под это дело нужно?
Можете конечно построчно работать, но уверены что у вас оперативки хватит к примеру для сортировки?
Сортировка не требует выделения памяти. Но требует чтобы в памяти хранился слайс с данными, по которым мы сортируем.
Вообще на миллионах лучше специальные инструменты использовать, ибо а а вдруг данные в два раза увеличатся с специальными инструментами у вас просто время обработки увеличиться, в случае вашего велосипеда, вполне возможно придется все переписывать)
В случае моего велосипеда, переписывать ничего не придется, так как я не представляю себе человека, загрузившего более 10 млн. урлов на проверку ТИЦ. Обработка миллиона записей займет 300 мб в оперативной памяти при самом печальном раскладе (хранить в памяти и сам URL). 10 млн. записей - 2 ГБ, а сортировка по нему займет аж целых 1.2 секунды). Я не знаю кому в здравом уме придет идея загрузить 10 млн. урлов на проверку. При желании можно сделать дисковую сортировку, а в памяти хранить только ТИЦ и номер байта с которого начинается строка. В последующем, мы просто переходим к n-ому байту в файле, и пишем его в файл отсортированный. С таким подходом мы выкинем строки из памяти, что снизит раз так в 10-15 количество потребляемой памяти, но увеличит время работы сортировки.
MapReduce это не тот инструмент, который применим в контексте данной задачи, т.к. для осуществления данного алгоритма, нужен ещё один ПК. Данные разбиваются на чанки и отправляются в кластер (Reduce), машины в кластере обрабатывают данные (Map).
Но что самое страшное в этом, это то что в данной задаче ничему особо не научишься, она скучная и не требует смекалки, все алгоритмы известны и все необходимые функции в ЯП уже есть. Открыть файл, прочитать ссылки, GET запрос, взять оттуда циферки (ТИЦ), записать в память, отсортировать, записать в файл, это скучнейшая задача которая практически ничему не учит. Ну кроме вызова функций для прям совсем новичка.
---------- Добавлено 15.10.2017 в 18:11 ----------
Вот это норм, попробую! Большое количество обрабатываемых урлов обещать не могу по причинам ресурсоемкости, но сама идея из разряда вот прям то что я ищу.
Код в студию скиньте, если не стесняетесь.
Подскажите, от куда можно вытащить городские районы?
Ещё можно было вытащить из API VK, как сейчас — не знаю.
Ну вообщем если без миллионов то эксель справиться на раз. Для миллионов нужна хотя бы умение работать с map-reduce а это явно не для человека который только учиться скрипты писать.
При чем тут 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.
Конечно есть. Zabbix, Nagios, Munin, Cacti, Spiceworks. Был ещё где-то софт который мониторит и шлет мыло, как раз пингуя, но не могу найти. Ещё есть всякие пингдомы и хост-треккеры.
Это позволит вывести на карте 1000 маркеров со всей необходимой информацией (кроме координат там есть еще названия фирм, ссылки на карточки фирм)?
Это позволит загрузится странице, как поведет себя карта с 1к маркерами - другой вопрос.