Монгодб: MongoDB Documentation

Содержание

что это за СУБД, NoSQL-система на C++

MongoDB — это документоориентированная система управления базами данных, которая не требует описания схемы таблиц. Считается одним из классических примеров NoSQL-систем, использует JSON-подобные документы и схему базы данных. Написана на языке C++.

Логотип MongoDB

MongoDB имеет открытый исходный код, она бесплатная и доступна любому разработчику. СУБД подходит для операционных систем семейства Linux, Windows и macOS. Ей можно пользоваться в облаке. Название читается как «Монго-ДБ».

Кто пользуется MongoDB

Бэкенд-разработчики веб-приложений и сайтов. В основном СУБД MongoDB используется в веб-программировании.
Специалисты в области Big Data и аналитики, которые работают с большим количеством не связанной друг с другом информации.
Разработчики в стартапах, где четко не определена структура хранения данных — в любой момент может потребоваться ее изменение.
DevOps-инженеры — иногда знание MongoDB может быть необходимо при работе с инфраструктурой проекта.
Для чего нужна MongoDB
- Хранение данных, которые не жестко связаны между собой.
- Управление данными: создание новых записей, их редактирование, удаление, контроль версий.
- Получение данных с помощью запросов без использования SQL.
- Отправка транзакций — последовательностей из нескольких запросов, которые выполняются один за другим.
- Быстрый, удобный и простой доступ к данным.
- Контроль доступа и поддержки безопасности данных.
- Выдача прав разным категориям пользователей.
- Поддержка базы в актуальном состоянии, в том числе при одновременном доступе с нескольких клиентов.
Отличие от реляционных баз данных
В реляционной базе данных информация представлена как набор связанных между собой таблиц. Доступ к данным осуществляется с помощью запросов на языке SQL. Реляционная модель — традиционная, ее используют чаще всего. Но для многих задач она неоптимальна, например, если связи между разными данными не жесткие.
В MongoDB реализована система, при которой данные хранятся в «табличных» документах форматов, близких к JSON. Информация записывается в виде пар из ключей и значений — как в таблице, в которой есть идентификаторы и соответствующие им данные. Благодаря такому формату в MongoDB можно разместить очень разнообразную и сложно структурированную информацию: документ — более гибкая структура.
При работе с такими базами SQL не используется, отсюда название NoSQL. Вместо него применяют языки программирования. В случае с MongoDB это JavaScript. Существуют драйверы для поддержки других популярных языков: Python, Java, C/C++, Go, PHP, Ruby и прочих.
Читайте также: SQL, R или Python: какой язык учить аналитику данных?
Как устроено хранение данных в MongoDB
Вместо традиционных понятий таблиц и полей в MongoDB используются свои сущности. Они отличаются от принятых в реляционных базах данных, но во многом схожи.
_id. Это идентификатор, который должен быть в каждом документе. Он помогает обращаться к тем или иным данным, по нему записи отличают друг от друга. Идентификатор создается автоматически, если его не задает программист при создании нового документа. В реляционных базах тоже есть идентификатор, но он называется иначе — первичный ключ.
Поле. Это одна запись в документе, если точнее, один ключ, метка, которой соответствует определенный набор данных. Понятие можно сравнить со столбцом в таблице реляционной базы. Например, если документ описывает данные о нескольких собаках, то в нем могут быть поля «Порода», «Кличка», «Возраст» и другие.
Описанный выше идентификатор — одно из полей, которые есть в документе, причем обязательное.
Документ. Один документ — это файл в формате BSON: название расшифровывается как binary JSON, или бинарный JSON. Отличие от стандартного JSON в том, что формат работает еще быстрее, но файлы в нем занимают меньше места.
В документе хранятся однотипные строго структурированные записи: ключи и значения. Выше мы привели пример с собаками: если документ посвящен им, то в нем будет только определенная информация о собаках и ничего другого. Его можно сравнить со строкой в таблице реляционной базы данных. Но в отличие от строки документ может хранить сложную по структуре информацию, а еще он более гибкий — для отдельных записей можно, например, опускать те или иные поля.
Максимальный размер документа — 16 Мб. Для сохранения данных большего размера используется технология GridFS, о которой мы поговорим ниже.
Коллекция. Вместо таблиц в MongoDB используются коллекции. Это наборы из документов. В одном наборе могут храниться документы с разнообразными данными — это главное отличие от таблиц. Коллекция разнородна, документы внутри нее могут различаться структурой, размером, значениями и связями. Поэтому MongoDB считается отличным выбором для хранения слабо структурированной информации.
Встроенный документ. В базах данных, которые управляются SQL, есть операция JOIN, объединяющая между собой сведения из разных таблиц. В MongoDB другая структура: обычно все находится внутри одной коллекции, а операции JOIN не предусмотрено. Для связей и разделений используются встроенные документы — структуры встраиваются друг в друга.
База данных. Так называется общее хранилище, где находятся коллекции, в которых, соответственно, расположены документы. У баз в MongoDB есть интересная особенность: когда база создана, но в нее ничего не записано, она де-факто не существует. Это отличает ее от пустых реляционных баз, которые существуют, даже если в них ничего нет.
Особенности MongoDB
Индексация. Данные внутри базы можно индексировать — так система быстрее найдет к ним доступ. Для данных создаются индексы, специальные объекты, которые хранят указатели на ту или иную информацию: обычно это конкретные значения и ссылки на них. Благодаря индексам можно реализовать поиск по базе, он не будет выглядеть как простой перебор всех данных. Это ускоряет работу системы.
Репликация.

Так называется возможность работы с репликами — копиями базы данных. Можно иметь несколько связанных друг с другом копий БД на разных серверах, и одна из них будет главной, а остальные — вспомогательными. Изменения сначала будут вноситься в главную базу, а потом передаваться другим. В итоге, если с основной копией что-то случится, любая существующая реплика сможет ее заменить — так в системе поддерживается стабильность. Замена происходит автоматически.
Сегментирование. Репликация — не единственный способ хранить базу MongoDB на разных серверах. Система поддерживает сегментирование, то есть разделение базы данных на отдельные сегменты и их распределение по разным серверам. Это позволяет балансировать нагрузку на мощности. Принцип разбиения определяет администратор, поэтому распределение по разным частям серверного кластера тоже можно спланировать.

Запросы ad hoc. Латинские слова означают «специально для этого», поэтому такие запросы еще называют специальными. Одна из особенностей MongoDB — гибкая поддержка разнообразных запросов. СУБД принимает запросы на поиск по разным полям, работает с функциями JavaScript и может возвращать пользовательские функции в ответ на запрос. Она поддерживает регулярные выражения. MongoDB позволяет получить в качестве ответа диапазон или случайное значение — запросы могут быть в том числе очень сложными.

Grid File System. Сокращенно эта технология называется GridFS, мы упоминали ее выше. Речь шла о том, что максимальный размер документа в MongoDB — 16 Мб, а технология применяется, если нужно сохранить в базу более объемные данные. По сути, это то же сегментирование, но в рамках документа. Массивные данные хранятся в двух коллекциях: files и chunks:
- files — коллекция, в которой находятся сведения о файлах. Это их имена и метаданные, содержащие информацию об объеме и других параметрах;
- chunks — коллекция, где хранятся сами файлы, но не целиком, а разбитые на небольшие сегменты. Размер каждого сегмента обычно 256 Кб, но эта цифра может меняться.
Благодаря такому разделению на маленькие составные части в базе можно хранить даже очень большие файлы. Это позволяет обойти максимальный размер документа в 16 Мб.
Преимущества MongoDB
Быстрая работа. Благодаря структуре документов, поддержке индексации и другим особенностям MongoDB работает быстро, без задержек. База производительна, часто используется во внутренних системах, на сайтах — там, где скорость имеет значение.
Гибкость. MongoDB позволяет хранить разнородные данные, поэтому она гибкая и легко адаптируется под разнообразные задачи. Например, если информация не укладывается в общую структуру или собирается разными способами и сильно различается, MongoDB все равно позволит успешно хранить ее и получать доступ.
Легкая масштабируемость. Причина, по которой MongoDB пользуются стартапы и небольшие компании, — возможность быстро и легко масштабировать систему. Если информация в базе должна измениться, например, планируется добавить новое поле, не нужно радикально перекраивать структуру всей БД. Это возможно благодаря документно-ориентированной модели и особому формату данных.
Отсутствие сложных соединений. В MongoDB не нужно описывать схему таблиц. Конструкции вроде JOIN не используются. В реляционных базах JOIN соединяет между собой данные из разных таблиц, но при документно-ориентированной модели необходимость в таких соединениях отсутствует.
Возможность работы на нескольких серверах. Это возможно благодаря механизмам репликации и сегментирования. Первый позволяет создавать работающие копии базы, которым в любой момент можно передать управление; второй помогает грамотно распределять нагрузку. Такие возможности делают работу системы стабильнее и снижают риск отказа базы в важный момент.
Недостатки MongoDB
Отсутствие хранимых процедур и функций. Хранимые процедуры — это возможность реляционных баз данных: разработчик один раз пишет набор команд на языке SQL, сохраняет его, а потом может вызвать в любой момент. Получается подобие скрипта, который выполняется по команде. Поддержка хранимых процедур в MongoDB не предусмотрена, и это не дает в полной мере автоматизировать работу с БД.
Пользовательские функции, или UDF, похожи на хранимые процедуры, но различаются особенностями сохранения и вызова. Их можно реализовать самостоятельно — функции, написанные на JavaScript, сохраняются с помощью специальной команды и позднее используются снова. Правда, это сложнее, чем возможность работать с ними «из коробки».
Неполное соответствие ACID. ACID — это набор принципов для баз данных, соответствие которым делает систему стабильной и предсказуемой. Принципов всего четыре: атомарность, согласованность, изолированность, устойчивость. MongoDB, в отличие от распространенных реляционных СУБД, соответствует им не полностью. До версии 4.0 система не отвечала требованиям атомарности — они требуют, чтобы никакая транзакция не «зависала» в системе завершенной не до конца. В более поздних версиях это исправили.
Сложности с транзакциями. Документно-ориентированный подход дает много плюсов, но из-за него сначала было затруднительно работать с транзакциями. В старых версиях их ACID-реализации не было, поэтому многие считали, что при NoSQL-подходе транзакции отсутствуют в принципе. Позже они появились, но работа по-прежнему имеет специфику.
Трудности при работе с жестко связанными данными. У разных документов внутри коллекции может быть совершенно различная структура, и сами коллекции не обязаны походить друг на друга. Это упрощает хранение слабо связанной информации, но если данные имеют жесткие связи между собой, подход перестает быть удобным. В этих ситуациях лучше отдавать предпочтение традиционным СУБД, которые работают с SQL.
Как начать работу с MongoDB
1. Скачать MongoDB на официальном сайте проекта, где компания представляет СУБД и другие решения, в том числе коммерческие. Можно воспользоваться официальным репозиторием MongoDB на GitHub или пакетным менеджером. В macOS это brew, в Linux — apt-get и другие.
2. Скачать MongoShell — шелл-оболочку, которая позволяет отдавать команды. Она скачивается отдельно и тоже есть на официальном сайте.
3. Установить MongoDB и шелл-оболочку на сервер, где будет храниться база. В реальных проектах обычно это арендованные на хостингах мощности. Создать тестовую базу данных для тренировки можно и на собственном устройстве.
Взаимодействие с базой обычно происходит через терминал. Можно подключить модули для поддержки разных языков программирования, но по умолчанию язык запросов для MongoDB — это JavaScript. Операторы, с помощью которых управляют базой данных MongoDB, основаны на нем.
Подумываете об использовании MongoDB? / Хабр
Будет ли MongoDB правильным выбором для вашего приложения?
Выбор базы данных — важный этап разработки приложения. Неправильный выбор может негативно сказаться как на процессах разработки и сопровождения вашего продукта, так и привести к снижению производительности.
В принципе, можно использовать любую базу данных, и она будет работать. Но одна база данных лучше работает с одним типом рабочей нагрузки, а другая с другим.
Не стоит выбирать MongoDB только потому, что это круто и ее используют много компаний. Вы должны понимать насколько она соответствует вашей рабочей нагрузке и ожиданиям. Поэтому выбирайте правильный инструмент.
В этой статье мы обсудим несколько возможностей MongoDB, которые стоит знать прежде чем вы решитесь выбрать и развернуть ее.
MongoDB работает с JSON-документами и разработчикам это нравится
Базовым компонентом MongoDB является документ, очень похожий на JSON. Технически это BSON, который содержит некоторые дополнительные данные (например, datetime), которые недопустимы в JSON.
Мы можем рассматривать документ как запись в реляционной базе данных. Документы помещаются в коллекции, которые соответствует концепции таблиц в реляционной базе данных.
JSON-документы очень популярны среди программистов и используются при разработке веб-сервисов, приложений и для обмена данными. Работать с базой данных со встроенной поддержкой таких данных может быть действительно эффективно.
Разработчики часто выбирают MongoDB, потому что ее можно начать использовать без специальных знаний об администрировании и проектировании баз данных, а также без изучения сложного языка запросов. Язык запросов MongoDB также представлен в формате JSON документов.
Разработчики могут легко создавать, сохранять, запрашивать и изменять JSON-документы. Здорово! Обычно это значительно ускоряет разработку.
В MongoDB нет схемы
Вы знакомы с реляционными базами данных? Наверняка да, ведь реляционные базы данных используются и изучаются уже очень давно и в школе и университете. В настоящее время на рынке это наиболее широко используемый тип баз данных.
Реляционная схема требует предопределенной и фиксированной структуры таблиц. Каждый раз, когда вы добавляете или изменяете столбец, вам необходимо выполнить DDL-запрос, и приложить дополнительные усилия, чтобы изменить код вашего приложения для работы с новой структурой. В случае значительных изменений, требующих изменения нескольких столбцов и/или создания новых таблиц, изменения в приложении могут быть весьма значительными. Отсутствие схемы в MongoDB означает, что ничего из этого не требуется. Вы просто добавляете документ в коллекцию и все. Например, у вас есть коллекция с данными пользователя. Если в какой-то момент вам нужно добавить новое поле «date_of_birth», вы просто начинаете работать с новыми JSON-документами с дополнительным полем. И все. Нет необходимости менять что-либо в схеме.
Вы также можете вставлять в одну и ту же коллекцию совершенно разные JSON-документы, представляющие разные сущности. Технически это осуществимо, но все же так делать не рекомендуется.
MongoDB также значительно сокращает цикл разработки приложения по нетехнической причине — устраняется необходимость координации миграции изменений схемы базы данных с DBA. Нет необходимости ждать, пока команда DBA еще раз все проверит и выпустит релиз в продакшн (с планами отката), что, как правило, потребует еще и некоторого простоя.
В MongoDB нет внешних ключей, хранимых процедур и триггеров. JOIN поддерживается, но не приветствуется
Проектирование реляционной базы данных должно осуществляться с учетом того, чтобы SQL-запросы могли выполнять различные JOIN для нескольких таблиц по определенным колонкам. Также необходимо предусматривать внешние ключи (foreign key) для контроля целостности данных и автоматических изменений в связанных полях.
Что насчет хранимых процедур? Хранимые процедуры могут быть полезны для встраивания в базу данных некоторой логики приложения для упрощения ряда задач или повышения безопасности.
А триггеры? Триггеры нужны для автоматического инициирования изменений данных при определенных событиях, таких как добавление / изменение / удаление строк. Они помогают управлять согласованностью данных и, в некоторых случаях, упростить код приложения. Но они отсутствуют в MongoDB. Так что имейте это в виду.
Примечание: честно говоря, есть агрегирование, которое может реализовать то же самое, что и LEFT JOIN, но это единственный случай.
Как жить без JOIN?
Соединение (JOIN) должно выполняться в коде вашего приложения. Если требуется выполнить JOIN двух коллекций, то сначала нужно прочитать первую, выбрать поле для JOIN и использовать его для запроса второй коллекции и т.д. Это кажется весьма дорогим с точки зрения разработки приложения и может привести к увеличению количества запросов. И это действительно так. Хорошая новость заключается в том, что в большинстве случаев вам не придется использовать JOIN.
Помните, что MongoDB — это база данных без схемы, не требующая нормализации. Если вы правильно спроектируете коллекции, то сможете встраивать (embed) и дублировать данные в одной коллекции без необходимости создания дополнительных коллекций. Таким образом, вам не придется выполнять соединение, потому что все данные, которые вам нужны, уже будут в одной коллекции.
Внешние ключи не поддерживаются. Но так как можно встраивать в одну коллекцию несколько документов, они вам просто не нужны.
Хранимые процедуры могут быть легко реализованы в виде внешних скриптов, написанных на любом языке программирования. Триггеры также реализуются снаружи с помощью Change Stream API.
Если у вас много коллекций, содержащих ссылки на поля, то в коде приложения вам придется реализовать много JOIN или выполнить множество проверок для обеспечения согласованности. Это все возможно, но потребует больших затрат на разработку. В этом случае MongoDB может оказаться неправильным выбором.
Очень просто развернуть репликацию и шардирование
MongoDB изначально разрабатывалась для работы в распределенных окружениях. Она была задумана как часть большого пазла. Для реализации репликации и шардирования сервер mongod может работать совместно с другими экземплярами mongod без использования каких-либо сторонних инструментов.
Replica Set (набор реплик) — это группа процессов mongod, которые обслуживают один и тот же набор данных, обеспечивая избыточность и высокую доступность. С оговорками, касающимися потенциально устаревших данных, вы также бесплатно получаете масштабируемость чтения. Для продакшн-решения всегда следует применять такую конфигурацию.
Sharding Cluster развертывается как группа из нескольких Replica Set с возможностью разделения и равномерного распределения данных по ним. В дополнение к избыточности, высокой доступности и масштабируемости чтения Sharding Cluster обеспечивает масштабируемость записи. Топология шардинга подходит для развертывания очень больших наборов данных. Количество шардов, которые вы можете добавить, теоретически не ограничено.
Обе топологии можно изменить в любое время, добавив больше серверов и шардов. Что еще более важно, никаких изменений в приложении не требуется, поскольку каждая топология полностью прозрачна с точки зрения приложения.
И, наконец, развертывание таких топологий очень просто. Вначале вам придется потратить некоторое время, чтобы понять несколько основных концепций, но затем, в течение нескольких часов, вы сможете развернуть даже очень большой кластер с шардированием. В случае нескольких серверов вместо того, чтобы делать все вручную, вы можете автоматизировать многие вещи с помощью плейбуков Ansible или других подобных инструментов.
Дополнительные материалы:
Deploy a MongoDB Replica Set with Transport Encryption (Part 1)
MongoDB Sharding 101 Webinar
В MongoDB есть индексы, и они очень важны
В MongoDB можно создавать индексы для полей JSON-документа. Индексы используются так же, как и в реляционных базах данных для ускорения выполнения запросов и уменьшения использования ресурсов компьютера: памяти, времени процессора и операций ввода-вывода в секунду (IOPS).
Для всех регулярно выполняемых запросов, операций изменения и удаления данных необходимо создавать необходимые индексы, которые помогут ускорить их выполнение.
MongoDB обладает очень мощными возможностями индексирования. Есть TLL-индексы, GEO Spatial — индексы для пространственных данных, индексы для элементов массива, частичные (partial) и разреженные (sparse) индексы. Если вы хотите подробнее изучить доступные типы индексов, вы можете обратиться к следующим статьям:
MongoDB Index Types and MongoDB explain() (part 1)
Using Partial and Sparse Indexes in MongoDB
Создавайте все необходимые индексы для ваших коллекций. Они очень помогут вам улучшить общую производительность вашей базы данных.
MongoDB требует много памяти
MongoDB интенсивно использует память. Нужно много памяти. Это относится и ко многим другим базам данных. Память, в большинстве случаев, — самый важный ресурс.
MongoDB использует оперативную память для кэширования наиболее часто и недавно используемых данных и индексов. Чем больше этот кэш, тем лучше будет общая производительность, потому что MongoDB сможет быстрее извлекать большой объем данных. Кроме того, изменения данных происходят в памяти. Запись на диск выполняется асинхронно: сначала в файл журнала (обычно в пределах 50 мс), а затем в обычные файлы данных (один раз в минуту).
WiredTiger — наиболее популярный движок хранения данных, используемый в MongoDB. Раньше это был MMAPv1, но в последних версиях он больше не доступен. Движок хранения WiredTiger использует кэш памяти (WiredTiger Cache) для кэширования данных и индексов.
Помимо WTCache, для доступа к диску MongoDB использует кэш файловой системы. Это еще одна важная оптимизация, для которой также может потребоваться значительный объем памяти.
Кроме того, MongoDB использует память для управления клиентскими соединениями, выполнения сортировки в памяти, временных данных при выполнении пайплайнов агрегации и другого.
Будьте готовы обеспечить MongoDB достаточным объемом памяти.
Но сколько нужно памяти? Эмпирическим правилом является оценка размера «рабочего набора».
«Рабочий набор» — это данные, которые чаще всего запрашиваются вашим приложением. Типичное приложение работает с ограниченным объемом данных. При обычной работе ему не нужны все данные. Например, в случае с временными рядами (time-series data), скорее всего, вам нужно будет получить только последние несколько часов или дней. Только в редких случаях вам понадобится читать более старые данные. В таком случае в вашем рабочем наборе может будут храниться данные только за несколько дней.
Предположим, что ваш набор данных составляет 100 ГБ, и вы оценили ваш рабочий набор в 20%, тогда вам потребуется как минимум 20 ГБ для WTCache.
Так как по умолчанию для WTCache используется 50% памяти (обычно мы рекомендуем не увеличивать ее значительно), то на сервере должно быть 40 ГБ памяти.
Каждый случай индивидуален, и иногда бывает трудно правильно оценить размер рабочего набора. В любом случае, основная рекомендация заключается в том, что вы должны предоставить максимальное количество памяти, которое можете себе позволить. Это будет полезно для MongoDB.
В каких случаях использовать MongoDB?
На самом деле таких ситуаций очень много. Я видел использование MongoDB в самых разных приложениях.
Например, MongoDB подходит для следующих типов приложений:
- логирование событий;
- управление контентом;
- игры;
- платежные системы;
- аналитика в режиме реального времени;
- приложения Интернета вещей;
- кеширование;
- приложения, обрабатывающие временные ряды.
И для многих других.
В принципе, вы можете использовать MongoDB практически для всего, так как это база данных общего назначения. Главное — это то, как вы ее используете.
Например, если вы планируете использовать MongoDB как реляционную базу данных с нормализованными данными, множеством коллекций и большим количеством JOIN, тогда MongoDB будет не лучшим выбором. Используйте реляционную базу данных.
Правильный способ использования MongoDB — придерживаться лучших практик и моделировать коллекции с учетом ряда правил, таких как встраивание документов вместо создания нескольких коллекций с полями-ссылками.
Percona Server for MongoDB: альтернатива с открытым исходным кодом enterprise-класса
Percona разрабатывает собственную версию MongoDB с открытым исходным кодом: Percona Server for MongoDB (PSMDB).
PSMDB — это прямая замена MongoDB Community со 100% совместимостью. PSMDB отличает то, что вы бесплатно получаете следующий enterprise-функционал:
- шифрование;
- журнал аудита;
- LDAP-аутентификация;
- LDAP-авторизация;
- редактирование журнала;
- kerberos-аутентификация;
- горячий бэкап;
- in-memory storage engine.
Без PSMDB все эти расширенные возможности доступны только в подписке MongoDB Enterprise.
Более подробную информацию о PSMDB можно найти по следующим ссылкам:
Percona Server for MongoDB Feature Comparison
Percona Server for MongoDB
Помните, что вы можете связаться с Percona в любое время, чтобы узнать подробности или получить помощь.
Заключение
Давайте подытожим, на что обращать внимание, прежде чем выбирать MongoDB в качестве базы данных для приложения.
Случаи, когда MongoDB будет хорошим выбором:
- Ваши приложения в основном работают с JSON-документами;
- Ваши данные непредсказуемы и бывают частые изменения схемы;
- Вам требуется высокая доступность и масштабируемость чтения;
- Вам нужно масштабировать данные очень большого размера;
- Требуется масштабирование из-за огромного количества операций записи.
Условие, при котором MongoDB может быть хорошим выбором, но с некоторыми ограничениями или потенциально узкими местами:
Условие, при котором MongoDB не будет хорошим выбором:
И напоследок запомните следующее:
- чем больше памяти на сервере, тем лучше;
- анализируйте ваши запросы и создавайте правильные индексы;
- постоянно мониторьте поведение базы данных;
- рассмотрите возможность внедрения PSMDB для получения базы данных enterprise-класса бесплатно;
- обращайтесь в Percona за консультациями.
Посмотрите на Percona Server for MongoDB.
Перевод материала выполнен в рамках курса «MongoDB». Если вам интересно узнать о курсе больше, приглашаем на день открытых дверей онлайн.
База данных MongoDB Atlas | Служба мультиоблачной базы данных
Самая передовая служба облачной базы данных на рынке с непревзойденным распределением данных и мобильностью в AWS, Azure и Google Cloud, встроенной автоматизацией для оптимизации ресурсов и рабочих нагрузок и многим другим.
Попробуйте бесплатно
Свяжитесь с отделом продаж
ЗНАКОМЬТЕСЬ С MONGODB ATLAS
MongoDB Atlas — это интегрированный набор служб данных, основанный на облачной базе данных, предназначенный для ускорения и упрощения процессов построения с использованием данных. Создавайте быстрее и эффективнее с помощью платформы данных для разработчиков, которая поможет решить ваши проблемы с данными.
Смотреть видео
Работайте с приложениями где угодно
Работайте с Atlas в любой точке мира. Разверните базу данных более чем в 90 регионах на AWS, Azure и Google Cloud и расширяйте ее до глобальной, мультирегиональной или мультиоблачной, когда вам это нужно. Прикрепите данные к регионам для строгого соответствия и сверхнизкой задержки.
Подробнее
Уверенное масштабирование операций
Уверенное строительство. Atlas поставляется со встроенными передовыми практиками и интеллектуально автоматизирует критические операции, чтобы обеспечить безопасность ваших данных и правильное функционирование базы данных.
Подробнее
Уменьшение сложности архитектуры
Получите доступ к своим данным и запросите их для любого варианта использования с помощью унифицированного API запросов. Данные, хранящиеся в Atlas, мгновенно доступны для использования с остальной частью нашей платформы, от полнотекстового поиска до аналитики и визуализации.
Узнать больше
Сосредоточьтесь на поставляемых функциях
Поддерживайте работоспособность ваших приложений, независимо от того, утроится ли трафик или будут добавлены новые функции. Atlas предлагает расширенные инструменты оптимизации производительности, поэтому у вас всегда будут ресурсы базы данных, необходимые для дальнейшего развития.
Подробнее
Обзор функций
Несколько регионов, несколько облаков
Запускайте мощные и отказоустойчивые приложения, которые охватывают несколько регионов или облаков одновременно.
Бессерверная и эластичная
Разверните бессерверную базу данных и платите только за используемые ресурсы.
Постоянная защита
Защитите данные с помощью встроенных настроек по умолчанию для доступа и сквозного шифрования.
Рекомендации по производительности
Получайте по запросу рекомендации по проектированию индексов и схем по мере роста вашей рабочей нагрузки.
Собственные инструменты
Подключитесь к базе данных из командной строки или с помощью предпочитаемого вами языка.
Автоматическое распределение данных по уровням
Установите правила архивирования для экономичного хранения данных по мере роста объема данных.
Непрерывное резервное копирование
Восстанавливайте данные в нужный момент с помощью восстановления на определенный момент времени.
Изоляция рабочей нагрузки
Оптимизация локального чтения или запуск аналитики с помощью выделенных вторичных узлов.
Работать легко, когда все является объектом
Мы создали нашу базу данных как разработчики для разработчиков. Поэтому мы всегда хотим убедиться, что у вас есть инструменты, необходимые для создания быстрее, больше и лучше.
Просмотр документации
Развертывание базы данных
Создание облачной базы данных за считанные секунды с помощью пользовательского интерфейса Atlas, интерфейса командной строки, оператора Kubernetes или поставщика ресурсов «инфраструктура как код» (IaC). Поэкспериментируйте с бесплатным кластером, запустите бессерверный экземпляр или настройте выделенную конфигурацию кластера.
Начало работы с Atlas
Запрос данных любой структуры
Наш унифицированный API запросов упрощает работу с любыми современными данными, такими как массивы, геопространственные данные, временные ряды и многое другое. Запрашивайте, преобразовывайте и анализируйте данные по мере развития вашей схемы.
Узнайте об API запросов MongoDB
Создайте свой путь
Создавайте запросы с помощью MongoDB Shell, Compass или непосредственно на выбранном вами языке программирования.
Просмотр всех языковых библиотек
Развертывание базы данных
Создайте облачную базу данных за считанные секунды с помощью пользовательского интерфейса Atlas, интерфейса командной строки, Kubernetes Operator или поставщика ресурсов «инфраструктура как код» (IaC). Поэкспериментируйте с бесплатным кластером, запустите бессерверный экземпляр или настройте выделенную конфигурацию кластера.
Начало работы с Atlas
MongoDB Atlas CLI
HashiCorp Terraform
AWS CloudFormation
Оператор Kubernetes
Фрагмент кода
Данные запроса любая структура
Наш унифицированный API запросов упрощает работу с любыми современными данными, такими как массивы, геопространственные данные, временные ряды и многое другое. Запрашивайте, преобразовывайте и анализируйте данные по мере развития вашей схемы.
Узнать об API запросов MongoDB
MongoDB Atlas CLI
HashiCorp Terraform
AWS CloudFormation
Оператор Kubernetes
Фрагмент кода
Создайте свой путь
Создавайте запросы с помощью MongoDB Shell, Compass или непосредственно в программе язык выбора.
Просмотр всех языковых библиотек
CLI MongoDB Atlas
HashiCorp Terraform
AWS CloudFormation
Оператор Kubernetes
Фрагмент кода
MongoDB Atlas CLI
HashiCorp Terraform
AWS CloudFormation
Оператор Kubernetes
Фрагмент кода
Создавайте невероятное программное обеспечение с помощью Atlas
Узнайте, как максимально эффективно использовать нашу платформу данных для разработчиков.
Базовое администрирование кластера
Узнайте, как развернуть бесплатную базу данных и загрузить образцы данных с помощью MongoDB.
Получите максимум от Atlas
Расширьте возможности работы с данными и аналитических данных с помощью остальной части нашей платформы данных для разработчиков.
Начните работу с Atlas сегодня
Начните работу за считанные секунды. Наши бесплатные кластеры поставляются с хранилищем объемом 512 МБ, так что вы можете поэкспериментировать с образцами данных и сориентироваться на нашей платформе.
Попробуйте бесплатно
Свяжитесь с отделом продаж
НАЧНИТЕ С:
- Более 95 регионов мира
- Примеры наборов данных
- Постоянная аутентификация
- Сквозное шифрование
- Средства командной строки