Сергей Рогожкин

тк выплаты должны получать физлица круг платежек небольшой
название услуги которая вам нужна "Безопасная сделка" или "сплитование платежей" или "прием платежей маркетплейс"

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

Почему выплачивать деньги физлицами проблемно - смотрите как бывает тут
https://vc.ru/claim/87339-chto-proishodit-v-banke-...

Я не уверен что все эти компании делают именно выплаты физ лицам но попробуйте позвонить им
https://front.platron.ru/shops/marketplace
https://oplata.tinkoff.ru/solution/safe-deal/
https://rbk.money/payment-solutions/
payture.com
https://marketplace.payanyway.ru/
https://www.payu.ru/marketplace
яндекс касса - раньше такая услуга была называлась у них "безопасная сделка", сейчас нет информации на их сайте, возможно перестали делать

Гради Буч.

есть, но они не нужны
https://habr.com/ru/post/444022/
можешь посмотреть
https://github.com/AmundsenJunior/rest-go-mux-pq

https://github.com/gin-gonic/gin

Здесь еще можете почерпнуть других фреймворков https://github.com/avelino/awesome-go#web-frameworks

Базу данных можно выбрать любую. Она не играет роли в realtime приложениях. Позвольте вам немного объяснить. Для передачи данных между клиентом и сервером в браузере существует всего два протокола. HTTP и Websocket. Firebase не магия и также использует их. Если браузером не поддерживается Websocket, то firebase откатывается на HTTP. Используя общераспространенный подход к разработке на PHP у вас не получится использовать websocket протокол поскольку типичные PHP приложения не живут дольше 1 запроса. Соответственно да, в таком варианте остается только ajax. Но точно также работает и firebase если в браузере нет поддержки websocket, так работает facebook, telegram и много всего остального. Они используют long-polling. Клиент отправляет запрос к скрипту на сервер, скрипт в цикле опрашивает хранилище mysql или более продвинутый вариант mysql+redis (чтобы не грузить запросами mysql) и пока данных не будет, цикл так и продолжит крутиться, для клиента это просто выглядит как повисший запрос к серверу. Как только данные появляются, они отправляются на клиент, соединение разрывается, а клиент сразу же отправляет новый запрос.

Есть развитие этой идеи. Называется HTTP Streaming. Отличие от long-polling в том, что после отправки данных клиенту соединение не разрывается, а сервер продолжает отправлять последующие данные по этому же соединению. Соединение разрывается по таймауту. Минус в том, что прокси-сервера могут кешировать небольшие пакеты данных и данные нужно раздувать например пробелами, чтобы пакет данных достигал минимального размера и был способен пробить кеш прокси-сервера. Плюс в том, что если у вас данные для клиента появляются скажем с переодичностью раз в секунду, то не будет происходить постоянного открытия-закрытия соединения как при long-polling.

Есть вариант, когда можно реализовать небольшую прослойку на socket.io. Ваше PHP приложение пишет данные для клиента например в redis. Приложение на socket.io подписывается на redis. Когда PHP что-то отправляет в redis, то socket.io мгновенно об этом узнает и рассылает это событие по websocket протоколу всем подключенным клиентам. Минусы. Раздуваете стек. Нет консистентности данных между записью в основное хранилище (mysql/postgre/mongo/etc) и redis. Соответственно может возникнуть ситуация, когда данные записали, но в redis событие не ушло. Поменяете местами, будет наоборот, событие есть, данных в базе нет.

Вариантов в целом очень много. Всё это называется Comet. Вам проще всего реализовать long-polling.

А реал-тайм база, которая умела пушить данные клиенту по tcp протоколу (но не в браузер) была и называлась она rethinkdb.com. Ныне не развивается. IP в России заблокирован. На сайт можно сходить по VPN.

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

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

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Зря в сторону CUDA не копаете, умножение и сложение - это конёк GPU.
Банально, переводим супер длинное число в массив, умножаем массив на 1-байтовое число, учитываем сдвиги. Даже ядра свои писать не надо, всё нужное в библиотеке cublas есть. Результат по скорости очень удивит.

Можно почитать вот это: https://dev.mysql.com/doc/refman/5.7/en/general-ta... создать tablespace на разных дисках и сгрупировать по ним таблицы так, чтобы равномерно использовать место и производительность дисков.

Неверно в корне.
Вы нарисовали по сути EAV (есть такая готовая схема данных под эту задачу - погуглите, примеров много).

Плюсы:
Удобно ложиться в реляционную модель, удобно программируется (если вам удобно работать с реляционной моделью), на первый взгляд хорошо подходит под любую реляционную СУБД (MySQL, PostgreSQL, Oracle).

Минусы:
Неоправдано малоэффективно по производительности.
Есть решения на порядок более быстрые.

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

По мне так EAV удобен как средство редактирования (ну и хранения первичной информации).

А вот собственно сам поиск гораздо эффективнее осуществляется на full-text search engines, например:
SphinxSearch (или его клон Мантикора), ElasticSearch и т.п.

И чем по большему количеству фильтров идет поиск - тем больше этот разрыв (хотя он и по одному фильтру уже весьма заметен).

В наиболее развитых full-text search engine поиск по свойствам является "дешевой" операцией, совершенно совместимой с основным полнотекстовый поиском.

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

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

====================

Вывод:

Если вам принципиально на MySQL - просто см. описание схемы данных EAV. Она как раз именно что для этого.
Если вам нужно чтобы все летало - см. SphinxSearch (он крайне быстр и нетребователен к ресурсам).

P.S.:
SphinxSearch
Умеет выдирать данные из MySQL. На их основании строит уже свой собственный узкоспециализированный но очень быстрый поиск для выборок, в вашем случае, по названию и по свойствам товаров.

Веб-компоненты - обобщающее название нескольких технологий, позволяющих создавать собственные элементы с инкапсулированными структурой, стилями и поведением.
Т.е. вы создаёте один-два файла в какой-нибудь папочке, описываете в них разметку, стили и js-код и вызовом некоторых api-функций говорите браузеру - "вот мой собственный элемент с именем my-element, если встретишь тэг , то наполни его вот этим, стилизуй вот так и по событиям выполняй этот код".
Технологии, которые это позволяют постепенно появляются в браузерах, но как обычно не полностью и не везде. Нужны полифилы.

И да, веб-компонент мужского рода)

Чуть проще и понятнее: тут и тут

PS: И бонус, как всегда: тут.