Email or username:

Password:

Forgot your password?
Ambassador Tablicek

Подумываю провести аналогии главы "40 основных приёмов по устранению технических противоречий" из книги Найти Идею с архитектурными рефакторингами в разработке ПО. Будет много сов, много глобусов. Стоит оно того, чтобы как минимум похихикать в процессе, а как максимум - поржать с того что все эти ваши рефакторинги придумали 40 лет назад. Заодно систематизирую кашу в голове.

25. Принцип самообслуживания.

Очень нравится концепция health-check, которые могут исправлять найденные проблемы, а не только говорить "мне херово". В ту же степь изначально спроектированные ограничения в сроке жизни данных - системы, которые не разрастаются, а агрегируют (при этом способны извлекать пользу из этих агрегатов), а затем и удаляют архивные данные и которые не надо обслуживать руками – офигенные.

2 comments
Ambassador Tablicek

26. Принцип копирования.

а. Вместо недоступного, сложного, дорогостоящего, неудобного или хрупкого объекта использовать его упрощенные и дешевые копии.

Буквально принцип CQRS, разделение читающей и пишущей нагрузки. Читать можно с множества дешёвых копий с небольшой приемлемой задержкой лага репликации, разгружая от читающей нагрузки мастер-реплику. Туда же вынос аналитики в отдельные BI системы, что даёт возможность не хранить архивы в рабочей базе.

Ambassador Tablicek

34. Принцип отброса и регенерация частей.

а. Выполнившая свое назначение или ставшая ненужной часть объекта должна быть отброшена (растворена, ис- парена и т. п.) или видоизменена непосредственно в ходе работы.
б. Расходуемые части объекта должны быть восстановлены
непосредственно в ходе работы.

Пункт "а" напоминает soft delete совсещённый с отложенным hard delete в базах, позволяющий рабочей БД не распухать со временем и не требовать дополнительного обслживания или сложных технических решений по работе с большими объёмами данных. Куда проще с такими данными просто не работать.

Как альтернатива, во всевозможных мониторингах требования к детализации данных сейчас, через месяц, через полгода и два года весьма различны. В каком-то роде сжатие архивных данных через агрегацию тоже можно считать отбросом части данных.

Аналогично действует и "прореживание" бэкапов через нечто похожее на цепочку кольцевых буферов - github.com/strizhechenko/backu

34. Принцип отброса и регенерация частей.

а. Выполнившая свое назначение или ставшая ненужной часть объекта должна быть отброшена (растворена, ис- парена и т. п.) или видоизменена непосредственно в ходе работы.
б. Расходуемые части объекта должны быть восстановлены
непосредственно в ходе работы.

Пункт "а" напоминает soft delete совсещённый с отложенным hard delete в базах, позволяющий рабочей БД не распухать со временем и не требовать дополнительного обслживания или сложных технических решений по...

Go Up