Size: a a a

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

2020 October 10

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Парадайс))
источник

IA

Igor A in Архитектура ИТ-решений
Alexey Pryanishnikov
Какая из команд? Есть 400 систем в конторе, в решении задействовано 150. Какая из команд и что там должна придумать?
Ок согласен.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Igor A
Это банк?
Какая разница. Общее направление должен кто-то задать. Сказать менеджменту стоимость решения.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Igor A
Ок согласен.
С другой стороны, выдав список доработок по каждой системе, солюшена вообще не заботит, кто там, как и что кодит
источник

N

Nikolay in Архитектура ИТ-решений
Сейчас читаю Клеппмана . Он в главе про репликацию в распределенных  системах баз данных без лидера рассматривает вопрос разрешения конфликтов записи  на основе оптимистических блокировок только .  Это выглядит странным. Ни одна знакомая реляционная база не использует такой подзод при записи/изменении . Все делают на основании locks? Ну да , в распределенных системах lock дорогой, но иначе это же не про консистентность? Неужели lock в распределенных системах настолько дорого ? Ну я в mongo не очень, но ведь в монго на основе локов?
источник

IA

Igor A in Архитектура ИТ-решений
Alexey Pryanishnikov
С другой стороны, выдав список доработок по каждой системе, солюшена вообще не заботит, кто там, как и что кодит
Я с такими решениями не сталкивался.
Обычно решееия ее требуют 150 систем) космос какойто.
Но видимо вы там давно сидите.
Интересно как вам удается аргументировать повышение зп.
Ведь раз в 3 года вы беднеете на 25% примерно
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Igor A
Я с такими решениями не сталкивался.
Обычно решееия ее требуют 150 систем) космос какойто.
Но видимо вы там давно сидите.
Интересно как вам удается аргументировать повышение зп.
Ведь раз в 3 года вы беднеете на 25% примерно
Контору меняешь )
источник

D

Danil in Архитектура ИТ-решений
Nikolay
Сейчас читаю Клеппмана . Он в главе про репликацию в распределенных  системах баз данных без лидера рассматривает вопрос разрешения конфликтов записи  на основе оптимистических блокировок только .  Это выглядит странным. Ни одна знакомая реляционная база не использует такой подзод при записи/изменении . Все делают на основании locks? Ну да , в распределенных системах lock дорогой, но иначе это же не про консистентность? Неужели lock в распределенных системах настолько дорого ? Ну я в mongo не очень, но ведь в монго на основе локов?
Ну DynamoDB, которая самая известная из таких СУБД, она eventually-consistent, да. Он в той же главе вроде много об этом пишет
источник

IA

Igor A in Архитектура ИТ-решений
Обычно надо пяток микросервисов понять влкруг и все
Такого чтобы понимать все это ж bad design.
источник

IA

Igor A in Архитектура ИТ-решений
Фича на 150систем - я бы подумал зачем так жить...
источник

Si

Sergey iscremas in Архитектура ИТ-решений
Nikolay
Сейчас читаю Клеппмана . Он в главе про репликацию в распределенных  системах баз данных без лидера рассматривает вопрос разрешения конфликтов записи  на основе оптимистических блокировок только .  Это выглядит странным. Ни одна знакомая реляционная база не использует такой подзод при записи/изменении . Все делают на основании locks? Ну да , в распределенных системах lock дорогой, но иначе это же не про консистентность? Неужели lock в распределенных системах настолько дорого ? Ну я в mongo не очень, но ведь в монго на основе локов?
Блокировки - это уже не про доступность
источник

N

Nikolay in Архитектура ИТ-решений
Danil
Ну DynamoDB, которая самая известная из таких СУБД, она eventually-consistent, да. Он в той же главе вроде много об этом пишет
без локов можно рассчитывать только на eventually consistent?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Igor A
Фича на 150систем - я бы подумал зачем так жить...
Не фича, а продукт
источник

IA

Igor A in Архитектура ИТ-решений
Alexey Pryanishnikov
Контору меняешь )
Ну вот и получили срок 3года
За этот срок вы ничего не поменяете и не улучшите 😈
Кодовую базу даже не поймете.
источник

D

Danil in Архитектура ИТ-решений
Nikolay
без локов можно рассчитывать только на eventually consistent?
ну а какие локи могут быть, если мы не знаем (не хотим знать), сколько серверов у нас вообще живых в момент записи
источник

N

Nikolay in Архитектура ИТ-решений
Sergey iscremas
Блокировки - это уже не про доступность
Почему ? Доступность - это когда система ответит что-то, ведь так ?
источник

N

Nikolay in Архитектура ИТ-решений
Danil
ну а какие локи могут быть, если мы не знаем (не хотим знать), сколько серверов у нас вообще живых в момент записи
Мы хотим. У нас же есть число нод -w,  которое должно подтвердить запись. Мы ждём их. Мы могли бы сначала ждать лок на w нодах
источник

D

Danil in Архитектура ИТ-решений
"When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. However, this consistency comes with some disadvantages:
   A strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500).
   Strongly consistent reads may have higher latency than eventually consistent reads.
"
источник

Si

Sergey iscremas in Архитектура ИТ-решений
Nikolay
Почему ? Доступность - это когда система ответит что-то, ведь так ?
Если есть необходимость в локах, то мы должны обеспечить одновременное присутствие всех реплик. Иначе никак. Это это уже не высокая доступность
источник

N

Nikolay in Архитектура ИТ-решений
Sergey iscremas
Если есть необходимость в локах, то мы должны обеспечить одновременное присутствие всех реплик. Иначе никак. Это это уже не высокая доступность
Не обязательно ведь всех , а только кворума ? Так ведь можно настроить и Кассандру и кафку. Ждём некое подмножество
источник