DollyPapper

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

Потому что в Го сигнатура метода в интерфейсе должна совпадать полностью. Таким образом на рантайме они быстро матчатся.

Иначе пришлось бы заглядывать внутрь типа A, а так как это все происходит на рантайме, было бы неоптимально. Возможно для вашей цели больше подойдут дженерики, в их случае происходит мономорфизация и компилятор генерирует отдельный код для каждого варианта дженерика, что работает быстро.

Кстати, не рекомендую называть интерфейсы ISomething, это не принято в Го.

1. Можно включить вендоринг - тогда все зависимости будут размещены в подпапке vendor и при следующих сборках доступ в интернет не понадобится. go mod vendor
2. Можно установить переменную GOPROXY так, чтобы исходники качались не через прокси proxy.golang.org, а через другой или напрямую с гитхаба. Environment variables
3. Можно использовать уже скачанный локально репозиторий. replace directive in go.mod

UPD: конкретно для go install можно попробовать п.2 с GOPROXY. Либо склонировать исходный репозиторий и собрать бинарник командой go build - для разрешения проблем с доступом к зависимостям воспользовавшись п. 1-3.

UPD 2: по конкретно интересующему вас репозиторию: клонируете его, переходите в папку installer и выполняете в ней GO111MODULE=off go build, получите собранный бинарник - нет там никаких внешних зависимостей и даже go.mod

1. GIN индексы - https://medium.com/@maanavshah/performance-optimiz...

2. Через костыли: сделать составной индекс на url и на reverse(url) и искать как url like 'setting%' and reverse(url) like reverse('%setting')

если нужно в динамике - одновременно выводить на консоль, писать в файл и тут же сразу построчно анализировать поступающую информацию, то тут чуть сложнее, хоть и не немного, вот небольшой пример:
работа через файл

#!/usr/bin/env bash

# функции бот1 и бот2 которые постоянно выводят рандомно числа от 0 до 9 с интервалом в 2 секунды
bot1(){
	while true; do
		echo "Bot1: $[RANDOM%10]"
		sleep 2
	done
}

bot2(){
	while true; do
		echo "Bot2: $[RANDOM%10]"
		sleep 2
	done
}

# путь к лог-файлу куда будем писать логи от ботов
LOG=/tmp/botsLog.txt

# удаляем лог-файл (если ненужно то закоментирвоать)
rm -rf $LOG

# запускаем ботов в фоновом(&) режиме, 
# а также начинаем выводит поступающую от них информацию на консоль и писать в общий лог-файл
bot1 | tee -a $LOG &
sleep 1
bot2 | tee -a $LOG &

# функция анализа лог-файла (потока)
analysisLogs() {
	# запускаем постоянное построчное чтение поступающих данных в функцию
	while read -r data; do
		# здесь мы задаём фильтры и то что выполнить если совпадёт условие
		case "$data" in
			"Bot1: 0" ) echo "Бот 1 выдал ноль"
				;;
			"Bot2: 0" ) echo "Бот 2 выдал ноль"
				;;
		esac
	done
}

# tail выводит поступающие данные по мере роста лог-файла (мониторит)
# в данном случае мы передаём появляющиеся данные из файла в функцию analysisLogs
tail -f $LOG | analysisLogs 

# это необходимо чтобы главная программа преждевременно не завершилась 
# пока не завершаться запущенные в ней фоновые(&) потоки
wait

exit

с комментариями думаю будет понятней
ctrl+c завершить скрипт

можно конечно и через переменную сделать но это будет не так красиво да и не по феншую, кстати здесь мы пишем в ОЗУ так как /tmp у большинства дистрибутивов примонтирован в оперативной памяти.

Если же не хочется вообще писать данные на диск или в озу, так как логи обычно склонны к накоплению если их не чистить да или просто ненужны, то можно просто использовать именованный канал(FIFO-файлы) с которым можно работать как с файлом(читать/писать) но при этом он будет выступать просто в роли промежуточного буфера, для этого в нашей программе нужно поменять всего две строчки(создать именованный канал и вместо tail использовать обычный cat )
работа через fifo-файл

#!/usr/bin/env bash

# бот1 и бот2 просто постоянно выводят рандомно числа от 0 до 9 с интервалом в 2 секунды
bot1(){
	while true; do
		echo "Bot1: $[RANDOM%10]"
		sleep 2
	done
}

bot2(){
	while true; do
		echo "Bot2: $[RANDOM%10]"
		sleep 2
	done
}

# путь к лог-файлу куда будем писать логи от ботов
LOG=/tmp/botsLog.txt

# удаляем лог-файл
rm -rf $LOG

# создаём именованный канал (FIFO-файл)
mkfifo $LOG

# запускаем ботов в фоновом(&) режиме, 
# а также начинаем выводит поступающую от них информацию на консоль и писать в общий fifo-файл
bot1 | tee -a $LOG &
sleep 1
bot2 | tee -a $LOG &

# функция анализа поступающих данных
analysisLogs() {
	# запускаем постоянное построчное чтение поступающих данных в функцию
	while read -r data; do
		# здесь мы задаём фильтры и то что выполнить если сработает условие
		case "$data" in
			"Bot1: 0" ) echo "Бот 1 выдал ноль"
				;;
			"Bot2: 0" ) echo "Бот 2 выдал ноль"
				;;
		esac
	done
}

# читаем файл(FIFO-файл) и передаём появляющиеся данные в функцию analysisLogs
cat $LOG | analysisLogs 

# это необходимо чтобы главная программа преждевременно не завершилась 
# пока не завершаться запущенные в ней фоновые(&) потоки
wait

exit

Мужские мужчины уже ответили на основной вопрос.

Я добавлю что чем больше данных мы обрабатываем тем дороже становиться цена передчи
информации из места где оно храниться в блок вычислений. В концепции трехзвенки которая
описана RDS(Postgres)/NodeJS/Python/Web удобнее всего вычилсять прямо в Postgres. Поскольку
данные рядом и сетевых расходов на передачу нет. Если Postgres по каким-то причинам не может
вычислять или не владеет API то в этом случае мы с помощью курсора (SELECT) передаем
нужный датасет на клиента (в данном случае это Python/Node) и там вычисляем. При этом
мы должны понимать что это займет время и сетевой канал да еще и результат вычислений
тоже надо отослать обратно. Тоесть данные будут бегать как рейсовый автобус туда-сюда.

Для однозначного решения что хорошо и что плохо - надо ставить эскперимент. Но предварительно
мне и присуствующим уже очевидно что лучше всего вычислять прямо в хранимых процедурах
Postgres. Единственным доводом против может быть несовершенство языка PL/pgSQL
но я-бы этот факт тоже проверил. Для реляционных задач его обычно хватало.

Данная проблема (рейсовый автобус для данных) еще более сильно выражена в BigData. Там стараются
дизайнить систему так что данные - write-only и после загрузки в хранилище (ETL/ELT) больше никогда
не изменяются и лежат неподвижно (т.н. Bronze Level информации). И джобы которые бегают
по ним - запускаются в вычислительном кластере физически рядом с дисковым хранилищем.

Вот. А на клиента отдаются обычно сводные отчеты и кака-то аналитика. Это то что в 100-10000 раз меньше
по размеру обычно чем основные данные.

Хорошей практикой является принимать данные из БД в структуру, которая соответствует по типам тому, что лежит в БД.

Если вам нужно конвертировать потом эти данные, конвертируйте их в другую структуру, которая расположена на слое бизнес-логики, например.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

кол-во вакансий у RN в раза 2-3 выше

Это.