Vadim Stepanenko

Писать все данные не в основную бд (бд платформы), а во временную бд апи и раз в N минут/часов сгружать данные в основную бд

Гораздо проще использовать нормальный сервер очередей. Вдобавок, данные будут быстрее попадать в БД не вися в отстойнике.

Ты не сообщил самое главное - как будут читаться собираемые данные. Будут ли они считываться и тем более фильтроваться в процессе записи, можно ли вводить запаздывание при чтении данных (например до 'некоторых' данных в прошлом).

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

Проблема не столько в данных и в их объеме, а в надежности всей схемы, т.е. например можно не делать единую точку отказа и сделать несколько независимых api endpoint, клиенты должны сами переключаться между ними, при ошибках, ну а сам выбор куда подключаться делать случайным.

Кстати, собственно сбор оперативных данных не обязательно делать в ОДНОЙ физической базе, это могут быть разные БД, а вот последующий анализ уже делать следующим сервисом (так же может быть несколько нод), собирающим данные из разных первичных источников в какой то единый или еще в какой то форме... именно подготовка данных к последующему их использованию и есть вопрос реализации.

Настоятельно не советую городить зоопарк из разных баз данных типа редис и sql-db.. когда sql база используется без индексов (и тем более без транзакций) на последовательную запись у нее нет конкурентов (ну только что совсем низкоуровневым программированием заняться)

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

Соответственно, вам нужен новый блок в двух случаях: либо он переиспользуется, либо для разделения кода для простоты восприятия.

Возьмём разметку посложнее (не надо в ней искать какого-то смысла, просто от фонаря что-то набрал для иллюстрации):

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

Ну так и пишите

.element {
   color: var(--color);

   body[theme="dark"] & {
      --color: white;
   }

   body[theme="light"] & {
      --color: #333333;
   }
}

Нет. Тип значения которое уже было возвращено всегда конкретен. Либо это строка, либо это объект.
Можно возвращать объект с методом toString который будет возвращать нужной строку при приведении к строке, но это не равносильно возвращению самой строки.

const ROUTES = {
  blog: {
    art: 'page-art',
    toString() {
      return 'section-blog'
    }
  }
}
ROUTES.blog.art // page-art
ROUTES.blog // object
'text: ' + ROUTES.blog // text: section-blog

Также можно попытаться накостылять магию с прототипом String, но это только в качестве развлечения, на проде за такое руки оторвут.)

SELECT categoryId, COUNT(*) AS `count`
FROM table
GROUP BY categoryId

const index = params?.index ?? section?.index ?? 0;

Перед запуском докера создайте пустой файл и дайте полные права (конечно slow.log а не slow.cfg)

touch ./resources/docker/logs/slow.log
chown 777 ./resources/docker/logs/slow.log

- "./resources/docker/logs/slow.log:/var/log/mysql/mysql-slow.log"

А лучше пробросьте в контейнер всю папку logs

volumes:
      - "./resources/docker/config/my.cfg:/etc/mysql/conf.d/config-file.cnf"
      - "./resources/docker/logs/mysql/:/var/log/mysql/"
      - "./resources/schema/schema.sql:/docker-entrypoint-initdb.d/1-schema.sql"

Это пустые страхи.
Никакой "фрагментации" "диска"в таблице из двух числовых полей (то есть с фиксированным размером записи) не будет. БД прекрасно сама повторно использует ячейки удалённых записей.
Поэтому, как правильно сказал Akina, мягкое удаление для лайков делать бессмысленно

INSERT OR UPDATE

используй INSERT ... ON DUPLICATE KEY UPDATE https://dev.mysql.com/doc/refman/8.0/en/insert-on-...
по user_id тобишь

Схематично:

SELECT orders.column,
       COALESCE(books.column, deposits.column) AS column
FROM orders 
LEFT JOIN books ON orders.type = 'book' AND orders.id = books.order_id
LEFT JOIN deposits ON orders.type = 'deposit' AND orders.id = deposits.order_id

shift+esc:

Обычно items делается в виде объекта, и тогда activeItem = items[activeItemId], это выполняется очень быстро.
Но если надо именно массив, то можно сделать так:

const activeItem = useMemo(() => items.find((item) => item.id === activeItemId), [items, activeItemId]);

Реселект нужен в тех случаях, когда в профайлере видно, что компонент перерисовывается, не смотря на то что данные в компонент не изменились.

Примеры того, когда это может быть: функция внутри useSelector создает и возвращает новый объект/массив. Функция (state) => state.settings[CONST_SECTION].list таковой не является

Даже когда эта идея прозвучала в популярном на то время сериале Теория Большого Взрыва, компания по сбору средств, на такой продукт собрала всего лишь 10 000 долларов что катастрофически мало.

Машина может работать при 35гр? а телефон? вот Вам ответ.
Если ноут перегреется - сам и вырубится, не парьтесь

Конечно нельзя сидеть под прямым солнцем с ЛЮБОЙ техникой(исключения техника с защитой IP 66 и выше). А в беседке - вполне ок, я сижу мне норм)

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

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

Ну на солнце лучше не сидеть. А в помещении при 30 градусах вроде ок.

Из того, без чего жить не могу
1. PhpStorm + sublime
2. Navicat - С этим старичком уже больше 15 лет вместе.
3. Gitkraken \ git-fork
4. Insomnia
5. Vagrant

С докером не локальной машине у меня всегда не складывается. Любое окружение, чуть сложнее запуска 4 контейнеров, сразу же прилетает довесок в виде баш скриптов между ними. Меня это всегда смущает и я перестаю в этом копаться.