ВС
Куберу докер нужен. Или любая другая реализация LXC контейнеров.
Size: a a a
2021 July 26
ВС
То есть, кубер - это сборщик, которому ты скармливаешь рецепт (манифест), а он по нему тебе уже собирает конкретное окружение
T🐜
https://itnext.io/symfony-messenger-worker-on-kubernetes-77f75725b5ed
вон в примере ниже смори, он команду в кубире запускает, а не в контейнере
вон в примере ниже смори, он команду в кубире запускает, а не в контейнере
ВС
И следит за состоянием этого окружения, чтобы оно всегда соответствовало требованию в манифесте
ВС
Что ты имеешь ввиду под "командой в кубере"? Для взаимодействия с кубером используется kubectl, в котором и выполняются команды. Можно зайти в Pod и выполнить команду в нём ещё.
ВС
И вообще, что ты за странный ресурс открыл, читай официальную доку сперва. Про архитектуру кубера начни читать. Могу тебе свою презентацию скинуть с краткой выжимкой по теме.
В
Подскажите как правильно хранить данные в базе
У меня есть 1000 пользователей, и у каждого может быть 1000 записей. Если все сложить в 1 таблицу, то получится 1 млн строк.
Мне нужно взять все записи пользователя одним запросом:
SELECT * WHERE user_id = $userID
Как можно организовать хранение данных так, чтобы максимально быстро получить все записи 1 пользователя?
У меня есть 1000 пользователей, и у каждого может быть 1000 записей. Если все сложить в 1 таблицу, то получится 1 млн строк.
Мне нужно взять все записи пользователя одним запросом:
SELECT * WHERE user_id = $userID
Как можно организовать хранение данных так, чтобы максимально быстро получить все записи 1 пользователя?
VM
не важно как ты положишь, но будет миллион записей =)
VM
1кк записей для любой БД - это не вопрос вообще
по user_id индекс построить и будет летать
по user_id индекс построить и будет летать
В
а если пользователей станет 10 тыс? скорость выбрки уменьшится
ВС
1кк - это 1млн
VM
если у тебя данные реально размазаны равномерно по пользователем, то партиции тебе помогут
VM
для этого и строят индексы, чтоб не перебирать всю таблицу
В
Дело в том, что пользователи загружают ексель таблицы, и я должен взять отдельные строки, в среднем по 1000 строк на пользователя.
И я боюсь, что с ростом пользователей приложение будет все медленнее, хочу заранее предусмотреть, кроме индексов что еще можно сделать?
И я боюсь, что с ростом пользователей приложение будет все медленнее, хочу заранее предусмотреть, кроме индексов что еще можно сделать?
VM
ты модешь легко проверить сгенерив фейковых данных на 1000, 10000, 1млн юзеров и проверить что будет с твоей системой
VM
можно не хранить в бд вообще эти данные, а сохранить их в обратно в файлик и прилинковав к юзеру ссылку на файл
В
а диск разве не медленнее, чем бД? будет же много чтения/записи с файлов
VM
ну это зависит от того, что ты с данными потом делаешь... если ты их просто хранишь после обработки и даешь "скачать" иногда, то можно и в файлике
если ты регулярно делаешь выборки, группировки и тд, то конечно в бд
если ты регулярно делаешь выборки, группировки и тд, то конечно в бд
В
группировок и выборок не будет, если писать в файл, то получится 1000 файлов, нужно будет их прочитать, сформировать отчет в виде JSON и отдать по API
В этом случае чтение 1000 файлов будет медленнее, чем БД?
В этом случае чтение 1000 файлов будет медленнее, чем БД?