PD
Там и комплаенс, и уровень и так далее. Многие хотели бы в облако, но низзя. В молодом финтехе в Европе и в Штатах получше
Size: a a a
2021 June 02
PD
Это мы еще взяли award как самое cloud like решение )
PD
Но все равно надо уметь вставать на bare metal (
PD
(Впрочем, у амазона iops безбожно дорогие)
T
мы даже как-то посчитали, что bare metal lease раз в 5 дешевле
PD
Ну, fdb на амазоне самое то. 6k iops на 1core node она и тянет.
T
интересно, спасибо за референс про fdb
T
как-нибудь заморочусь сравнить с кассандрой в наших сценариях
PD
Там можно поднять кучу узлов на одном сервере, но им памяти нужно сразу заметно. То есть 100k iops с узла мы не смогли утилизировать (
СХ
bolt db испытывали?
СХ
ну или LMDB, с которого он вдохновлялся? они как раз бенчили оптан
PD
Проект заброшен автором и не понятно, какие там вообще есть гарантии. И он, вроде бы, вообще не про записи (запись строго последовательна, с fysnc на каждый write - это точно не быстро).
СХ
не заброшен, как говорят его амбассадоры, а "дописан" ))
PD
LMDB показывает 35000 writes на Optane c 520000 IOPS
Это грустно и я столько и из FDB выжму )
Это грустно и я столько и из FDB выжму )
PD
Тем более что по сути они похожи.
PD
Только FDB еще и распределенная )
v
Привет всем, а ангулярщиков тут нет?
v
Всю мою практику мучает вопрос, а как быть с ошибками, вот fetch какой-то бросил скажем 500 и все, нет никакой методологии где и как это следует обработать
v
Хотя вопрос наверное кажется не ангуляра, а всех близких по парадигме решений
T
так вроде не очень много вариантов
если ошибка 5хх надо ретраить с backoff по фибоначчи
если ошибка 4хх то показать пользователю что-то вменяемое, куда-то его дальше вести, хороший UX
если ошибка 5хх надо ретраить с backoff по фибоначчи
если ошибка 4хх то показать пользователю что-то вменяемое, куда-то его дальше вести, хороший UX