Например, компоненты с высоким уровнем абстрактности и низкой устойчивостью могут считаться хорошо спроектированными, поскольку они легко адаптируются к изменениям и масштабируются.
Согласно этому положению, хорошо спроектированным является компонент в координатах , но, в действительности, это "зона бесполезности". Кажется, здесь допущена ошибка.
Для примера, сам Мартин пишет
Как компонент с максимальной устойчивостью (I=0) сделать гибким настолько, чтобы он сохранял устойчивость при изменениях? Ответ заключается в соблюдении принципа открытости/закрытости (OCP). Этот принцип говорит, что можно и нужно создавать классы, достаточно гибкие, чтобы их можно было наследовать (расширять) без изменения. Какие классы соответствуют этому принципу? Абстрактные.
вкратце: делаем сиквенс с шагом в X (например 100) каждая сессия получает опорное значение и следующие X-1 значений крутит у себя в памяти это даёт скорость и гарантирует уникальность из минусов - могут быть большие "дыры" в случае рестартов приложения но, кажется, это неважно. а достичь глобальной последовательности вообще почти невозможно с учётом скалирования и использования пуллов коннектов.
это ведь делается для подъёма в кеш значений переменных a и b? Но чем гарантируется предварительный сброс значений этих переменных в память? sfence после их присвоения не вызывается. Это обеспечивается особенностями memory model в C (не знаю этот язык), или я упустил саму цель lfence перед валидацией значений a и b?
в контексте redis речь про "appendfsync always", или о "In the case of a complete system failure on default settings, only a few seconds of data would be lost."? если о первом варианте, то будут ли преимущества при обработке скачков относительно dbms с wal-ом?
@vadv,большое спасибо за дополнительное исследование! крайне любопытно и полезно. про FPW - отлично. наверное, можно было бы даже в саму статью добавить. познавательно!
по п.2 есть некоторые сомнения, которые хочется развеять. WAL ведь - транзакционный лог с LSN. сброс буферов на диск через WAL не проходит и, кажется, не должен сказываться на его приросте. возможно, под WAL в графике скрывается что-то другое, или причина WAL-логенерации иная?
можно предположить что с checkpoints что-то нездоровое происходит и WAL активно чистится, что учитывается а графике, но до конца физика мне пока не ясна.
1. параметры запуска pg_bench (особенно интересны --client=clients и --jobs=threads)
2. в чём, на ваш взгляд, причина активной генерации wal в бенчмарке с uuid v4?
Согласно этому положению, хорошо спроектированным является компонент в координатах
, но, в действительности, это "зона бесполезности".
Кажется, здесь допущена ошибка.
Для примера, сам Мартин пишет
, то есть объявляет удачными координаты
написать\найти аналог pooled-генератора
https://vladmihalcea.com/hibernate-hidden-gem-the-pooled-lo-optimizer/
вкратце: делаем сиквенс с шагом в X (например 100)
каждая сессия получает опорное значение и следующие X-1 значений крутит у себя в памяти
это даёт скорость и гарантирует уникальность
из минусов - могут быть большие "дыры" в случае рестартов приложения
но, кажется, это неважно. а достичь глобальной последовательности вообще почти невозможно с учётом скалирования и использования пуллов коннектов.
Спасибо за ответ и за ссылки!
Спасибо за статью.
Подскажите, когда вы делаете в последнем примере
это ведь делается для подъёма в кеш значений переменных a и b?
Но чем гарантируется предварительный сброс значений этих переменных в память?
sfence после их присвоения не вызывается.
Это обеспечивается особенностями memory model в C (не знаю этот язык), или я упустил саму цель lfence перед валидацией значений a и b?
в контексте redis речь про "appendfsync always", или о "In the case of a complete system failure on default settings, only a few seconds of data would be lost."?
если о первом варианте, то будут ли преимущества при обработке скачков относительно dbms с wal-ом?
@vadv,большое спасибо за дополнительное исследование! крайне любопытно и полезно.
про FPW - отлично.
наверное, можно было бы даже в саму статью добавить. познавательно!
большое спасибо за подробный ответ!
по п.2 есть некоторые сомнения, которые хочется развеять.
WAL ведь - транзакционный лог с LSN.
сброс буферов на диск через WAL не проходит и, кажется, не должен сказываться на его приросте.
возможно, под WAL в графике скрывается что-то другое, или причина WAL-логенерации иная?
можно предположить что с checkpoints что-то нездоровое происходит и WAL активно чистится, что учитывается а графике, но до конца физика мне пока не ясна.
1. параметры запуска pg_bench (особенно интересны --client=clients и --jobs=threads)
2. в чём, на ваш взгляд, причина активной генерации wal в бенчмарке с uuid v4?
спасибо
спасибо!