Как mongodb хранит файлы

Обновлено: 07.07.2024

MongoDB—база данных, которая хранит данные в виде документов для использования приложением. Как правило, документы имеют структуру, подобную JSON (JavaScript Object Notation—текстовый формат обмена данными, основанный на JavaScript). Mongo—нереляционная база данных “NoSQL”. Это означает, что Mongo хранит все связанные данные в одной записи, а не хранит их во многих заранее заданных таблицах, как в базе данных SQL. Некоторые преимущества этой модели хранения заключаются в следующем:

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

Хотя существует много нереляционных баз данных, использование Mongo с JSON в качестве структуры хранения документов делает его логичным выбором при изучении бэкенда JavaScript. Доступ к документам и их свойствам подобен доступу к объектам в JavaScript.

Mongoose.js—модуль npm для Node.js, который позволяет вам писать объекты для Mongo так же, как и в JavaScript. Это может облегчить создание документов для хранения в Mongo.

Работа над задачами в этом руководстве потребует написания кода на Glitch.

Запустите этот проект на Glitch по этой ссылке или клонируйте этот репозиторий на GitHub!

Размещение бесплатного экземпляра mongodb для проектов в MongoDB Atlas

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

Чтобы создавать веб-приложения с помощью базы данных MongoDB можно использовать три пути:

Для создания базы данных MongoDB и разработки приложения использовать собственный компьютер. Для этого вы должны установить сервер Node и сервер базы данных MongoDB на своем ПК.
Для создания базы данных MongoDB использовать облачный сервис MongoDB Atlas, а приложение разрабатывать и запускать на локальном ПК. Этот способ будет рассмотрен в данной статье.
Для создания базы данных MongoDB использовать облачный сервис MongoDB Atlas, а приложение разрабатывать и запускать на каком-нибудь облачном сервисе, например Glitch.

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

Установка и настройка Mongoose и MongoDB

Дальнейшие действия предполагают, что у вас нет своего проекта, и что вы начнете с нуля.

В терминале создайте каталог myapp и сделайте его рабочим.

С помощью команды npm init создайте файл package.json .

Эта команда выдает целый ряд приглашений, например, приглашение указать имя и версию вашего приложения. На данный момент, достаточно просто нажать клавишу ВВОД, чтобы принять предлагаемые значения по умолчанию для большинства пунктов, кроме следующего:

Введите app.js или любое другое имя главного файла по своему желанию. Если вас устраивает index.js, нажмите клавишу ВВОД, чтобы принять предложенное имя файла по умолчанию.

Чтобы ваше приложение могло работать с базой данных MongoDB нужно установить драйвер. Установите драйвер MongoDB и его зависимости, выполнив в терминале из каталога myapp следующую команду.

Теперь установите модуль mongoose в каталоге myapp , набрав следующую команду в терминале.

После установки в каталоге myapp будут находится два файла package.json , package-lock.json и каталог node_modules . В файле package.json будут добавлены зависимости:

Переменные окружения в файле .env

Для хранения переменных окружения вы будете использовать файл .env . Создайте его в корне проекта и скопируйте в него URI базы данных MongoDB Atlas, полученный раннее:

Обратите внимание: URI окружен одинарными (можно двойными) кавычками; между переменной MONGO_URI и знаком = , а также, между знаком = и URI не должно быть пробела; замените на имя пользователя, а

Обратите внимание, в файле .env хранится пароль, поэтому при сохраненинии проекта в репозиторий, данный файл нужно включить в список исключений в файле .gitignore .

Для того, чтобы переменные окружения из файла env можно было использовать в приложении нужно установить пакет dotenv :

В файле package.json будет добавлена зависимость:

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

Теперь все переменные из файла .env будут доступны в process.env . Чтобы прочитать значение переменной, например, PASSWORD нужно обратиться к свойству process.env.PASSWORD .

Подключение БД MongoDB

В корне проекта создайте файл index.js , в который скопируйте следующий код.

В функции connect() первый параметр process.env.MONGO_URI - это URI для подключения приложения к БД (в данном случае значение свойства MONGO_URI хранится в файле .env ). Вторым параметром в функции connect() является необязательный объект опций. Третий параметр - это функция обратного вызова, которая будет вызвана после попытки соединения с базой данных.

Создание модели

CRUD Часть I - создание

CRUD - это сокращение для операций Create, Read, Update and Delete (создать, прочесть, обновить и удалить). Эти операции являются основными для работы с базами данных, таких как MongoDB.

В mongoose все завязано на 2х ключевых понятиях Схема(Schema) – описание сущности и Модель – сама сущность.

Создадайте схему и модель из неё.

В файл index.js скопируйте следующий код.

Каждое поле в mongoose.Schema характеризуется типом и может иметь дополнительные характеристики: default , min и max (для Number), match и enum (для String), index и unique (для индексов). Подробнее о типах можно почитать тут.

В функции mongoose.model первый параметр - это имя модели, второй параметр - имя схемы, из которой создается модель.

Схемы - это строительный блок для моделей. Модель позволяет создавать экземпляры ваших объектов, называемых документами.

Создание и сохранение записи модели

В файле index.js замените содержимое на следующий код.

В вашей базе данных теперь должен быть один документ с именем “Ivan Petrov”.

Создание нескольких записей с помощью model.create()

Выше было показано, как сохранить документ в базе данных mongodb с помощью метода mongoose save() . Но что если нужно сохранить много документов, например, из массива. Для этого можно применить другой метод mongoose - create() .

В файле index.js замените содержимое на следующий код.

Первый аргумент в методе Model.create() - это документы в виде массива или объекта, которые будут вставлены в БД. Второй аргумент - это функция обратного вызова.

В функции обратного вызова в первый аргумент err передается ошибка, а во второй аргумент users передаётся массив arrayUsers .

Использование model.find() для поиска в базе данных

В файл index.js скопируйте следующий код.

Первый параметр в функции find() - это селектор, являющийся объектом, который указывает, что нужно искать в базе данных. Если селектор не указан, возвращаются все документы из БД. Вторым параметром в функции find() является функция обратного вызова.

Функция find() находит и возвращает все документы, соответствующие селектору. Результатом будет массив документов.

Если в результате будет слишком много документов, чтобы поместиться в памяти, используйте функцию cursor()

Использование model.findOne() для возвращения одного документа из базы данных

В mongoose есть метод findOne() , который ведет себя как метод find() , но возвращает только один документ (не массив). Даже если документов с данным параметром поиска несколько метод findOne() возвращает первый найденный документ. Это особенно полезно при поиске по свойствам, которые вы объявили уникальными.

В файл index.js скопируйте следующий код.

Метод findOne() находит в базе данных первый попавшийся документ со свойством < name: "Светлана" >и возвращает его. Если в качестве первого параметра в функции findOne() ничего не указано, mongoose вернет произвольный документ.

Использование model.findById() для поиска в базе данных по id

Когда в базу данных сохраняется документ, mongodb автоматически добавляет поле _id и присваивает ему уникальный буквенно-цифровой ключ. Поиск по _id является очень частой операцией, поэтому mongoose предоставляет специальный метод для этого - findById() .

В файл index.js скопируйте следующий код.

Обновление документов в БД с помощью стандартного поиска, присвоения и сохранения

Для того, чтобы изменить (обновить) документ в базе данных, в mongoose существуют методы update , findByIdAndUpdate и findOneAndUpdate . Но сначала нелишнем будет узнать о классическом способе изменения документов. Этот способ состоит из уже изученных вами методов, а именно: findOne , findById и save .

В файл index.js скопируйте следующий код.

Обновление документов в БД с помощью model.findOneAndUpdate()

В последних версиях mongoose есть методы, упрощающие обновление документов. Но некоторые более продвинутые функции (например, хуки pre/post, валидация) ведут себя по-другому при этом подходе, поэтому классический метод все еще полезен во многих ситуациях.

В файл index.js скопируйте следующий код.

Удаление документов из MongoDB с помощью Mongoose

Для того, чтобы удалить документы из БД MongoDB в Mongoose существуют методы remove() , deleteMany() , deleteOne() , findOneAndDelete() , findByIdAndRemove() и findOneAndRemove() .

Удаление одного документа с помощью model.findByIdAndRemove

В файл index.js скопируйте следующий код.

Метод findByIdAndRemove() находит документ по Id , заданному в первом параметре, и удаляяет этот документ. Если документ найден, то он возвращается в функцию обратного вызова (в данном случае, в параметр user ). Первый параметр Id может быть определен как строка "5e25a8e88170fb0f8ce90f71" , номер 345924 или объект < _id: "5e25a8e88170fb0f8ce90f71" >.

Удаление нескольких документов с помощью model.remove()

Функция Model.remove() полезна для удаления всех документов, соответствующих заданным критериям.

Примечание: Метод remove() возвращает не удаленный документ, а объект JSON, содержащий результат операции и количество удаленных элементов.

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

Если вы не передадите функцию обратнного вызова в качестве последнего аргумента в методе Model.find() (или в других методах поиска), то запрос не будет выполнен. Запрос можно сохранить в переменной для последующего использования. Этот тип объектов позволяет построить запрос с использованием цепочечного синтаксиса. Фактический поиск в БД выполняется, когда вы окончательно прицепите метод .exec() . Вы всегда должны передавать свою функцию обратного вызова этому последнему методу. Есть много помощников запроса, здесь вы узнаете о самых “известных” из них.

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

limit(2) - Ограничивает максимальное количество документов, возвращаемых в запросе, - двумя.

MongoDB реализует новый подход к построению баз данных, где нет таблиц, схем, запросов SQL, внешних ключей и многих других вещей, которые присущи объектно-реляционным базам данных.

Со времен динозавров было обычным делом хранить все данные в реляционных базах данных (MS SQL, MySQL, Oracle, PostgresSQL). При этом было не столь важно, а подходят ли реляционные базы данных для хранения данного типа данных или нет.

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

Но, даже учитывая все недостатки традиционных баз данных и достоинства MongoDB, важно понимать, что задачи бывают разные и методы их решения бывают разные. В какой-то ситуации MongoDB действительно улучшит производительность вашего приложения, например, если надо хранить сложные по структуре данные. В другой же ситуации лучше будет использовать традиционные реляционные базы данных. Кроме того, можно использовать смешенный подход: хранить один тип данных в MongoDB, а другой тип данных - в традиционных БД.

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

Формат данных в MongoDB

Одним из популярных стандартов обмена данными и их хранения является JSON (JavaScript Object Notation). JSON эффективно описывает сложные по структуре данные. Способ хранения данных в MongoDB в этом плане похож на JSON, хотя формально JSON не используется. Для хранения в MongoDB применяется формат, который называется BSON (БиСон) или сокращение от binary JSON.

BSON позволяет работать с данными быстрее: быстрее выполняется поиск и обработка. Хотя надо отметить, что BSON в отличие от хранения данных в формате JSON имеет небольшой недостаток: в целом данные в JSON-формате занимают меньше места, чем в формате BSON, с другой стороны, данный недостаток с лихвой окупается скоростью.

Кроссплатформенность

MongoDB написана на C++, поэтому ее легко портировать на самые разные платформы. MongoDB может быть развернута на платформах Windows, Linux, MacOS, Solaris. Можно также загрузить исходный код и самому скомпилировать MongoDB, но рекомендуется использовать библиотеки с офсайта.

Документы вместо строк

Если реляционные базы данных хранят строки, то MongoDB хранит документы. В отличие от строк документы могут хранить сложную по структуре информацию. Документ можно представить как хранилище ключей и значений.

Ключ представляет простую метку, с которым ассоциировано определенный кусок данных.

Однако при всех различиях есть одна особенность, которая сближает MongoDB и реляционные базы данных. В реляционных СУБД встречается такое понятие как первичный ключ . Это понятие описывает некий столбец, который имеет уникальные значения. В MongoDB для каждого документа имеется уникальный идентификатор, который называется _id . И если явным образом не указать его значение, то MongoDB автоматически сгенерирует для него значение.

Каждому ключу сопоставляется определенное значение. Но здесь также надо учитывать одну особенность: если в реляционных базах есть четко очерченная структура, где есть поля, и если какое-то поле не имеет значение, ему (в зависимости от настроек конкретной бд) можно присвоить значение NULL . В MongoDB все иначе. Если какому-то ключу не сопоставлено значение, то этот ключ просто опускается в документе и не употребляется.

Коллекции

Если в традиционном мире SQL есть таблицы, то в мире MongoDB есть коллекции. И если в реляционных БД таблицы хранят однотипные жестко структурированные объекты, то в коллекции могут содержать самые разные объекты, имеющие различную структуру и различный набор свойств.

Репликация

Система хранения данных в MongoDB представляет набор реплик. В этом наборе есть основной узел, а также может быть набор вторичных узлов. Все вторичные узлы сохраняют целостность и автоматически обновляются вместе с обновлением главного узла. И если основной узел по каким-то причинам выходит из строя, то один из вторичных узлов становится главным.

Простота в использовании

Отсутствие жесткой схемы базы данных и в связи с этим потребности при малейшем изменении концепции хранения данных пересоздавать эту схему значительно облегчают работу с базами данных MongoDB и дальнейшим их масштабированием. Кроме того, экономится время разработчиков. Им больше не надо думать о пересоздании базы данных и тратить время на построение сложных запросов.

GridFS

Одной из проблем при работе с любыми системами баз данных является сохранение данных большого размера. Можно сохранять данные в файлах, используя различные языки программирования. Некоторые СУБД предлагают специальные типы данных для хранения бинарных данных в БД (например, BLOB в MySQL).

В отличие от реляционных СУБД MongoDB позволяет сохранять различные документы с различным набором данных, однако при этом размер документа ограничивается 16 мб. Но MongoDB предлагает решение - специальную технологию GridFS , которая позволяет хранить данные по размеру больше, чем 16 мб.

Система GridFS состоит из двух коллекций. В первой коллекции, которая называется files , хранятся имена файлов, а также их метаданные, например, размер. А в другой коллекции, которая называется chunks , в виде небольших сегментов хранятся данные файлов, обычно сегментами по 256 кб.

Для тестирования GridFS можно использовать специальную утилиту mongofiles , которая идет в пакете mongodb.

Перед тем, как углубиться в то, как MongoDB хранит данные, есть концепция, которая должна быть понятной, а именно файлы, отображаемые в Memeory.

На рисунке ниже показано, как база данных работает с базовой системой.

Файл с отображением в памяти - это ОС, которая создает файл данных в памяти через mmap, который отображает файл в область виртуальной памяти.
Для этого процесса виртуальная память является абстракцией физической памяти, а размер адресного пространства составляет 2 ^ 64.
Операционная система использует mmap для отображения всех данных, требуемых процессом, в это адресное пространство (красная линия), а затем отображает текущие данные, которые должны быть обработаны, в физическую память (серая линия)
Когда процесс обращается к определенным данным, если данные не находятся в виртуальной памяти, возникает сбой страницы, и затем ОС загружает данные с жесткого диска в виртуальную память и физическую память
Если физическая память заполнена, запускается операция выгрузки. В это время некоторые данные необходимо записать обратно на диск. Если это чистые данные памяти, они записываются обратно в раздел подкачки. Если нет, они записываются обратно на диск.

С отображенным в память файлом данные, к которым осуществляется доступ, оказываются в памяти, упрощая логику MongoDB для доступа и изменения данных.
MongoDB читает и пишет имеет дело только с виртуальной памятью, остальное оставлено для ОС
Размер виртуальной памяти = все размеры файлов + некоторые другие издержки (соединение, стек)
Если журнал включен, размер виртуальной памяти почти удвоится
Преимущества использования MMF 1: не нужно самостоятельно управлять планированием памяти и диска 2: стратегия LRU 3: во время процесса перезапуска кэш все еще там.
Недостатки использования MMF 1: фрагментация диска будет влиять на использование ОЗУ, высокая скорость чтения также повлияет на 2: невозможно оптимизировать алгоритм планирования самостоятельно, используйте только LRU

Файлы на диске состоят из экстентов, и пространство выделения также выделяется в единицах экстентов
Коллекция имеет один или несколько объектов
Запись пространства имен в файле ns указывает на первый экстент этой коллекции

При создании базы данных (на самом деле MongoDB не создает базу данных явно, она автоматически создает базу данных при записи данных в коллекцию в базе данных), MongoDB выделяет набор файлов данных, все коллекции, индексы и базу данных. Другие метаданные хранятся в этих файлах. Файл данных находится в dbpath, указанном при запуске, и по умолчанию находится в / data / db. Типичная структура файловой организации выглядит следующим образом:

Я пытаюсь найти лучшее решение для создания масштабируемого хранилища для больших файлов. Размер файла может варьироваться от 1-2 МБ и до 500-600 гигабайт.

Я нашел некоторую информацию о Hadoop, и это HDFS, но это выглядит немного сложно, потому что мне не нужны никакие карты/уменьшить задания и многие другие функции. Теперь я думаю использовать MongoDB, и это GridFS в качестве решения для хранения файлов.

а теперь вопросы:

что будет с gridfs, когда я пытаюсь написать несколько файлов одновременно. Будет ли блокировка операций чтения/записи? (Я буду использовать его только как файловое хранилище)
будут ли файлы из gridfs кэшироваться в ОЗУ и как это повлияет на производительность чтения и записи?
может быть, есть некоторые другие решения, которые могут решить мою проблему более эффективно?

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

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

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

имея это в виду, мы уже попали в первую загвоздку:

производительность чтения небольших файлов может быть потрясающей, непосредственно из ОЗУ; записи будут такими же хорошими.

единственный способ обойти это, чтобы начать положить один файл через много осколков :\ .

Примечание: еще одна вещь, чтобы рассмотреть, что средний по умолчанию размере chunks "chunk" - 256KB, так что это много документов для файла 600GB. Этот параметр можно использовать в большинстве драйверов.

GridFS, будучи только спецификацией, использует те же блокировки, что и в любой другой коллекции, блокировки чтения и записи на уровне базы данных (2.2+) или на глобальном уровне (pre-2.2). Они также мешают друг другу, то есть как вы можете обеспечить последовательное чтение документа, в который записывается?

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

Я лично обнаружил, что S3 (как сказал @mluggy) в уменьшенном формате избыточности лучше всего хранит простую часть метаданных о файле в MongoDB, так же, как с помощью GridFS, но без коллекции chunks, пусть S3 обрабатывает все это распределение, резервное копирование и другие вещи для вас.

надеюсь у меня было ясно, надеюсь, это поможет.

Edit: в отличие от того, что я случайно сказал, MongoDB не имеет блокировки уровня коллекции, это блокировка уровня базы данных.

вы рассматривали сохранение метаданных в MongoDB и запись фактических файлов в Amazon S3? Оба имеют отличные драйверы, а последний является очень избыточным, облачным/cdn-готовым хранилищем файлов. Я бы попробовал.

Я начну с ответа на первые два:

существует блокировка записи при записи в GridFS, да. Нет замка для чтения.
файлы не будут кэшироваться в памяти при запросе, но их метаданные будут.

GridFS не может быть лучшим решением для вашей проблемы. Блокировка записи может стать чем-то вроде боли, когда вы имеете дело с этим типом ситуации, особенно для больших файлов. Есть другие базы данных, которые могут решить эта проблема для тебя. HDFS-это хороший выбор, но как вы говорите, это очень сложно. Я бы рекомендовал рассмотреть механизм хранения, такой как Riak или S3 Amazon. Они больше ориентированы на хранение файлов и не имеют серьезных недостатков. S3 и Riak имеют отличные возможности администратора и могут обрабатывать огромные файлы. Хотя с Riak, последнее, что я знал, вам нужно было сделать некоторые файлы, чтобы хранить файлы более 100 МБ. Несмотря на это, как правило, лучше всего делать некоторый уровень chunking для огромных размеров файлов. Есть много плохих вещей,которые могут произойти при передаче файлов в DBs - от тайм-аутов сети, переполнения буфера и т. д. В любом случае, ваше решение потребует значительной настройки для массивных размеров файлов.

Я использую Ubuntu 16.04. Я создал базу данных MongoDB. Когда я запускаю его (с помощью команды mongod), он говорит, что база данных находится в /data/db (dbpath=/data/db).

База данных работает нормально. Но в проводнике файлов я не могу найти эту папку. Я посмотрел папку Computer и папку Home (Computer/home/<my name>).

Я также показал скрытые файлы и папки с помощью Ctrl + H.

Как я могу найти мою папку с базой данных?

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

grep dbPath /etc/mongod.conf

Согласно mongodb docs:

Значение по умолчанию путь /data/db directory

По умолчанию MongoDB прослушивает подключения от клиентов на порту 27017 и сохраняет данные в каталоге / data / db.

Если установлено dbPath, mongodb будет использовать каталог, указанный в dbPath

По умолчанию MongoDB прослушивает подключения от клиентов на порту 27017 и сохраняет данных в каталоге / data / db.

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

grep dbPath /etc/mongod.conf

Согласно mongodb docs:

Значение по умолчанию путь /data/db directory

По умолчанию MongoDB прослушивает подключения от клиентов на порту 27017 и сохраняет данные в каталоге / data / db.

Если установлено dbPath, mongodb будет использовать каталог, указанный в dbPath

По умолчанию MongoDB прослушивает подключения от клиентов на порту 27017 и сохраняет данных в каталоге / data / db.

Я нашел /etc/mongod.conf (обратите внимание, что буквы «b» нет). Там говорится: storage: dbPath: / var / lib / mongodb. И эта папка выглядит так, как будто это база данных. Также переменной является dbPath (верхний регистр «P»). Но почему, черт возьми, когда я начинаю mongod, он говорит dbpath = / data / db? – croraf 3 December 2017 в 12:00 Благодаря! Проблема заключается в выводе команды mongod «MongoDB start: pid = 2722 port = 27017 dbpath = / data / db 64-bit host = korisnik-Lenovo-Y520-15IKBN» что dbpath является / data / db. Хотя это может быть путь по умолчанию, команда запуска db должна указывать фактический путь, в моем случае / var / lib / mongodb. – croraf 3 December 2017 в 12:38 @Stennie Да, кажется, что mongodb запускается при загрузке ОС (что вы называете «услугой»). Это меня смутило. Я проверю сегодня, но, вероятно, запуск mongod дает ошибку, что порт уже связан. – croraf 4 December 2017 в 13:20

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Вы должны найти местоположение в файле конфигурации: /etc/mongod.conf

Путь по умолчанию - /data/db directory

Читайте также: