ilionis: ну один из подходов в качестве примера: несколько процессов асинхронно что-то считают и складывают в очередь, а какой-то один процесс мониторит эту очередь и по накоплению подходящей пачки результатов - вываливает эту пачку куда-то, очистив очередь.
Kuzya: когда он обратится в правоохранительные органы, они запросят у него необходимую им информацию. Например договор с провайдером, дату, время и т.п. Из этой информации правоохранители уже смогут получить нужную информацию у провайдера, через СОРМ-2 и т.п.
entermix: ну в реальной жизни бывает приходится хирургическими методами по-живому делать на боевых клиенстких базах... если там в update случайно забыть where - то изменение затронет не один документ, а все сотни тысяч... что по сути эквивалентно убиению базы -))
рефлекс написания сразу текста "update table where" и потом уже всего остального - подстраховывает...
StrVL: по-сути противоречие в "жесткой... для каждого конкретного " и "универсальный инструмент"
Сам термин СУБД подразумевает множественное число (Базами) [разных] баз, а вот некий "язык применения разных алгоритмов поиска" - может оказаться чем-то таким. В какой-то мере под такое даже натянется LINQ -)
xmoonlight: Собственно любыми запросами. Отсюда и вывод, что ресурсу чуть актуальнее странички-заглушки shared-хостинг не подходит. Ибо или придется переплачивать за бОльшее количество ресурсов (полосы, памяти) или жестоко урезать "подозрительную" активность что выплеснет из тазика и ребенка вместе с водой... Например бан поисковиков или же прокси-ускорителей (турбо режимы броузеров) с вытекающими последствиями в виде неиндексирования поисковиками и недоступности ресурса для части вполне добропорядочных пользователей.
Александр: ну проблемы с многоэкземплярностью как таковой я не вижу. Но вот межплагинное взаимодействие - идет несколько вразрез с самой идеей плагинов. Но мой вкус плагины, это все-таки достаточно автономные и закрытые самостоятельные куски, которые если и взаимодействуют, то с "головой", а не "соседями" (о которых они и не должны знать). И взаимодействуют по достаточно узкому шлангу (типа несколько команд и параметров).
xmoonlight: для "заглушки" - это предостаточный хостер, для нагруженных сервисов - используются более другие аренды серверов и collocation -)
А так - какая разница хостеру чем занимается xx% полосы пропускания его канала - жутко полезными пакетами или полной бесполезностью, если часть полосы загружается.
Наверное наиболее понятный пример сотовая связь и тарифы с предоплаченными минутами - опсосу совершенно без разницы то ли абонент 10 минут выяснял что нужного человека нет или за 10 минут провернул сотню сделок с акциями на бирже на 100500 миллардов баксов. В обоих случаях будут тарифицированы 10 минут.
xmoonlight: я никак не считаю. А вот хостер считает процессорное время по учетке клиента и пакеты через интерфейс в сторону клиентского ресурса и обратно.
Соответственно хостер учтет пакеты, на которые клиент даже не соизволит ответить. Со всеми вытекающими.
В итоге школоло-атака: прописываем в броузере "открывать при запуске эти вкладки" - пару десятков страниц атакуемого сайта и открываем... -)
xmoonlight: и в чем будет толк? Если перегруз по тарифному плану возникает при нагрузке на уровне одновременной загрузки десятка вкладок в броузере - то какой смысл навешивать допнагрузку на процессор и "противодействовать" после учетной точки хостера?
В общем случае слегка купировать проблему можно на уровне настройки тарифного плана: многие хостеры предлагают этакие "скрипты" действий в случае превышения нагрузки. Настраиваются эти скрипты в личном кабинете и действия по этим скриптам осуществляются на стороне хостера ДО точки учета клиентских лимитов.
Недостатки и последствия использования таких скриптов - уже озвучивались.
А средства и услуги по противодействию реальным DDoS - как правило стоят тысячи долларов.
xmoonlight: думаю стоит внимательно прочесть договор оферты - там все это расписано подробно. В том числе и про то, что купив велосипед - нефиг ныть о его неспособности перевезти жену и тещу со шкафом на дачу за раз.