Сергей Гладышев

updateOrInsert несовместим с "собирать в ОЗУ". Он тупо делает select а потом insert.

Хз сколько это 2гб в записях. Если до нескольких миллионов - то тупо делаете пачками по 3-5 тыс. select, потом insert недубликатов такими же пачками по 3-5кж

Если больше - делаете тоже самое, но разбиваете файл на несколько и раздаете задачи джобам.

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

единственный действенный способ оградить код – не отдавать его, а запилить saas.

Просто для информации, хранимые проценуры не используются вообще нигде, кроме, наверное, хардкорного энтерпрайза.
Тем более непонятно, как процедуры решают проблему переделывания кода.

Если отвечтаь на вопрос буквально, то

1. Для большинства простых операций с БД запросы вообще не пишутся, пишутся обращения к ORM. Например в вместо

$stmt = $pdo->prepare("SELECT * FROM users WHERE id=?");
$stmt->execute([$id]);
$user = $stmt->fetch();

Пишется

$user = $em->getRepository(User::class)->find($id);

2. Сложные запросы с фильтрами лежат в специальных классах, которые называются репозиториями.

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

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

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

а переписывать и тестировать процедуры в субд проще? тем более, скорее всего, с изменением процедуры придется переписывать код все равно.

Конструктор new Phar('my_new_phar.phar') создаёт новый архив
addFile('SimpleClass.php') добавляет в архив ваш файл с классом.

https://odan.github.io/2017/08/16/create-a-php-pha...

Не делайте так. В инструкциях четко написано серверный токен должен храниться на сервере, и желательно в защищенном хранилище.

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

Ничего шифровать не нужно. Алгоритм такой
1. Берете https://github.com/Valve/fingerprintjs2
2. Отправляете результат его работы c каждым запросом
3. Авторизируетесь и получаете токен который на сервере привязан к fingerprint и IP
4. При получении запроса с токеном и fingerprint, проверяете наличие токена в своем хранилище, и соответсвие токена IP и fingerprint которые пришли с клиента
5. Если не прошла проверка, заставляйте авторизироваться снова.

P.S. IP часто динамический. Так что учитывайте это. Например много людей используют мобильный интернет. Плюс нужно понимать что может быть несколько устройств. Пользователь может зайти с планшета, телефона и ПК

через сам php никак, только с помощью ffmpeg

В общем, вот такой конфиг завелся :

version: '2.0'
services:
    rabbitmq:
        image: rabbitmq:3-management-alpine
        container_name: rabbitmq
        volumes:
            - ./.docker/rabbitmq/etc/:/etc/rabbitmq/
            - ./.docker/rabbitmq/data/:/var/lib/rabbitmq/
            - ./.docker/rabbitmq/logs/:/var/log/rabbitmq/
        ports:
            - "5672:5672"
            - "15672:15672"
    nginx:
        image: nginx:latest
        ports:
            - "8000:80"
        # монтируем директории, слева директории на основной машине, справа - куда они монтируются в контейнере
        volumes:
            - ./hosts:/etc/nginx/conf.d
            - ./www:/var/www
            - ./logs:/var/log/nginx
        links:
            - php
    php:
        # у нас свой образ для PHP, указываем путь к нему и говорим что его надо собрать
        build: ./images/php
        links:
            - mysql
            - rabbitmq
        volumes:
            - ./www:/var/www
    mysql:
        image: mariadb
        ports:
            - "3306:3306"
        volumes:
            - ./mysql:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: secret
        environment:
            PMA_HOST: mysql
            MYSQL_USERNAME: root
            MYSQL_ROOT_PASSWORD: secret

Далее ставим плагин , дающий возможность изучать происходящее в кролике используя браузерный UI.
Для этого заходим в контейнер docker exec -it rabbitmq bash
Ставим плагин rabbitmq-plugins enable rabbitmq_management
Можно убедиться , что все установлено rabbitmq-plugins list
Нам покажут список установленных плагинов.
После заходим по адресу localhost:15672 (пароль-логин , по умолчанию guest).

Кролик готов! :)

На еластике это решается так https://project-a.github.io/on-site-search-design-...

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

Крч я через сниффер перехватил запрос, куда отправляет приложение бум.
И просто отправить такой же запрос мало.
Нужно отправить точно такие же заголовки, иначе будет ошибка либо пустой массив возвращать.
Поэтому я передал все в точности как и бум. И получил такой рабочий код:

$ch = curl_init('https://api.um-agency.com/feed/tracks/get?pass_key=bamboo5e4d9fcf47abb&block_type=3&offset=0&count=100');
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        "Accept: application/json",                                             //
        "User-Agent: VK_Music/4.2.1 (Android 4.2.4749 8.1.0)",                  // Получение списка топ 100 чарта вк, маскируясь под Boom
        "Host: api.um-agency.com",                                              //
        "Accept-Encoding: utf-8",
        "Connection: Keep-Alive"
    ));
    $html = curl_exec($ch);
    curl_close($ch);
    $list_arr = json_decode($html);

Я генерировал раписания постов для каждого пользователя, когда стояла аналогичная задача.
Пользователь регистрируется у бота, и в этот момент для существующих в БД постов к рассылке генерируется расписание для данного пользователя. Далее кроном дергается скрипт, который проверяет, есть ли на данный момент расписание для рассылки, и отправляет сообщения.
Не уверен в оптимальности такого решения, но в моем случае получилось достаточно гибко.
Можно попробовать сделать нечто аналогичное.

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

Если это невозможно - группируйте поисковые запросы и привязывайте результат к такой группе.
Для отображения - находите группу для запроса и достаёте ответ из кэша этой группы.
Привязка простая: "один-ко-многим": ответID->запросы.

Дополнительно:
Можно проставлять "веса" на каждое слово в запросе и составить свой словарь синонимов, чтобы выдавать релевантные результаты из своего кэша на запросы, которые похожи на предыдущие, но которые не отправлялись ни разу на API фотохостинга.
Иными словами: сделать свой промежуточный поиск до поиска в фотохостинге через API.