Я много лет писал на С++ и могу вам сказать, что он не быстрее ни на 92%, ни на 82%
если честно, то я тоже много лет писал на С++ и могу вам сказать, что mp_allocator дает ускорение в 5-8 раз, а не жалкие 100% https://ders.by/cpp/norefs/norefs.html#4.2
и везде и всегда, GC - это УБИЙЦА производительности многопоточных приложений!
факт в том, что на сегодняшний день мелким и средним бизнесам ВООБЩЕ не нужна распределенка, k8s и прочие гадости:
Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.
Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро в секунду) или даже 50 000 звучит более правдоподобно.
А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.
Если вы пытаетесь сделать проект, конкурирующий с тем, на котором зарабатывает Диктатор — тогда будьте готовы к тому, что вас будут годами, так сказать, «травить собаками».
ну покажите мне еще один "велосипед", где копирование объекта HashMap со всеми ее элементами - это просто memcpy()? джависты даже не поймут суть вопроса.
если честно, то я тоже много лет писал на С++
и могу вам сказать, что mp_allocator дает ускорение в 5-8 раз, а не жалкие 100%
https://ders.by/cpp/norefs/norefs.html#4.2
и везде и всегда, GC - это УБИЙЦА производительности многопоточных приложений!
факт в том, что на сегодняшний день мелким и средним бизнесам ВООБЩЕ не нужна распределенка, k8s и прочие гадости:
вот ссылка, если нужны подробности: https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f
а теперь посмотрите на это:
by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs.
both Shenandoah and ZGC have worse (by factors of 10–100×) query latencies than the other three collectors!
отсюда https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f
почитайте главу 5.7 Clocks and Timers
книги Nicolai M. Josuttis-The C++ Standard Library, 2nd Edition_ A Tutorial and Reference-Addison-Wesley (2012).pdf
абсолютно в точку!
"Здесь вообще всё просто так, кроме денег" (ц)
смиялсо.
ну покажите мне еще один "велосипед", где копирование объекта HashMap со всеми ее элементами - это просто memcpy()? джависты даже не поймут суть вопроса.
а бывает HashMap с транзакциями. но на Жабе у вас не получится.
https://ders.by/cpp/memdb/memdb.html
хехе. для начала контекст новым читателям:
итак, наш Vault - тоже База. база секретов.
и вы только что нам сказали, что у вас есть "2 варианта" безопасного соединения с Vault. прекрасно!
так почему бы Приложению сразу не использовать эти "2 варианта" для прямого соединения с Базой без всякого Vault?
если "2 варианта" безопасны, то Vault не нужен. (не улучшает Безопасность)
если "2 варианта" НЕ безопасны, то Vault не нужен тем более!! (он ухудшает Безопасность)
вы не поняли сути вопроса.
если для доступа к ПровайдеруСекретов необходим токен, то вам нужен ПровайдерСекретов2 ;)
и взрослые вроде люди... зачем разбирать сказки?
галочка на UI - это просто галочка. шифруйте сами локально. только так.
все хуже, на самом деле.
эти 5 секунд жестко встроены в Архитектуру. и возможность поднять их до 10 неизбежно означает, что что-то ухудшится в те же 2-4 раза.
кто-нибудь гуглил GitHub SLA?
получается смешно немного там (ц) Йода
лучше смотреть вызов t->commit(test07_wrt_cb, mp, test07_chk_cb, mp); в code\test_mem_db\main.cpp из https://ders.by/cpp/deque/code.zip
вы ж понимаете, что ко всему закроют доступ.
все согласно Концепции: это продвинутая хеш-таблица для тех, кому уже не хватает обычной. т.е. удобный и быстрый кэш, а не медленная БД.
ЗЫ и обратите внимание на колбэки check_cb и write_cb метода commit() -- это абсолютно уникальные возможности!
потому что у Go есть GC, а сборщик мусора в многопоточном приложении - это УБИЙЦА производительности!!!
многопоточность очень сложна, но оправдана при росте производительности.
а потом мы прикручиваем костыль, убивающий всю производительность...
за что боролись граждане??
держу пари, что вы это не знали:
by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs.
both Shenandoah and ZGC have worse (by factors of 10–100×) query latencies than the other three collectors!
здесь подробности https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f
не бывает такой Роскоши, увы.
(в серьезных проектах)
bottleneck - это не оскорбление :) он есть всегда.
это как скорость эскадры определяется скоростью самого медленного корабля.
практика показывает, что в реальных проектах есть только один СЕРЬЕЗНЫЙ bottleneck. максимум два.
это другое :)
смотрите https://en.wikipedia.org/wiki/FoundationDB#Design_limitations
FoundationDB does not support transactions running over five seconds.
Transaction size cannot exceed 10 MB of total written keys and values.
Keys cannot exceed 10 kB in size. Values cannot exceed 100 kB in size.
пять секунд - это стыдно. и остальное тоже.
а, ну еще можно эффективно создавать Структуры данных второго порядка внутри ЛЮБОГО key-value store
https://ders.by/cpp/deque/deque.html
BTW если надо ОЧЕНЬ быстро и внутри процесса, то рекомендую Хеш-таблицу с транзакциями
https://ders.by/cpp/memdb/memdb.html