В статье приводятся говорится про создание искуственного дисбаланса и в качестве пруфов приводится то что… сервисы знакомств не борятся с дисбалансом. Это следствие а не причина.
В статье говорится что есть другое мнение про закон паретто и оно не верное, но не приводится пруфов этому.
Никаких подтверждений точки зрения, описанной в статье, нет.
Суть этих контраргументов заключается в том, что вам не следует заморачиваться по поводу того, что в приложениях для знакомств много несовпадений. Ведь «80% женщин выбирают 20% лучших мужчин»
Вот эти «контраргументы» и есть правда. Это 20% мужчин встречаются с 80% процентами женщин в силу своей полигамности. Остальные женщины не хотят встречаться с остальными 80% мужчинами, т.к. в их глазах они третий сорт и природа — против.
Отличие настоящего мира от сайта знакомств очень простое — географический фактор. Женщины видят только мужчин, которые рядом. Если бы они посмотрели на этих же мужчин на фоне лучших мужчин всего мира, то не стали бы с ними встречаться. А так, когда они видят только тех, кто рядом, то они очень даже ничего.
Так что сайты которые выдают не всех кандидатов, а выдают их какими-либо порциями (эмилируя географические ограничения реального мира), лишены описываемой проблемы.
Всё в порядке. Ты принят в agile. Только могут быть проблема со scrum, т.к. они больше продуктово-оринетированы. Пиши хороший код в канбан команде.
Agile — это про организацию всей компании, это не про scrum.
Вот именно, суть этого просто в том что никто не может написать хороший проект, если у него нет внутренней мотивации это сделать и единственная его мотивация тупо получить деньги и всё.
Ты пилишь проект и твоя мотивация — успех проекта, ты вовлечён. Если твоя цель отсидеть от звонка до звонка и делать такой минимум чтобы тебя не уволили, а на всё остальное пофиг, то действительно с тобой не по пути. Даже если ты хорошо пишешь хороший код (допустим за плохой увольняют, так что ты пишешь хороший).
Ага, у вас какой-то более другой кейс пайплайнинга, чем в языках, где взаимодействие разных потоков не так легко достигается.
В них обычно условие для пайплайнинга — есть N команд, но на первые N-1 ответ не нужен срочно. А нужен только в конце.
Т.е. вот 4 команды SET X 1
SET Y 2
GET W
GET Z
и нам ответ нужен только в конце — это W и Z. Нам не нужен W до этого момента и тем более результаты установки X, Y. В этом случае пайплайнинг позволяет послать 4 команды, а потом ждать ответа.
У вас же такого нет, просто из разных процессов всё идёт через один сокет. И в клиенте у вас конкурентность и на redis-server. А могло бы всё идти по разным сокетам и без конкурентности… В чём профит, непонятно. Разве что какие-то внутренние проблемы редиса с
большим кол-вом сокетов.
Да потому что на 48 шардов очень плохо работает пайплайнинг запросов. А он экономит цпу как на клиенте, так и в самом редисе
Т.е. 8 клиентов на 8 редис процессов могли бы идти по 8 сокетам. Все на разных ядрах.
А у вас 8 клиентов идут на 8 редис тредов через 1 сокет все в перемешку.
И профит в том что и клиент и сервер жрут меньше CPU. Непонятно…
сессии юзеров, фоновые задачи, csrf токены, межсервисные локи, различные другие токены, коды подтвеждений sms — всё отлично там хранится.
у редиса два механизма записи на диск — снапшоты и AOF. не вижу повода не хранить там даже важные данные.
> что они называют транзакциями, и Lua процедуры. Но на практике этим пользуются невероятно редко
Ну как так «невероятно редко». У нас например невероятно часто. Это же зависит от кейса — если кэш, то они не нужны. Если хранение данных, то нужны «часто».
Про пайплайнинг замечание здравое. Но что-то у меня сомнения что KeyDB с оверхедом от многопоточности будет быстрее чем редис с оверхедом от отсутствия пайплайнинга. Или будет?
И что за кейс где нужен пайплайнинг — это же не кэширование?
разработчики Redis упорно не хотят внедрять полноценную параллельность, упоминая, насколько это усложнит приложение и повысит накладные расходы
Ну вы наверное упорно не понимаете философию редис. Обвинять редис в том что он однопоточный, это всё равно что обвинять Си, в том что он компилируемый, Go в том что статически типизированный, а mysql в том что таблицы нужно декларировать, прежде чем использовать.
У одного из проектов мы столкнулись с тем, что команда разработки настроила крайне агрессивное кэширование данных из БД (PostgreSQL) через Redis
Могли бы запустить по одному редису на каждое ядро. При кэшировании, по ключу кэша, вычислять (например взять последние 3 бита от md5 ключа) в каком из редисов это будет храниться. Тогда бы ваша система выполняла свои функции вообще без межпроцессного/межпотокового взаимодействия, что было бы быстрее. Но вы взяли другой инструмент и теперь ваша система синхронизируется между потоками и переключает контекст там, где это не нужно.
спиртовые салфетки. только не в аптеке, а в интернет магазинах, в больших коробках. дешевле в разы, чем в аптеках. можно легко купить тысячи штук.
у меня например есть спирт, но я пользуюсь спиртовыми салфетками для бытовых целей (обезжирить что-то), потому что это тупо удобнее чем искать тряпочку, потом её пропитывать спиртом.
Здорово!
Что останавливает меня от использования этого? То что я всё равно не буду вырывать листы из блочной тетради и нумеровать их.
И да, соглашусь с комментом что «Перелистывание страницы вправо» следовало бы назвать «Перелистывание страницы влево», потому что и рука и страница двигается налево.
логика так себе
1) если обновления есть и юзер квалифицировн, то антивирус не нужен. если обновлений нет, то антивирус помогает, но в общем случае битва проиграна, если на компьютере уязвимости. т.к. антивирус ловит не всё.
2) если компьютер скомпрометирован, проблема тут не в бэкапах. например могут воспользоваться вашими аккаунтами
Переустановить систему с сохранением всех данных и с переустановкой и настройкой всех программ, с решением проблем устаревшего оборудования (включая замену), для сколько стоит?
Если апгрейд win7 на win10 — то ради бога, но нужно принять риск что закончится полной переустановкой.
Это всё если юзер не компьютерщик, частный пользователь, тем не менее компьютер ему нужен.
если запускать что попало, то и обновления не помогут.
после окончания поддержки будут появляться новые и новые дыры, механизм эксплуатации которых будет самый разнообразный. может появиться что угодно — эксплоиты в изображениях, документах, входящих tcp пакетах.
А за что там платить 5 тыс и в чём там может быть отличие нормальных систем от плохих? Это же просто плазма крови сделанная в центрифуге. Либо она прозрачная, либо не очень. Что ещё может быть с ней не так?
Я так понимаю из-за хайпа оно стоило 10 тыс за укол N лет назад, потом цены упали до плюс-минус 1 тысячи…
В статье говорится что есть другое мнение про закон паретто и оно не верное, но не приводится пруфов этому.
Никаких подтверждений точки зрения, описанной в статье, нет.
Вот эти «контраргументы» и есть правда. Это 20% мужчин встречаются с 80% процентами женщин в силу своей полигамности. Остальные женщины не хотят встречаться с остальными 80% мужчинами, т.к. в их глазах они третий сорт и природа — против.
Отличие настоящего мира от сайта знакомств очень простое — географический фактор. Женщины видят только мужчин, которые рядом. Если бы они посмотрели на этих же мужчин на фоне лучших мужчин всего мира, то не стали бы с ними встречаться. А так, когда они видят только тех, кто рядом, то они очень даже ничего.
Так что сайты которые выдают не всех кандидатов, а выдают их какими-либо порциями (эмилируя географические ограничения реального мира), лишены описываемой проблемы.
Agile — это про организацию всей компании, это не про scrum.
В них обычно условие для пайплайнинга — есть N команд, но на первые N-1 ответ не нужен срочно. А нужен только в конце.
Т.е. вот 4 команды
SET X 1
SET Y 2
GET W
GET Z
и нам ответ нужен только в конце — это W и Z. Нам не нужен W до этого момента и тем более результаты установки X, Y. В этом случае пайплайнинг позволяет послать 4 команды, а потом ждать ответа.
У вас же такого нет, просто из разных процессов всё идёт через один сокет. И в клиенте у вас конкурентность и на redis-server. А могло бы всё идти по разным сокетам и без конкурентности… В чём профит, непонятно. Разве что какие-то внутренние проблемы редиса с
большим кол-вом сокетов.
Т.е. 8 клиентов на 8 редис процессов могли бы идти по 8 сокетам. Все на разных ядрах.
А у вас 8 клиентов идут на 8 редис тредов через 1 сокет все в перемешку.
И профит в том что и клиент и сервер жрут меньше CPU. Непонятно…
у редиса два механизма записи на диск — снапшоты и AOF. не вижу повода не хранить там даже важные данные.
Ну как так «невероятно редко». У нас например невероятно часто. Это же зависит от кейса — если кэш, то они не нужны. Если хранение данных, то нужны «часто».
И что за кейс где нужен пайплайнинг — это же не кэширование?
Ну вы наверное упорно не понимаете философию редис. Обвинять редис в том что он однопоточный, это всё равно что обвинять Си, в том что он компилируемый, Go в том что статически типизированный, а mysql в том что таблицы нужно декларировать, прежде чем использовать.
Могли бы запустить по одному редису на каждое ядро. При кэшировании, по ключу кэша, вычислять (например взять последние 3 бита от md5 ключа) в каком из редисов это будет храниться. Тогда бы ваша система выполняла свои функции вообще без межпроцессного/межпотокового взаимодействия, что было бы быстрее. Но вы взяли другой инструмент и теперь ваша система синхронизируется между потоками и переключает контекст там, где это не нужно.
у меня например есть спирт, но я пользуюсь спиртовыми салфетками для бытовых целей (обезжирить что-то), потому что это тупо удобнее чем искать тряпочку, потом её пропитывать спиртом.
Что останавливает меня от использования этого? То что я всё равно не буду вырывать листы из блочной тетради и нумеровать их.
И да, соглашусь с комментом что «Перелистывание страницы вправо» следовало бы назвать «Перелистывание страницы влево», потому что и рука и страница двигается налево.
1) если обновления есть и юзер квалифицировн, то антивирус не нужен. если обновлений нет, то антивирус помогает, но в общем случае битва проиграна, если на компьютере уязвимости. т.к. антивирус ловит не всё.
2) если компьютер скомпрометирован, проблема тут не в бэкапах. например могут воспользоваться вашими аккаунтами
Если апгрейд win7 на win10 — то ради бога, но нужно принять риск что закончится полной переустановкой.
Это всё если юзер не компьютерщик, частный пользователь, тем не менее компьютер ему нужен.
после окончания поддержки будут появляться новые и новые дыры, механизм эксплуатации которых будет самый разнообразный. может появиться что угодно — эксплоиты в изображениях, документах, входящих tcp пакетах.
Это не сарказм. Правда интересно.
Я так понимаю из-за хайпа оно стоило 10 тыс за укол N лет назад, потом цены упали до плюс-минус 1 тысячи…