Size: a a a

Архитектура ИТ-решений

2021 February 06

AM

Alexey Mergasov in Архитектура ИТ-решений
На несколько недель))))
источник

N

Nikolay in Архитектура ИТ-решений
А мне вот это вопрос интересен. Особенно за что можно торговать перфоманс
источник

A

Alex in Архитектура ИТ-решений
Nikolay
А мне вот это вопрос интересен. Особенно за что можно торговать перфоманс
Лучше им вообще не торговать.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Против прозводительности вообще всё. Потому что реализация любого аспекта нагружает решение. Нужно искать баланс. Это же интересно, настоящая инженерная работа.
источник

N

Nikolay in Архитектура ИТ-решений
Можно ещё лэтэнси vs сроупут
источник

N

Nikolay in Архитектура ИТ-решений
Тут как раз статья недавно бала на эту теме в кафке. Или большой сроупут или минимальное лэтэнси. Всегда выбор
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Nikolay
Можно ещё лэтэнси vs сроупут
Нет конечно. Может быть широкая полоса с большой задержкой
источник

N

Nikolay in Архитектура ИТ-решений
Gennadiy Kruglov
Нет конечно. Может быть широкая полоса с большой задержкой
Вопрос в том, что нет большого сроупут и минимального лэтэнси.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Nikolay
Тут как раз статья недавно бала на эту теме в кафке. Или большой сроупут или минимальное лэтэнси. Всегда выбор
Зависит от системы
источник

N

Nikolay in Архитектура ИТ-решений
Gennadiy Kruglov
Зависит от системы
В кафке так. А где не так ?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Nikolay
Вопрос в том, что нет большого сроупут и минимального лэтэнси.
При прямой коммутации в маршрутизаторах
источник

N

Nikolay in Архитектура ИТ-решений
В базах так же. Или oltp где доступ по ключу или olap, где много читаем , но лэтэнси большой
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Nikolay
В базах так же. Или oltp где доступ по ключу или olap, где много читаем , но лэтэнси большой
При чём здесь пропускная способность? Конечно, чем тяжелее запросы, чем дольше ждать
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Иван
Это как-то жирно для чатика. Тут можно любой с любым сопоставить и накидать говна на вентилятор на несколько часов балобольства
Надежность против доступности. Кидайте :)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Если вычитывать данные из Kafka в ЦОД на другом континенте, то полоса вряд-ли изменится, а задержка увеличится существенно.

Прямой зависимости нет, поэтому "в лоб" противоставлять малополезно.
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Есть просто прям очевидные типо безопасность vs  удобство импользования. Но вот навскидку много пар не придумал
источник

AM

Artem Mitropolskiy in Архитектура ИТ-решений
Есть тройки типо cap-теоремы
источник

И

Иван in Архитектура ИТ-решений
Artem Mitropolskiy
Надежность против доступности. Кидайте :)
Без контекста не имеет смысла
источник

N

Nikolay in Архитектура ИТ-решений
Gennadiy Kruglov
Если вычитывать данные из Kafka в ЦОД на другом континенте, то полоса вряд-ли изменится, а задержка увеличится существенно.

Прямой зависимости нет, поэтому "в лоб" противоставлять малополезно.
если вычитывать с другого контитента это как раз сразу видно. вот есть ситуация. мессадж M1 записывается в кафку. у того кто на другом контитенте ... есть 2 опции. или получать сообщения через x миллисекунд или через условные y миллисекунд . причем x << y. он в минуту может почить в сумме X или Y. Причем X << Y. это в основном вопрос батчинга и сжатия
источник

N

Nikolay in Архитектура ИТ-решений
ну самый известный торг - это доступность vs консистентность
источник