Получается, раз 1й товар встречался в похожих у 2го и 3го (оба раза на втором месте), то и в новом словаре для него будут ключами - товары 2 и 3, значениями - позиции, оба раза 2-е.
Когда из этого набора данных удастся вытащить позиции для товара 1, получится что-то вроде:
+-------+---------------------------------------+
| id | similar_from.1 |
+-------+---------------------------------------+
| 1 | null (или 0, не проверял) |
+-------+---------------------------------------+
| 2 | 2 |
+-------+---------------------------------------+
| 3 | 1 |
+-------+---------------------------------------+
Если ваш магазин начнет помимо двух видов товаров продавать хотя бы еще 1000, вы так и будете делать модельки на каждый новый вид?
Подробнее не получится, потому что это навык "моделирование предметной области". Частично можно получить, прочитав учебники по реляционным базам данных, частично - с опытом придет.
Тут два варианта. Либо не инициализировать пул в родительском процессе, чтобы не делиться коннектами с потомками, либо при инициализации нового процесса переинициализировать пул.
Когда процесс форкается, все его ресурсы шарятся между родителем и потомком. В результате, все ваши воркеры пользуются одним и тем же коннектом (так это видит постгрес). Получается, что БД общается с процессом, у которого не то чно раздвоение, раз-n-ие личности. При этом байты, возвращаемые постгресом, перепутываются тем больше, чем интенсивнее идет общение с БД. После форка в дочернем процессе необходимо закрывать все ресурсы, открытые в родительском, кроме явно необходимых. Увеличение числа коннектов с 1 до 400 проблему не фиксит а скрывает, ну типа
field потрошится на слова и хранится либо в виде их хешей, либо в виде exact_word. Поиск ищет по field. Однако, чтобы написать SELECT my_text FROM ..., вам понадобится attr.
Попробуйте склеить сначала первое и последнее видео. Если качество устроит и не будет разрывов - меняйте размер слайдшоу на этапе склейки картинок, тогда получится избежать перекодирования.
Не кажется ли вам, что отдавать файл через GraphQL - это странно? Как минимум придется их парсить на клиенте из json-ответа и создавать дополнительную нагрузку на саму Django, вместо отдачи статики каким-нибудь nginx.
Последний параметр в QueueDeclare имеет тип Table (в исходниках видно). Table - это алиас для словаря из строковых ключей и произвольных значений. Создаете словарь с нужными вам данными и передаете в вызов. Подробнее только в учебнике голанга.
На первом шаге перенумеруем позиции:
На втором шаге перекинем данные аналогично тому, как это было проделано с колонкой similar_from
Получается, раз 1й товар встречался в похожих у 2го и 3го (оба раза на втором месте), то и в новом словаре для него будут ключами - товары 2 и 3, значениями - позиции, оба раза 2-е.
Когда из этого набора данных удастся вытащить позиции для товара 1, получится что-то вроде:
Отсюда уже понятно что в where и order by