Почему, всё-таки, не SDCH? Есть нативная поддержка в Хроме и форках, включая Яндекс.Браузер, скоро будет поддержка в Safari, активно поддерживается гуглом в своих сервисах; т.е. вам не придётся сражаться с производительностью cliend-side, целостностью, хешами и прочим — всё это уже встроено и тщательно протестировано, и от вас нужно просто сделать словарь и разложить по http сервисам. И, да, кодирование/декодирование в 400мкс — заметно меньше метрик vcdiff.
Я имел ввиду именно то, что сказал, несмотря на мнение сообщества по данному вопросу. Есть а приори запрещённый контент, который тем или иным способом убирается с интернет-ресурсов (хотя обычно не так топорно и открыто, как в эрэфии). Наиболее ярким видом такого контента является child porn, таким же контентом является этот фильм, пропагандирующий ИГИЛ и «терроризм». Отрицать это несколько по-ханжески.
Так устроен мир западного интернета — определённые категории контента там сильно не любят, и за него карают. С этой точки зрения нет принципиальной разницы между этим роликом и child porn.
По сути, заблокировали только фильм Saleel As-Sawarim — пропаганда ИГИЛ. Насколько я понимаю, по делу, которое поддерживает Европа и США — т.ч. тут archive.org стоило бы заблаговременно удалить подобный контент.
Зависит от того, от чего защищаться. От флуда и всяческих переборов паролей эффективно защищаться короткоживущими счётчиками, по ID юзера и по IP (стоит добавить, что в этом случае экспайр заведомо вреден). Для уменьшения нагрузки на базу можно придумывать что-то такое, но в целом это не очень логичное поведение — особо любопытному пользователю, или поисковому краулеру, отдавать какую-нибудь 500-ую ошибку вместо контента. Хотя, конечно, в нормальных языках программирования можно безболезненно задержать такие запросы, чтобы общий рейт запросов в БД был адекватным. Ну и в большем количестве случаев ограничения рейта запросов на уровне nginx достаточно.
Что мешает поставить ещё один (или десять) редисов? Memory footprint у чистого редиса настолько незначительный, что нет никаких проблем поднимать много редисов. Более того, из-за однопоточности редиса это быстро становится необходимым для сохранения стабильно низкого времени ответа, особенно на современных многоядерных серверах.
Мне кажется, эта статья для глупых джуниоров, при этом нет плашки tutorial. Во всех остальных случаях под такую задачу писать LUA скрипт глупо, тогда как настроить редис, чтобы тот автоматически очищал память (maxmemory + maxmemory-policy опции в конфиге) по LRU вместо экспайров, может кто угодно, кто умеет обращаться с редисом. Автор, похоже, не умеет. В крайнем случае, то же самое можно сделать в мемкеше, который точно знают все веб-разработчики.
На мой вкус это не статья уровня хабра/гиктаймс. По сути здесь набор банальностей без малейшего обоснования, ссылок, подробностей, рассказа о внутреннем устройстве, научных открытиях, проблемах и прочем, что мы все любим. По виду это просто пиар своей студии переводов научно-развлекательным видео для школьников.
Мне кажется, вы путаете причину и следствие. Вертикальное масштабирование ограничено на порядки сильнее, нежели горизонтальное, и стоит на порядки дороже. Однако, не все алгоритмы могут адекватно горизонтально масштабироваться. Евангелисты VoltDB утверждают, что в большинстве случаев немасштабируемых транзакций достаточно мало, чтобы их присутствие не убивало производительность кластера.
Про in-memory СУБД вы, мягко говоря, написали нечто странное.
Всё было бы отлично, если бы вы не написали про масштабируемость. В этом аспекте Oracle, очевидно, хуже VoltDB, из-за врождённой неспособности к эффективному шардингу.
Про использование Oracle «всеми», и, как следствие, поддержку — без коммьюнити это не работает.
А быстрее, надёжнее и масштабируемее постгреса и оракла — опенсорсный VoltDB. Вы поймите, оракл — не свет в оконце, а весьма ограниченное решение, имеющее массу проблем с поддержкой. Вспомните, например, как Сбербанк год назад искал специалистов, которые бы смогли разобраться в причинах падения их кластера с ораклом.
Исходно это доклад на Highload 2014, видео и презентация когда-нибудь будут.
Про in-memory СУБД вы, мягко говоря, написали нечто странное.
Про использование Oracle «всеми», и, как следствие, поддержку — без коммьюнити это не работает.