Необходимо трекать источник трафика в рамках одной рекламной сети. Многие системы позволяют получать ID или URL площадки-источника в параметрах. Если потери носят технический характер, то он будет приблизительно идентичен для всех источников. Бывают так, что в среднем трафик в сети нормальный, но есть некоторые «активисты» с большим процентом ботовой или ручной накрутки.
Это довольно частое заблуждение, что кластеризация нужна только для обработки большого количества данных. Важно не количество данных, а характер выполняемых с ними операций. То, что ваши 32Гб легко влезают в память, не значит что для любой задачи вы сможете быстро, а в общем случае, вообще, обработать эти данные в памяти, или, даже, в рамках всех, включая дисковые, ресурсов одной ноды. Ваши «маленькие» данные могут легко породить декартово произведение фантастических размеров. Например, ваши 32Гб это логи посещений вашего ресурса, а получить вам нужно, скажем, список уникальных IP адресов никогда не загружавших одинаковые страницы в интервале 5 минут ))
Первое правило кластеростроения — тестировать производительность любого кластерного решения только на рельном физическом кластере. Никакие однонодовые инсталляции и всякие виртуализации в рамках одной ноды никогда не дадут вам реальных результатов. Вы не получите производительности больше, чем ее есть у вас физически, при этом, не кластерные продукты в рамках одной ноды, однозначно выиграют, т.к. утилизируют эту производительность эффективнее.
1. Эффективность распознавания даже простых версий капчи сильно далека от 100%. Про сложные/нестандартные варианты даже и не говорим.
2. Сложность реализации алгоритмов распознавания капчи значительно выше чем простого брутфорсера перебирающего логины/пароли по словарю или схеме.
3. Задача распознавания капчи достаточно ресурсоемка, т.е. под это требуются либо дополнительные, иногда, весьма существенные вычислительные мощности, либо скорость перебора сильно падает.
В общем, все три фактора делают брутфорс малоэффективным. Проще бросить и поискать другую жертву или другую уязвимость, чем ломать форму с капчей брутфорсом.
Настоящая риалтаймовость для write intensive задач недостижима без кэширования и предагрегации. Фактически, описанное решение, это интеллектуальная инвалидация кэша промежуточных результатов MapReduce задачи при поступлении новых данных. Сам же MapReduce никто не отменял, хотя бы и по кэшу плюс изменения. Так что, глобально, это туда же, куда и Impala.
В этом нет ничего удивительного — многие крупные высоконагруженные проекты используют именно этот набор инструментов. Вообще, шардинг решает большую часть проблем с нагрузками этого типа, а уж чем его делать и что использовать в качестве бэкенда для хранения — неважно, почему-бы и не MySQL.
Сложности начинаются, если у вас есть data intensive задачи, требующие выборки по многим шардам, и данные при этом плохо или совсем не агрегируемые. Здесь придется писать тонны логики, реализующей распределенные запросы. Второй неприятный случай, если вы хотите повысить время ответа, при том что у вас в рамках шарды уже минимально допустимое количество данных (которых на самом деле может быть очень много), необходимых для ответа, и дальше эти данные уже не режутся. Например один очень-очень активный пользователь, генерящий половину всех запросов/данных.
Dropbox — сервис массовый, рассчитанный на пользователей Word-а и Excel-я. Процент тех, из них, кто может сам поднять VPS и настроить удаленный бекап, ничтожно мал. К тому же, если вдруг каждый захочет завести себе для хранения 10Гб свою собственную виртуалку, которая инфраструктурно значительно сложнее аккаунта на Dropboxe, цена на VPS-ы резко изменится ;)
2. Сложность реализации алгоритмов распознавания капчи значительно выше чем простого брутфорсера перебирающего логины/пароли по словарю или схеме.
3. Задача распознавания капчи достаточно ресурсоемка, т.е. под это требуются либо дополнительные, иногда, весьма существенные вычислительные мощности, либо скорость перебора сильно падает.
В общем, все три фактора делают брутфорс малоэффективным. Проще бросить и поискать другую жертву или другую уязвимость, чем ломать форму с капчей брутфорсом.
Сложности начинаются, если у вас есть data intensive задачи, требующие выборки по многим шардам, и данные при этом плохо или совсем не агрегируемые. Здесь придется писать тонны логики, реализующей распределенные запросы. Второй неприятный случай, если вы хотите повысить время ответа, при том что у вас в рамках шарды уже минимально допустимое количество данных (которых на самом деле может быть очень много), необходимых для ответа, и дальше эти данные уже не режутся. Например один очень-очень активный пользователь, генерящий половину всех запросов/данных.
www.nokia.com/about-nokia/research/demos/the-morph-concept/video