Просто опыта мало, нагуглил сегодня что MySQL может вставлять 40.000 записей в секунду, простым инсертом (массовым конечно)
И даже может вставить 247.000 в секунду если через батч файл
Эти цифры даже близко не мои 445 строк в секунду, поэтому проблема меньше, чем мне показалось.
Скорее всего телодвижений потребуется минимум.
Просто буду как-нибудь писать данные в tsv файлы и например раз в минуту персистить эти данные в базу, реалтайм не обязателен.
А я уже нагородил себе какие-то сервисы на go, какой то master-slave и тд и тп
Тут главное минимизировать количество подключений, потому что 445 +1 подключений для MySQL вроде бы многовато, по дефолту 100 стоит
Дмитрий, на счет «апи большого брата»то кстати да, но в теории «на словах» все должно работать и пока не думаем, что сторонний сервис как-то откажет.
Когда нужны данные:
Да нет, я бы не сказал что сразу, 90 процентов действий это задачи из очереди, выполняются в фоне, клиент заходит и видит только лишь графики, те результаты по факту, ну иногда уведомления получает, когда данные с этих графиков уже какие-то странные, но это детали бизнес-логики.
Нет, данные сразу не нужны, я пока н понимаю может ли MySQL писать 445 записей в секунду, по ним строить индекс и еще изредка отдавать ответы на select..
Дмитрий, спасибо за ответ. Пойду гуглить дальше. Идея на каждый запрос обращаться в главный сервис чтобы проверить токен - убъет мое приложение. (Пункт 3)
Очень узкое место. Вдруг главный не отвечает, вдруг тайм-аут 29сек от него, вдруг еще чего, а у меня пользователи так и останутся висеть, все их запросы будут разворачиваться по тайм-ауту в самом начале при валидации токена, ну нафиг такой подход, буду искать новый, ходить каждый раз за валидацией токена куда-то далеко не вариант.
А к данным пользователя я буду обращаться крайне редко, при авторизации я же у себя юзера сохраняю в базе и работаю уже «локально». Обновлять его поля только при следующей его авторизации значит буду
Дмитрий, мой сервис - это приложение на ларавел на отдельной впс, реализовано как json api, рядышком фронт на react общается с моим сервисом по апи.
А есть еще один «главный сервис» и он не мой, но у него есть юзеры и он должен «выдавать» их мне (как я понимаю по oAuth2), на моем сервисе нет кнопки «зарегистрироваться», только кнопка «войти через главный сервис», те клиентов «сам» я не регистрирую, а только лишь получаю в колбеке от главного сервиса
Дмитрий Кузнецов, не могу скрин сделать, тк нечего скринить, никаких ошибок
вот такие только скрины (ответ от севера с domain localhost и localhost:3000)
mayton2019, ответ от api, часть большой xml, сломалось тут недавно, начал разбираться и увидел что вот такое вот приходит.
вручную поменял кавычки внутри кавычек - код заработал
XML у меня мапится на мой класс (JMS\Serializer\...)
Просто опыта мало, нагуглил сегодня что MySQL может вставлять 40.000 записей в секунду, простым инсертом (массовым конечно)
И даже может вставить 247.000 в секунду если через батч файл
Эти цифры даже близко не мои 445 строк в секунду, поэтому проблема меньше, чем мне показалось.
Скорее всего телодвижений потребуется минимум.
Просто буду как-нибудь писать данные в tsv файлы и например раз в минуту персистить эти данные в базу, реалтайм не обязателен.
А я уже нагородил себе какие-то сервисы на go, какой то master-slave и тд и тп
Тут главное минимизировать количество подключений, потому что 445 +1 подключений для MySQL вроде бы многовато, по дефолту 100 стоит