Досить цікаве відео (англійською, на жаль), в якому дівчина, на прикладі соцмереж, розповідає про плюси і мінуси кешування в web-додатках.
Найбільш змістовними є перші дві третини ролика, які можна підсумувати наступним чином:
1) даних у соцмережах нині багато, оновлюються вони часто, а користувачеві їх потрібно надавати швидко
2) тому без кешування не обійтися
3) далі показується, як кешування (концептуально) працює в Twitter, Facebook і Reddit
4) але є проблемка...
5) кешування в кожному соцмережевому проекті відписується вручну
6) в результаті, маємо багато коду, який робить практично одне і те ж у кожному проекті. А багато коду - це багато багів і людської праці
7) і що ж з цим робити?
8) використовувати бази даних! Типу SQL. Користувачі в соцмережах працюють з тайм-лайнами, а кожен такий тайм-лайн мовою БД виражається простим запитом
9) результат такого запиту - це табличка, яка кешується самою БД і автоматично оновлюється, у міру оновлення базових таблиць, на основі яких вона була порахована
10) але тут знову проблема...
11) сучасні реалізації БД не настільки розумні, щоб їх можна було використовувати в тому вигляді, в якому вони пропонуються
12) вони централізовані, їх неможливо навчити семантики програми, не можна подружити з клієнтським кешем і... наступний недолік мені особливо сподобався. Я його навіть виділю в окремий пункт
13) академічна наука давно вже все вирішила, а ось розробники БД чомусь туплять і відстають від прогресивного людства на три десятки років (формулювання вільне, але я не можу просто пройти повз цього досить наївного, на мій погляд, судження)
Частина відео мені здалася досить каламутною. Дівчина розповідає, що потрібно робити з БД, щоб все «полетіло». На жаль, ніякої конкретики вона не пропонує, тому я навіть не знаю, що можна тут про цю частину ролика написати. Так що див. відео. Однак, якщо в двох словах, то:
14) світ врятують «товсті» клієнти (які повинні «нести» на собі значну частину програми) і
15) кешування на боці клієнта, узгоджене з кешуванням на боці сервера
Загалом, відповідь на "головне питання життя, всесвіту і всього такого" ", як завжди вислизнула. Найцікавіша частина розмови виявилася беззмістовною. Тим не менш, я все одно рекомендую відео, оскільки постановка проблеми дана досить чітко і наочно. До того ж дівчата в IT - це прекрасно. Всіляко треба вітати.
Якщо все ж пообсуждать, то досить нетривіальним може здатися пропозиція використовувати «товстих» клієнтів. Це те, чого дуже хотілося б, наприклад, фірмі Intel, яка явно була б не проти в кожен комп'ютер знову поставити високопродуктивний процесор загального призначення. Тим не менш, світ поки що рухається в протилежному напрямку. Що буде в майбутньому, сказати складно. Можливо, дійсно знайдуться якісь killer-додатки, які змусять всіх нас знову купити «праски». Хто знає...
Про SQL скрізь - ідея приваблива і багатьох хвилює. Можливо, що саме в соцмережах, після деяких доробок, вона і приживеться. Все-таки, як не крути, соцмережеві запити до БД - штука відносно проста. Різноманітність запитів невелика, і вони не дуже складні. Тому, на мій погляд, можна навіть дозволити собі не використовувати ніяких БД, а писати все вручну (як, власне, зараз і робиться). Тобто. ті самі «багато коду», на які нарікає дівчина, - це, як мені здається, зовсім не ті «супермного коду», які довелося б писати для оптимальної роботи систем, що обробляють сотні або тисячі різнорідних запитів. Ось тут, якраз, використовувати готову БД важко. Оптимізувати її під якийсь клас запитів можна, але запити з іншого класу будуть постійно йти повз кешів або, чого доброго, взагалі розвалювати кеші. Мабуть, на це автор доповіді відповіла б, що хоче ще й «одружити» БД із семантикою додатків. Але вона не говорить, як це зробити, так що і обговорювати тут поки нічого...
Ось, начебто, і все...
UPD: стаття присвячена пробемам кешування. Тому прибрав міркування на тему Java Script (чомусь саме вони привернули увагу всіх, хто відписався). Не люблю холівари...
