Oleg
да просто руками промапили
Oleg
хардкодом
Oleg
со строками
Oleg
сложили в отдельный класс и пометили, что да, это некрасиво выглядит, но необходимо
yopp
тот самый момент когда стоит задуматься об инвестиции в оперсурс, через контрибьюшены.
Bro
порой бывает что проще в новую коллекцию инсертами напихать быстрее чем удалят или модифицировать текущую
Oleg
порой бывает что проще в новую коллекцию инсертами напихать быстрее чем удалят или модифицировать текущую
у нас большая вложенность документов была
Viktor
тот самый момент когда стоит задуматься об инвестиции в оперсурс, через контрибьюшены.
Там годами пулреквесты игнорят
Viktor
Мне вроде один раз удалось их натыкать носом в конкретный перформансный проеб
Viktor
И его починили
Олег
Nick
Олег
не спец, но проверьте пользователя изпод которого запускается монга, возможно у него нет прав
Nick
ну полагайте, првоерять лучше через просмотр юзера изпод которого запущен процесс
Nick
а не мифические конфиги
Георгий
Всем привет)) Проблема с монгой))
Георгий
В каких случаях нужно закрывать базу данных?
Георгий
ТО есть я открыл коннект наприме, сделал запрос на получении коллекции. После перешел на страницу каталога там получается тоже нужен запрос к базе данных чтобы получить список товаров. Вот в каком месте этих действий надо закрывать базу?
Nick
ни в каком, вы должны создать подключение в момент старта приложения и работать пока не помрет приложение
Георгий
Спасибо)) Прсто так странно сейчас смотрю видеоуроки от loftschool и там на каждое действие открывается и закрывается база данных, делал по тому как рассказывает учитель и нихера))
Nick
а можно всетаки кусочек кода, а то мне кажется я немного про другое
Nick
где открывается бд и закрывается
Георгий
Георгий
Георгий
А там еще 4 операции поиск по id, insertOne, update и delete
Nick
ну да, это корректно когда у вас простые тесты. в общем случае вы создаете коннект до базы, тот самы .connect(), и только после подклчюения инициализируете все остальное имея объект db и работая дальше в приложении только с ним
Георгий
А коннетк должен быть один?
Nick
да, драйвер сам разберется что дальше делать, по идее там асинхронщина, да и наверняка пул коннектов имеется и менеджерится самим драйвером
Yurii
Andrey
подскажите пожалуйста технику создания индексов в моем случае: база создается налету если это необходимо, как быть в этом случае с индексами, каждый раз вручную проверять существует ли БД?
пример кода
_, err := m.client.Database(getDbNameFromIssue(issueId)).Collection("postspins").InsertMany(context.Background(), docs)
dima
привет, скажите на практике часто ли используется АФ в монге? я так понял что это мощный инструмент по переносу обработки выборки с клиента на сервер.
dima
интересует именно практическое применение. Вот например есть клиент и хочет из бд условно что-то выбрать. Так вот я могу получить выборку и обработать на своем сервере и отдать клиенту, либо использовать АФ и выбрать и обработать на сервере бд? вот тут что-то не совсем понятно
dima
Я так понял что лучше применить АФ поскольку работать с BSON будет быстрее чем если например получить выборку и обрабатывать у себя после JSON.parse(). Особенно в случаях с большим объемом данных?
yopp
привет, скажите на практике часто ли используется АФ в монге? я так понял что это мощный инструмент по переносу обработки выборки с клиента на сервер.
Да, часто. Монговцы форсят идею то «aggregate is the new find».
yopp
У этого подхода есть свои плюсы и минусы
yopp
Как и везде
yopp
подскажите пожалуйста технику создания индексов в моем случае: база создается налету если это необходимо, как быть в этом случае с индексами, каждый раз вручную проверять существует ли БД?
пример кода
_, err := m.client.Database(getDbNameFromIssue(issueId)).Collection("postspins").InsertMany(context.Background(), docs)
создавть индексы в тот момент когда иницилизируется база
yopp
если вы явно этого не делаете, то тогда при старте вашего приложения
Andrey
создавть индексы в тот момент когда иницилизируется база
а можно как-то подписаться на событие создания базы, по сути она явно не инициализируется, зависит от входных данных, я не могу спрогнозировать этого
yopp
это очень плохо
yopp
так лучше не делать
Andrey
есть вариант вынести создание индексов как АПИ и дергать с другого микросервиса, который косвенно имеет отношение к будущему созданию БД, но мне не нравится такая связность
dima
Да, часто. Монговцы форсят идею то «aggregate is the new find».
спасибо.
на счет +/- вижу пока только плюсы )) чувствую практика это исправит
yopp
есть вариант вынести создание индексов как АПИ и дергать с другого микросервиса, который косвенно имеет отношение к будущему созданию БД, но мне не нравится такая связность
создавать базы на лету это вообще плохая идея
yopp
я вижу буквально несколько случаев когда это оправдано
Andrey
ну вот кейс следующий: у заказчика несколько миллиардов билетов в пакете, пакет с очередным пакетом никак не взаимодейтсвуют, пакет имеет имя, пакет представлен в виде файла с метаданными и данными, новый пакет загружается через другой микросервис раз в пару лет, после загрузки должна создаться база отыгранных билетов с именем пакета (это я так уже выбрал, потому что все в одну базу класть нет смысла), заказчику передается продукт без сопровождения в дальнейшем
yopp
«нет смысла»
yopp
ну вот вы сами смысл нашли
Andrey
база то создаваться может видимо по факту загрузки нового пакета, но в клиентском апи я не могу точно сказать что с такого-то времени все поступающие данные относятся к одному пакету, поэтому вычисляю куда писать налету
yopp
вы сами себе создали проблему и теперь героически её решаете :)
yopp
в вашем случае данные стоит хранить вообще в одной коллекции
yopp
это только первая боль, дальше будет ещё больнее
yopp
например когда надо будет строить кросс-аналитику
yopp
или просто посчитать какие-то глобальные метрики
yopp
однородные данные не стоит размазывать по разным базам
Andrey
так старые данные будут только индекс и место занимать, по сути мне их нужно будет заархивировать и положить в хранилище
Andrey
согласен, но они никак не будут пересекаться после факта закрытия одного пакета и начала следующего, из-за этого не вижу смысла их класть вместе
yopp
они будут и так и так занимать место
yopp
вы только сделаете всем хуже
yopp
вы добавили кучу динамических параметров, в те места, в которых эта динамика очень сложна в управлении
yopp
даже если данные не брать в расчёт, мы говорим о резервном копировании, об управлении доступом
yopp
проблема с архивацией, если она будет остро стоять, решается шардированием и назначением зон
Andrey
а перебалансировка на текущих вставках сильно скажется?
Andrey
допустим есть 10 мощных железяк, архивируем на другие 3 слабые
yopp
вы можете отключить балансировщик и двигать чанки руками или назначить окна
yopp
в смысле не двигать руками, а включать когда надо подвинуть
Andrey
я имею в виду фаза когда мы с одних машин начинаем гнать трафик на другие, сильно ли просаживает это основные шарды? ограничиваются ли ресурсы?
yopp
миграция чанка — чтение из коллекции
yopp
и запись в коллекцию на целевом шарде
yopp
как это повлияет на ваш конкретный деплоймент, я не могу сказать, потому что непонятно что у вас там с ёмкостью
Andrey
миграция кроме чтения нагрузки весомой на запись не дает? за исключением конечно шардов куда пишется
yopp
это всё зависит от вашего хранилища
yopp
если у вас там HDD, то чтением можно пложить и запись
yopp
я ещё раз повторю: влияние балансировки на ваш деплоймент будет зависеть от конфигурации и ёмкости вашего деплоймента
yopp
и от того что там внутри происходит
Andrey
понял. спасибо большое
попробую в одну базу писать
Pavel
привет, mongod v3.2.20, нужно в конфиге забиндить несколько ip для доступа с них.
в доках написано через запятую: To bind to multiple addresses, enter a list of comma-separated values.
на stackoverflow на подобный вопрос отвечают bindIp = [127.0.0.1, 192.168.184.155, 96.88.169.145] для монго 3.2.7
что из этого старый, а что новый вариант, как лучше? Сейчас нет возможности локально попробовать, ложить базу на N-минут не хочется
Константин
Ребят посоветуйте oodb
yopp
привет, mongod v3.2.20, нужно в конфиге забиндить несколько ip для доступа с них.
в доках написано через запятую: To bind to multiple addresses, enter a list of comma-separated values.
на stackoverflow на подобный вопрос отвечают bindIp = [127.0.0.1, 192.168.184.155, 96.88.169.145] для монго 3.2.7
что из этого старый, а что новый вариант, как лучше? Сейчас нет возможности локально попробовать, ложить базу на N-минут не хочется
Никакой разницы нет. bindIp = […] это старый формат конфигурационного файла (property), а bindIp: […, …] новый (yaml)
yopp
т.е. вам нужно указать в том формате, в котором у вас сейчас конфиг