Хороший, плохой и злой… кэш
[embedded content]Довольно интересное видео (на английском, к сожалению), в котором девушка, на примере соцсетей, рассказывает о плюсах и минусах кэширования в web-приложениях.
Наиболее содержательными являются первые две трети ролика, которые можно суммировать следующим образом:
1) данных в соцсетях нынче много, обновляются они часто, а пользователю их нужно предоставлять быстро2) поэтому без кэширования не обойтись3) далее показывается, как кэширование (концептуально) работает в Twitter, Facebook и Reddit4), но есть проблемка…5) кэширование в каждом соцсетевом проекте отписывается вручную6) в результате, имеем много кода, который делает практически одно и то же в каждом проекте. А много кода — это много багов и людского труда7) и что же с этим делать?
8) использовать базы данных! Типа SQL. Пользователи в соцсетях работают с тайм-лайнами, а каждый такой тайм-лайн на языке БД выражается простым запросом9) результат такого запроса — это табличка, которая кэшируется самой БД и автоматически обновляется, по мере обновления базовых таблиц, на основе которых она была посчитана10), но тут опять проблема…11) современные реализации БД не настолько умны, чтобы их можно было использовать в том виде, в котором они предлагаются12) они централизованны, их невозможно обучить семантике приложения, нельзя подружить с клиентским кэшем и… следующий недостаток мне особенно понравился. Я его даже выделю в отдельный пункт13) академическая наука давно уже все решила, а вот разработчики БД почему-то тупят и отстают от прогрессивного человечества на три десятка лет (формулировка вольная, но я не могу просто пройти мимо этого довольно наивного, на мой взгляд, суждения)
Оставшаяся часть видео мне показалась довольно мутной. Девушка рассказывает, что нужно делать с БД, чтобы все «полетело». К сожалению, никакой конкретики она не предлагает, поэтому я даже не знаю, что можно здесь об этой части ролика написать. Так что см. видео. Однако, если в двух словах, то:
14) мир спасут «толстые» клиенты (которые должны «нести» на себе значительную часть приложения) и15) кэширование на стороне клиента, согласованное с кэшированием на стороне сервера
В общем, ответ на «главный вопрос жизни, вселенной и всего такого», как всегда ускользнул. Самая интересная часть разговора оказалась бессодержательной. Тем не менее, я все равно рекомендую видео, т.к. постановка проблемы дана довольно четко.
Если все же пообсуждать, то довольно нетривиальным может показаться предложение использовать «толстых» клиентов. Это то, чего очень хотелось бы, например, фирме Intel, которая явно была бы не прочь в каждый компьютер снова поставить высокопроизводительный процессор общего назначения. Тем не менее, мир пока что движется в противоположном направлении. Что будет в будущем, сказать сложно. Возможно, действительно найдутся какие-нибудь killer-приложения, которые заставят всех нас снова купить «утюги». Кто знает…
Про SQL везде — идея заманчивая и многих волнует. Возможно, что именно в соцсетях, после некоторых доработок, она и приживется. Все-таки, как ни крути, соцсетевые запросы к БД — штука относительно простая. Разнообразие запросов невелико, и они не очень сложны. Поэтому, на мой взгляд, можно даже позволить себе не использовать никаких БД, а писать все вручную (как, собственно, сейчас и делается). Т.е. те самые «много кода», на которые сетует девушка, — это, как мне кажется, совсем не те «супермного кода», которые пришлось бы писать для оптимальной работы систем, обрабатывающих сотни или тысячи разнородных запросов. Вот тут, как раз, использовать готовую БД затруднительно. Оптимизировать ее под какой-то класс запросов можно, но запросы из другого класса будут постоянно идти мимо кэшей или, чего доброго, вообще разваливать кэши. Видимо, на это автор доклада ответила бы, что хочет еще и «поженить» БД с семантикой приложений. Но она не говорит, как это сделать, так что и обсуждать тут пока нечего…
Вот, вроде, и все…
А нет, не все! :)
Девушка упомянула несколько фреймворков на Java Script, предназначенных для обновления и синхронизации кэшей. Я с ними не знаком. Однако предполагаю, что они должны делать вычислительно емкую работу, если конечно, рассчитаны на широкое применение. В связи с чем, не могу не подметить настораживающую меня тенденцию: все больше вычислительно нагруженных приложений пишется на Java, Java Script, HTML5, Ruby, Python, Perl, …
Никого это не пугает?
