?

https://tech.geekjob.ru/fun-mongo-1-objectid/ тут пишут что это просто функция от времени

https://tech.geekjob.ru/fun-mongo-1-objectid/ тут пишут что это просто функция от времени

там вроде еще кроме времени дополнительные параметры, + радном какой-то

https://tech.geekjob.ru/fun-mongo-1-objectid/ тут пишут что это просто функция от времени

Это не официальная документация

О каком шифровании речь?

Я про функцию Dara at rest encryption. Там указывается внешний ключ (aws, azure, gcr), которым дополнительно шифруются данные. Этот ключ действует на уровне проекта. Но мне нужно, чтобы это работало на уровне кластера или бд. Чтобы один пользователь не смог своим ключом расшифровать данные другого пользователя этого же проекта.

https://tech.geekjob.ru/fun-mongo-1-objectid/ тут пишут что это просто функция от времени

http://bsonspec.org

Я про функцию Dara at rest encryption. Там указывается внешний ключ (aws, azure, gcr), которым дополнительно шифруются данные. Этот ключ действует на уровне проекта. Но мне нужно, чтобы это работало на уровне кластера или бд. Чтобы один пользователь не смог своим ключом расшифровать данные другого пользователя этого же проекта.

Скорее всего вы ищите field level encryption

Data at rest не предполагает управления ключами на уровне базы данных, только на уровне физического хранилища

Скорее всего вы ищите field level encryption

Эта фича есть в Atlas?

Это фича драйвера, по-моему с 4.0

https://docs.mongodb.com/manual/core/security-client-side-encryption/

Спасибо!

А может ли возникуть ситуация совпадения _id двух коллекций одной БД

А может ли возникуть ситуация совпадения _id двух коллекций одной БД

Нет, _id - уникальный

Нет, _id - уникальный

Даже в контексте одной БД?

Даже в контексте одной БД?

Уникальный в рамках одной коллекции

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

Уникальный в рамках одной коллекции

Хм, даже так🧐

Тогда сорян за не правильную информацию

Чисто теоретически может пересечься между двумя разными коллекциями

Но вероятность не очень большая

Наверное вероятность равна вероятности возникновения коллизии

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

Имя коллекции там кажется не участвует.

стоит ли хранить сами изображения в mongo ? или лучше хранить ссылки на изображения?

какие тут бестпрактис?

стоит ли хранить сами изображения в mongo ? или лучше хранить ссылки на изображения?

Ссылку на изображения в монго, само изображения на хостинге лучше всего.

стоит ли хранить сами изображения в mongo ? или лучше хранить ссылки на изображения?

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

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

не представляю как переносить базу с компа на сервак, если в базе будут указаны абсолютные ссылки на папки

но относительные ссылки кажутся лютым костылём

да, вариант с размещением файлов в cdn кажется самым привлекательным

стоит ли хранить сами изображения в mongo ? или лучше хранить ссылки на изображения?

Я использую gridfs и храню в монге

Я использую gridfs и храню в монге

какие тут подводные камни?

но относительные ссылки кажутся лютым костылём

почему? если ссылка к примеру "/uploaded_images/66728dj20hi2n.jpg", то на фронте это прямо вставляется как картинка

какие тут подводные камни?

Не знаю если честно

почему? если ссылка к примеру "/uploaded_images/66728dj20hi2n.jpg", то на фронте это прямо вставляется как картинка

и отдаватся с помощью nginx?

+

если будешь мигрировать на cdn - просто скриптом проходишся по ссылкам, и меняешь их

и отдаватся с помощью nginx?

Но в любом случае у тебя будет ссылка. У меня ссылка ведет на эндпоинт который вытаскивает картинку из монги (гридфс чанков) и выдает на выходе байты картинки

если будешь мигрировать на cdn - просто скриптом проходишся по ссылкам, и меняешь их

я думаю сразу тогда замутить cdn небольшой,для последующего масштабирования проекта

Но в любом случае у тебя будет ссылка. У меня ссылка ведет на эндпоинт который вытаскивает картинку из монги (гридфс чанков) и выдает на выходе байты картинки

а если нагрузка будет огромная?

монга не отвалится?

Монга масштабируема) Не отвалится

Но в любом случае у тебя будет ссылка. У меня ссылка ведет на эндпоинт который вытаскивает картинку из монги (гридфс чанков) и выдает на выходе байты картинки

а эндпоинт на ноде? просто обычно знаю нода не очень хорошо с таким I/O справляется

типа поэтому отдачу статики ставят на nginx

типа поэтому отдачу статики ставят на nginx

+

а эндпоинт на ноде? просто обычно знаю нода не очень хорошо с таким I/O справляется

Да, на ноде, посмотрим как себя это все покажет, пока особо не нагружал

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

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

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

А objectid генерирует драйвер? Это не сама бд делает?

А objectid генерирует драйвер? Это не сама бд делает?

Она это делает только если _id не указан

Почти все драйвера генерируют на клиенте

Понял, спасибо

подскажите по такой ситуации делается запрос на поиск докуметов с limit =10 и при skip = 10, последний документ в этой выборке равен первому документу при skip=20, результат упорядочен по полю типа Date

если поле по которому идет сортировка имеет одинкавую дату - то как монга в этом случае их сортирует? не должен же этот порядок меняться при skip?

если поле по которому идет сортировка имеет одинкавую дату - то как монга в этом случае их сортирует? не должен же этот порядок меняться при skip?

https://docs.mongodb.com/manual/reference/operator/aggregation/sort/#behavior

а эндпоинт на ноде? просто обычно знаю нода не очень хорошо с таким I/O справляется

https://github.com/nieoding/nginx-gridfs

https://github.com/nieoding/nginx-gridfs

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

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

это уже другой вопрос)

а так подобный эндпоинт не сложно пишется

кстати, если у меня файлы до 16МБ, стоит хранить в обычной коллекции, или всё же лучше в GridFS?

кстати, если у меня файлы до 16МБ, стоит хранить в обычной коллекции, или всё же лучше в GridFS?

лучше в папке на диске))

думаю лучше сразу в gridfs

требования к размеру файлу поменяются и все

будешь сидеть переносить все в gridfs

лучше в папке на диске))

Не, это вообще не вариант))

Парни, а как можно "разъединить" кластер на два независимых?

Просто сделать rs.remove по каждой из репликасетов, включая конфиг-сервера?

const model = await Model.findOne({}) model.x = 1 console.log(model) // {x: 1, _id: a} await model.save() console.log(await Model.findOne({})) // {_id : a}

Почему .save() не работает?

Парни, а как можно "разъединить" кластер на два независимых?

У вас шард?

да

Вы хотите из одного шаржированного кластера сделать два шардированных кластера или хотите выделить один из шардов в репликасет?

Сделать два шардированных кластера. Идея простая - нам нужно сделать "переезд" кластера из одного расположения в другое. Для этого мы сделали реплики в новом расположении, переключили primary, указали приложению адреса новых конфиг-серверов. Теперь идея в том, чтобы "разорвать" коннект между кластерами

При этом хотелось бы, чтобы приложение не закешировало старые конфиг-сервера и шарды и не продолжало пытаться законнектится к ним

Самый простой способ, это добавить новый регион в шард, зонировать его и настроить балансировку таким образом чтоб все существующие документы начали миграцию в новую зону. Придётся шардировать все коллекции, чтоб потом шард из новой зоны пометить как primary. Дождаться окончания миграции данных в новый регион и вывести старый шард из кластера. Конфиг сервера перенести похожим образом, только через увеличение числа реплик в новом регионе. В новом регионе вам временно потребуется на две реплики больше чем в старом. После завершения initial sync, старым нодам назначить нулевой приоритет. Сделать stepDown и убедится что новый праймари в новом регионе. А у монгосов можете просто поменять записи в днсах на адреса монгосов в новом регионе м дождаться когда апдейты днс записей доедут до клиентов

А зачем зонироваться, если обычная репликация всё и так сделает?

То есть первую часть, если убрать зонирование, мы уже и сделали

Клиенты наши, на них поменяли адреса на новый кластер

Теперь вопрос просто в том, как быстро монго драйвер, в котором есть информация от нового кластера о всех его нодах - как старых так и новых, "позабудет" старые после rs.remove

Не, это вообще не вариант))

Почему?

Всем привет ✋🏻