lega

Для БД важнее io (быстрый диск) и кол-во оперативы, чтоб индексы влазили. А большая частота не значит большую производительность, 10-15 лет назад уже были процы под 4ГГц, но они слабее чем современный мобильный проц с частотой гораздо ниже.

Есть ещё вариант: список групп который хранится в каждом пользователе.

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

Ещё можно объеденить entity_id и entity_type в одну колонку (bigint),
если нужно джойнить, то можно использовать уникальные ид по всей базе (префиксные ид),
так же будет удобно ссылаться на объекты из других мест просто одним числом, без указания типа, т.к. тип зашит в ид.

параметр subscriptions в котором для каждого пользователя хранить массив состоящий из id пользователей на которых он подписан

Да, норм, так же можно сделать массив - кто на пользователя подписан, или оба, зависит от использования.

Если версия А1, то данные передаются (проваливаются) через прототипы (дочерние скоупы), и доступ на чтение к ним должен быть по имени (на запись - через родительский объект).
Если А2, то нужно через проперти компонентов передавать, в А2 нет встраиваемых темплейтов из коробки.

В вашем примере нет ngFor, какие данные не прокидываются?

Можете подготовить/переразбить html, удалить переводы строк и т.п.
''.join(page).replace('\n', '').split('<img')
без split можно использовать re.finditer

Так же можно сначала получить все img, а потом вручную отфильтровать по классу.

Когда-то успешно использовал велосипед, для вас будет что-то типа:
xget(html, 'img@class="jshop_img[\w -]+"~src')

qlkvg Фишка в том что не всегда нужен парсинг, иногда нужно просто выкусить/получить пару слов из html. В моем случае regex работал отлично и быстрее чем lxml (и аналоги) в 100-1000 раз, т.к. нужно было обработать всего 1% документа, а не парсить весь.

mongodump/mongoexport

Можно указать язык в индексе, тогда будет искать слова со склонениями ("книга/книги"),
Полнотекстового в монге вроде как нет, но можете вручную разбивать текст, например "Охранник" -> "охр охра охран охранн охранни охранник", тогда будет искать по любой части (с начала слова), аналогично делается поиск по любой части слова.
3-граммы (n-граммы) для поиска с опечатками.

Создается проперти app3.seen при изменении которого обновляется DOM.

Можно через map-reduce.
Но сам по себе такой запрос не эффективен, т.к. происходит перебор всех данных. Как минимум кешировать.

Все просто, в компоненте используется директива :value - она не отслеживает изменения option как это делает v-model.

Дополню: при изменении option, браузер автоматический корректирует значение select.value, :value это не учитывает.

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

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