точнее может позволить кэшировать информацию о лайках в памяти прилы

а если разделять еще и приложение? тогда уже толкьо в базе хранить

и при текущих потребностях она всё ок сделала

Бизнес так не работает

как мне кажется бизнес работает именно так

и еще составила структуру так, что она легко поддается модификацией для других нужд

как мне кажется бизнес работает именно так

Нет

Нет

ну хз, сколько работаю всегда хотят быстро и пофиг на остальное, "потом если что перепишешь"

и плевать что потом время на это тоже тратить

ну хз, сколько работаю всегда хотят быстро и пофиг на остальное, "потом если что перепишешь"

Бред

а если разделять еще и приложение? тогда уже толкьо в базе хранить

при измении таблицы она делает запрос в базу и обновляет кэш

а при проверке она использует только кэш памяти

ей не надо делать лишние селект запросы

а при проверке она использует только кэш памяти

Ты уверен?

при измении таблицы она делает запрос в базу и обновляет кэш

так если приложений для чата будет сразу два запущено?

если да кабы

так если приложений для чата будет сразу два запущено?

и дальше уже просто через nginx будет roundrobin?

она тогда чуть-чуть перепишет свой код под новые потребности

а пока я согласен с ней

не нравится

гоу покажите свои реализации

как это надо делать лучше

и мутите баттлы на бенчмарках

а пока вы обсуждаете абстрактные вещи

с которыми Настя еще не столкнулась и вряд ли столкнется

)))

а пока я согласен с ней

+10 hp to Славик

с которыми Настя еще не столкнулась и вряд ли столкнется

Ок

Лучше написать обыкновенно helloworld через iostream, чем пилить это эффективно через getchar_unlocked, если задача того не требует

вот же накинулись, я просто спросил реализацию и почему так

Уж что лучше, всегда getchar/putchar_unlocked аль даже fread, или же просто и понятно через iostream?

Реализация к месту, вопросов нет)

кстати, даже вк хранит лайки json'ом

кстати, даже вк хранит лайки json'ом

Если память не изменяет, то они еще и в мускуле это делат

Уж что лучше, всегда getchar/putchar_unlocked аль даже fread, или же просто и понятно через iostream?

Пока производительность не важна, эффективно писать и не требуется

+5 hp to Nastassia

красава

Пока производительность не важна, эффективно писать и не требуется

Ошибаешься

Пока производительность не важна, эффективно писать и не требуется

тут уже заход на территорию "не требуется, но стоило бы". сложно и философия

вот это был хороший вброс =) за Настиным решением стоит даже анализ исходников существующих высоконагруженных приложений

пойду подрочу

Ошибаешься

Радость моя, тормози философскую беседу, правда. Политика уместности и достаточности здесь более чем применима

Тут выбор между ясностью кода и его эффективностью

пойду подрочу

??

отличный план

пойду подрочу

+1 hp to Славик

ок, лучше эти 12 млн перетащить по сети в json?)

проверка происходит на стороне сервера

загрузить их в память оперативную

Лан признаю

Вы супер

а если база и клиент на разных машинах сидячт?

12млн весит вся таблица

к слову

а если база и клиент на разных машинах сидячт?

Ой все

не у одного поста будет 12млн лайков

а у миллиона постов в сумме

а если база и клиент на разных машинах сидячт?

А давай без если: в параллельных вселенных и вовсе по-другому может быть, нужна мера

не у одного поста будет 12млн лайков

ок, у одног поста 5к лайков, иды пользоватеклей надо будет таскать за собой?

А давай без если: в параллельных вселенных и вовсе по-другому может быть, нужна мера

да без проблем, но я пытаюсь понять как оно будет лучше в боевой ситуации с норм нагрузкой

в том же ВК например

юзер хочет поставить лайк, идет запрос на сервер, сервер с базы или внутренного кэша тащит инфу о конкретной посте, парсит айдишки и быстро сверяет был ли такой лайк или нет

ок, у одног поста 5к лайков, иды пользоватеклей надо будет таскать за собой?

да

или хранить в оперативной памяти

можно хранить в качестве кэша мапу

и будет сложность O(1) для проверки айдишки

что мешает сделать выборку по этим 12 лямам записей и попросить вернуть строку с юзверем если она там есть? реально долгая операция?

ERROR: S client not available

или хранить в оперативной памяти

Холодный старт будет жуткий

на хабре вроде есть статья, как заводятся одноклассники после масштабного падения

когда там у них слег датацентр или все

это норма

на хабре вроде есть статья, как заводятся одноклассники после масштабного падения

Снимок фактический

такие высоконагруженные проекты падают полностью крайне редко и это считается глобальной аварией

м маил ру

кэш в оперативной памяти будет пополняться по мере поступления к нему запросов

такие высоконагруженные проекты падают полностью крайне редко и это считается глобальной аварией

Масдай часто падает

Перед сном ужастики рассказываете.

не при инициализации прилы

Не надо так...

тут товаришь из соседнего чата рассказывал как у них спецы настраивают виртуализацию...

юзер решил поставить лайк, тогда запрос в базу и сохранение в кэше

юзер решил поставить лайк, тогда запрос в базу и сохранение в кэше

да, но это при условии что приложение монолит и оно одно, так?

если же запущен еще один инстант этого приложения то кешу мы доверять не можем, так?

как у него бухгалтерия вышла в ceph... и не вернулась.

Я у себя пик поймал в декабре 5 слишним тысяч в сек запрос к базе

Не когда бы подумать не мог

Но факт

если же запущен еще один инстант этого приложения то кешу мы доверять не можем, так?

смотря как кеш реализован

База справлялась

может он у тебя в разделяемой памяти, или в мемкеше, что пофиг, или еще где

Тормозов небыло

может он у тебя в разделяемой памяти, или в мемкеше, что пофиг, или еще где

Нет

почему нет?

в любом случае чтобы кеш был общий, его нужно выносить

Mysql inodb + транзакции

Жуть

зачем бд напрягать.?

зачем бд напрягать.?

Да норм вроде