17 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

MySQL и MongoDB — когда и что лучше использовать

Содержание

Разница между SQL и NoSQL: MySQL и MongoDB

При выборе базы данных предстоит принять важное решение: остановиться на реляционной (SQL) или нереляционной (NoSQL) структуре БД. Оба этих варианта вполне жизнеспособны, но между ними есть различия, которые пользователи должны учитывать при принятии решения. В этой статье мы рассказываем, в чем состоит разница SQL и NoSQL, а также обсуждаем еще две важные вещи: выбрать MySQL или MongoDB.

Основные различия

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

А теперь представьте другой город Б, в котором все дома говорят на разных языках. Все по-разному взаимодействуют с миром, нет никакого «универсального» способа понимания или устойчивой организации общения. Если один что-то изменит, это ни на кого не повлияет.

Этот пример помогает проиллюстрировать одно из основных различий между SQL (реляционной) и NoSQL (нереляционной) базами данных. Из него уже можно сделать определённые выводы.

Реляционные базы данных используют язык структурированных запросов (SQL) для того, чтобы обрабатывать данные и управлять ими. С одной стороны, это довольно удобно: SQL — один из наиболее разносторонних и общеупотребимых вариантов, так что это безопасный выбор. Также этот язык подходит для сложных запросов. С другой стороны, с этим языком идут определенные ограничения. В SQL нужно использовать заданные наперед схемы и определять структуру данных перед началом работы с нею. К тому же, все данные должны иметь одну и ту же структуру. Как в случае с городом А, перемена в структуре может обернуться сложностями и разрушить всю систему.

Нереляционные базы данных, напротив, обладают гибкими схемами для неструктурированных данных. Они могут храниться по-разному: в колонках, документах, графах или в виде хранилища «ключ-значение». Эта гибкость позволяет:

  • Можно создавать документы, не определяя их структуру заранее;
  • Каждый документ может обладать собственной уникальной структурой;
  • Синтаксис может различаться в разных базах данных;
  • В процессе работы можно добавлять новые поля.

Масштабируемость

В большинстве случаев SQL БД можно масштабировать вертикально, то есть можно проводить увеличение нагрузки на каждом отдельном сервере, повышая мощности ЦП, ОЗУ, твердотельного диска. А вот NoSQL БД можно масштабировать горизонтально. Это значит, что нагрузка распределяется благодаря разделению данных или добавлению большего количества серверов. Это как если бы вы добавляли больше этажей к зданию либо добавляли больше зданий к району. В последнем варианте система может получиться более крупной и мощной. Именно поэтому для крупных или часто меняющихся БД обычно выбирают NoSQL.

Структура

SQL БД имеют форму таблиц, а в NoSQL БД данные представляются в виде документов, пар «ключ-значение», графов или хранилищ wide-column. Из-за этого реляционные (SQL) базы лучше использовать для приложений, в которых нужно переходить между несколькими записями (например, система бухучета), или для систем устаревшего вида, которые при создании имели реляционную структуру.

Примерами SQL БД являются ySQL, Oracle, PostgreSQL и Microsoft SQL Server, а NoSQL БД — MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.

SQL против NoSQL: MySQL либо MongoDB

Раз уж мы разобрались, в чем состоит разница SQL и NoSQL, рассмотрим ключевые различия между ними на примере MySQL и MongoDB.

MySQL: SQL (реляционная) база данных

Ниже представлены сильные стороны MySQL:

  • Сформированность: MySQL — хорошо известная база данных, то есть она обладает крупным коммьюнити, широкими возможностями тестирования и стабильностью;
  • Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у нее есть адаптеры для таких языков, как Node.js, Ruby, C#, C++, Java, Perl, Python и PHP, то есть эта система не ограничена языком запросов SQL;
  • Экономичность: Система является открытой и бесплатной;
  • Воспроизводимость: Базу данных MySQL можно использовать на разных узлах, что позволяет снизить нагрузку и повысить масштабируемость и доступность приложения;
  • Разделение данных: Несмотря на то что эту процедуру можно проводить на не всех SQL БД, серверы MySQL позволяют это сделать. Это не только экономично, но и может быть полезно для приложения.

MongoDB: NoSQL (нереляционная) база данных

Ниже представлены сильные стороны MongoDB:

  • Динамичность: Как говорилось ранее, динамическая схема гарантирует гибкость, позволяющую менять структуру без редактирования существующих данных;
  • Масштабируемость: MongoDB можно масштабировать горизонтально, благодаря чему уменьшается нагрузка для бизнеса;
  • Легкость в управлении: Для этой базы данных не требуется администратор. Так как она достаточно дружелюбна в отношении юзеров, воспользоваться ей могут как разработчики, так и администраторы;
  • Скорость: Эта БД показывает отличные результаты в работе с короткими запросами;
  • Гибкость: В MongoDB можно добавлять новые столбцы и поля, не влияя на уже существующие записи и производительность приложения.

Какую базу данных выбрать для своего проекта?

MySQL — отличный выбор для любого приложения, которому будет удобно пользоваться ее заранее определенной структурой и готовыми схемами. Например, это касается приложений, которые осуществляют переходы между нескольким записями (системы бухучета или управления инвентарем) или основаны на устаревших системах (им подойдет структура MySQL).

MongoDB, напротив, подойдет для бизнесов с быстрым ростом или для баз данных, в которых не используются определенные схемы. Точнее, если у вас не получается определить схему для БД или структуры постоянно меняются (как часто бывает с мобильными приложениями, аналитикой, работающей в реальном времени, системами менеджмента контента и т. д.), выбирайте MongoDB.

SQL против NoSQL на примере MySQL и MongoDB

SQL против NoSQL на примере MySQL и MongoDB

  • Переводы , 24 сентября 2018 в 18:50
  • Corewood

Когда необходимо выбрать СУБД, главный вопрос обычно заключается в выборе реляционной (SQL) или нереляционной (NoSQL) структуры. У обоих вариантов есть свои преимущества, а также несколько ключевых особенностей, которые стоит иметь в виду при выборе.

Основные различия

Представьте себе город — пусть он называется Город А, где все говорят на одном языке. Все дела ведутся на нём, он используется в любой форме коммуникации — в целом это единственное средство взаимодействия и взаимопонимания для обитателей города. Изменение языка в любой из сфер деятельности собьёт всех с толку.

Теперь представьте Город Б, где все обитатели говорят на разных языках. Они совершенно по-разному взаимодействуют с окружающим миром, и для них не существует «универсального» средства общения.

Эти два примера наглядно демонстрируют различия между реляционными и нереляционными базами данных, и за этими различиями скрываются ключевые особенности обеих СУБД.

Реляционные базы данных используют структурированный язык запросов (Structured Query Language, SQL) для определения и обработки данных. С одной стороны, это открывает большие возможности для разработки: SQL один из наиболее гибких и распространённых языков запросов, так что его выбор позволяет минимизировать ряд рисков, и будет особенно кстати, если предстоит работа с комплексными запросами. С другой стороны, в SQL есть ряд ограничений. Построение запросов на этом языке обязывает предопределять структуру данных и, как в случае с Городом А, последующее изменение структуры данных может быть губительным для всей системы.

Нереляционные базы данных, в свою очередь, предлагают динамическую структуру данных, которые могут храниться несколькими способами: ориентированно по колонкам, документо-ориентированно, в виде графов или на основе пар «ключ-значение». Такая гибкость означает следующее:

  • Вы можете создавать документы, не задавая их структуру заранее;
  • Каждый документ может обладать собственной структурой;
  • У каждой базы данных может быть собственный синтаксис;
  • Вы можете добавлять поля прямо во время работы с данными.

Масштабируемость

В большинстве случаев SQL базы данных вертикально масштабируемые, то есть вы можете увеличивать нагрузку на отдельно взятый сервер, наращивая мощность центральных процессоров, объёмы ОЗУ или системы хранения данных. А NoSQL базы данных горизонтально масштабируемы. Это означает, что вы можете увеличивать трафик, распределяя его или добавляя больше серверов к вашей СУБД. Всё равно, что добавлять больше этажей к вашему зданию, либо добавлять больше зданий на улицу. Во втором случае, система может стать куда больше и мощнее, делая выбор NoSQL базы данных предпочитаемым для больших или постоянно меняющихся структур данных.

Структура

В реляционных СУБД данные представлены в виде таблиц, в то время как в нереляционных — в виде документов, пар «ключ-значение», графов или wide-column хранилищ. Это делает SQL базы данных лучшим выбором для приложений, которые предполагают транзакции с несколькими записями — как, например, система учётных записей — или для устаревших систем, которые были построены для реляционных структур.

26 мая в 18:00 в 18:00, онлайн, беcплатно

В число СУБД для SQL баз данных входят MySQL, Oracle, PostgreSQL и Microsoft SQL Server. Для работы с NoSQL подойдут MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.

SQL vs. NoSQL: MySQL или MongoDB

Разобравшись с ключевыми структурными различиями SQL и NoSQL баз данных, стоит внимательно рассмотреть их функциональные особенности на примере MySQL и MongoDB.

MySQL: реляционная СУБД

  • Проверено временем: MySQL — крайне развитая СУБД, что означает наличие большого сообщества вокруг неё, множество примеров и высокую надёжность;
  • Совместимость: MySQL доступна на всех основных платформах, включая Linux, Windows, Mac, BSD и Solaris. Также у неё есть библиотеки для языков вроде Node.js, Ruby, C#, C++, Java, Perl, Python и PHP;
  • Окупаемость: Это СУБД с открытым исходным кодом, находящаяся в свободном доступе;
  • Реплицируемость: Базу данных MySQL можно распределять между несколькими узлами, таким образом уменьшая нагрузку и улучшая масштабируемость и доступность приложения;
  • Шардинг: В то время как шардинг невозможен на большинстве SQL баз данных, MySQL является исключением.

MongoDB: нереляционная СУБД

  • Динамическая схема: Как упоминалось выше, эта СУБД позволяет гибко работать со схемой данных без необходимости изменять сами данные;
  • Масштабируемость: MongoDB горизонтально масштабируема, что позволяет легко уменьшить нагрузку на сервера при больших объёмах данных;
  • Удобство в управлении: СУБД не нуждается в отдельном администраторе базы данных. Благодаря достаточному удобству в использовании, ей легко могут пользоваться как разработчики, так и системные администраторы;
  • Скорость: Высокая производительность при выполнении простых запросов;
  • Гибкость: В MongoDB можно без вреда для существующих данных, их структуры и производительности СУБД добавлять поля или колонки.

Какую СУБД выбрать?

MySQL — верный выбор для любого проекта, который может положиться на предопределённую структуру и заданные схемы. С другой стороны, MongoDB — отличный вариант для быстрорастущих проектов без определённой схемы данных. В особенности если вы не можете определить схему для своей базы данных, вам не подходит ни одна из предлагаемых другими СУБД или в вашем проекте она постоянно меняется, как, например, в случае с мобильными приложениями, системами аналитики в реальном времени или контент-менеджмента.

MongoDB для начинающих: знакомство и установка (часть 1/3)

MongoDB — это система управления базами данных, которая значительно отличается от MySQL. Основная разница заключается в том, что в MySQL запросы пишутся на языке SQL, а в MongoDB на BSON (бинарный JSON). Это значит, что работа с этой системой может осуществляться в основном через JavaScript выражения.

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

  • Установка и запуск MongoDB на Windows
  • Работа с MongoDB через консоль
  • Интеграция MongoDB и PHP

Разработчикам не составляет труда быстро освоить работу с Mongo, если они знакомы с JSON. Этот формат использует выражения, которые состоят из пар “ключ”: “значение”.

Почему MongoDB

Между не табличными СУБД многие пользователи делают выбор в пользу MongoDB. Во-первых, данную систему можно установить практически на всех операционных системах (Windows, OSX, Linux). Во-вторых, проект до сих пор активно развивается и с завидной частотой команда разработчиков публикует обновления. Также мне кажется, что MongoDB предоставляет хорошую документацию для начинающих.

MongoDB лучше подходит в тех случаях, когда таблицы можно представить в виде объектов. По-моему, подобные системы лучше использовать при разработке приложений для мобильный устройств. В этом плане, Mongo предоставляет отдельные библиотеки, как для iOS, так и для Adndroid-а.

Ещё один весомый аргумент в пользу MongoDB: работать с данной системой можно на многих языках программирования, таких как C/C++, Python, PHP, Rubym Perl, .NET и даже Node.js.

MongoDB — это реальное решение, если вы хотите отступить от SQL и попробовать что-то новенькое.

Ключевая терминология

Перед тем как приступить к установке MongoDB, давайте разберёмся с основными понятиями.

Как и MySQL, MongoDB может содержать множество баз данных, только вместо таблиц они содержат “коллекции”.

Коллекция — это что-то типа таблицы, только без колонок. Вместо этого каждая строка содержит наборы записей в виде ключ:значение.

Пример:

Внутри коллекции Users (пользователи) может располагаться запись с ключами firstname (имя) и lastname (фамилия). В то же время, та же коллекция может содержать запись с другими ключами: firstname, lastname, e-mail, birth (день рождения). В этом-то и заключается гибкость MongoDB.

Каждая из этих записей, или строк, называется “документ”, но это не тот документ типа .txt или .html. Данная запись хранится в памяти в JSON формате.

Пример:

Предположим, в нашей коллекции содержится 500 документов. Как уже говорилось раньше, каждый из них может содержать разные поля. Единственное поле, которое должно быть у каждой записи, — это уникальный идентификатор (id), который добавляется автоматически.

Поначалу данная терминология может быть непривычной. Всё будет намного понятнее, когда вы увидите работу с СУБД на практике.

Установка MongoDB на Windows

Сперва качаем архив с MongoDB для win32 или win64.

Распаковываем скачанный архив и помещаем его, к примеру, на диск C, в каталог mongodb. Причём, проследите за тем, чтобы каталог bin был доступен по адресу C:mongodbbin .

Далее прописываем путь к папке bin в настройках нашей ОС, для того чтобы к .exe файлам данной папки мы могли достучаться из любого места. Итак, делаем правый клик на Компьютер — Свойства. В списке слева, выбираем “Дополнительные параметры системы”:

Далее, нажимаем на кнопку “Переменные среды”:

В открывшемся окне ищем системную переменную Path. Кликаем по ней дважды. В поле “значение переменной” переходим в самый конец, ставим знак “;” и вписываем путь к каталогу bin:

Отлично! Жмём “ок”. и переходим к следующему шагу.

Для начала, нам необходимо создать каталог, где будут храниться наши БД. К примеру, C:databases . Создаём эту папку.

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

Данная команда создаст специальный лог файл и настройки конфигурации для сервиса.

Далее создаём сервис:

Прежде чем запустить его, давайте отредактируем файл mongod.cfg , вписав туда настройку dbpath — путь к папке с нашими базами данных. В моём случае, после правки файла его содержание должно выглядеть примерно так:

Возвращаемся к командной строке и запускаем сервис MongoDB:

Для того чтобы проверить, будет ли сервис запускаться автоматически, нажимаем сочетание клавиш “windows+r”, пишем “services.msc”, нажимаем ОК.

В списке сервисов ищем MongoDB и, если его тип запуска не автоматический, то выставляем данный пункт, предварительно сделав правый клик, и выбрав, “свойства”.

Теперь, когда мы создали сервис, который будет запускать MongoDB при включении компьютера, нам не нужно будет делать это вручную.

Для проверки работы MongoDB открываем командную строку и пишем:

Нажимаем Enter. Далее можем работать с данной СУБД. К примеру, посмотрим, какие сейчас у нас есть базы:

В ответе вы должны увидеть вот такую вот строку:

Итак, MongoDB установлена и сконфигурирована. В следующей части мы рассмотрим основные команды для работы с данной СУБД.

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://www.hongkiat.com/blog/webdev-with-mongodb-part1/
Перевел: Станислав Протасевич
Урок создан: 3 Апреля 2013
Просмотров: 104039
Правила перепечатки

5 последних уроков рубрики «PHP»

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Когда использовать MongoDB или другие системы, ориентированные на документы?

Мы предлагаем платформу для видео- и аудио-клипов, фотографий и векторных изображений. Мы начали с MySQL в качестве базы данных и недавно включили MongoDB для хранения всей метаинформации файлов, поскольку MongoDB лучше соответствует требованиям. Например: фотографии могут иметь Exif, у видео могут быть звуковые дорожки, где мы хотим также хранить метаинформацию. Видео и векторная графика не имеют общей метаинформации и т.д., Поэтому я знаю, что MongoDB идеально подходит для хранения этих неструктурированных данных и сохранения их в поиске.

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

Итак, возникает вопрос: когда использовать MongoDB и когда использовать СУРБД. Что бы вы взяли, mongoDB или MySQL, если бы у вас был выбор и почему вы его принимали?

MongoDB не является хранилищем ключей/значений, его немного больше. Это определенно не RDBMS. Я не использовал MongoDB в производстве, но я использовал его немного для создания тестового приложения, и это очень классный кусок набора. Кажется, он очень эффективен и либо имеет, либо скоро будет отказоустойчивостью и авто-осколками (он же будет масштабироваться). Я думаю, что Монго может быть самым близким к замене РСУБД, которую я видел до сих пор. Он не будет работать для всех наборов данных и шаблонов доступа, но он создан для вашего типичного материала CRUD. Хранение того, что по существу является огромным хэшем, и возможность выбора на любом из этих ключей, — это то, что большинство людей используют реляционную базу данных. Если ваша БД — 3NF, и вы не делаете никаких подключений (вы просто выбираете кучу таблиц и объединяете все объекты, AKA, что большинство людей делают в веб-приложении), MongoDB, вероятно, зацепит вас за вас.

Тогда в заключении:

Реальная вещь, которую следует отметить, заключается в том, что если вы отвлекаетесь от создания чего-то супер-потрясающего, потому что вы не можете выбрать базу данных, вы делаете это неправильно. Если вы знаете mysql, просто используйте его, Оптимизируйте, когда вам действительно нужно. Используйте его как магазин k/v, используйте его как rdbms, но, ради бога, создайте свое приложение-убийца! Ничто из этого не имеет значения для большинства приложений. Facebook все еще использует MySQL, много. Википедия использует MySQL, много. FriendFeed использует MySQL, много. NoSQL — отличный инструмент, но его, конечно же, не будет вашим конкурентным преимуществом, его не будет делать ваше приложение горячим, и, самое главное, ваши пользователи не будут заботиться об этом.

На что я буду строить следующее приложение? Возможно, Postgres. Я буду использовать NoSQL? Может быть. Я мог бы также использовать Hadoop и Hive. Я мог бы хранить все в плоских файлах. Возможно, я начну взламывать Маглева. Я использую все, что лучше всего подходит для работы. Если мне нужна отчетность, я не буду использовать какой-либо NoSQL. Если мне нужно кэширование, я, вероятно, воспользуюсь Tokyo Tyrant. Если мне нужна ACIDity, я не буду использовать NoSQL. Если мне нужна тонна счетчиков, я использую Redis. Если мне нужны транзакции, я использую Postgres. Если у меня есть тонна одного типа документов, я, вероятно, использую Mongo. Если мне нужно написать 1 миллиард объектов в день, Id, вероятно, использует Волдеморт. Если мне нужен полнотекстовый поиск, Id, вероятно, использует Solr. Если мне нужен полнотекстовый поиск волатильных данных, Id вероятно использует Sphinx.

Мне нравится эта статья, я нахожу ее очень информативной, она дает хороший обзор ландшафта и шумихи NoSQL. Но, и что самая важная часть, это действительно помогает задавать себе правильные вопросы, когда дело касается выбора между РСУБД и NoSQL. Стоит прочитать IMHO.

Использование Mongodb и Mysql в одном проекте

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

Однако я буду использовать некоторые соединения для некоторых частей проекта, и я не уверен, сохраняю ли я информацию пользователя в Mongodb или нет. Я слышал, что некоторые проблемы могут возникнуть в mongodb во время процесса написания. должен ли я использовать только mongodb с коллекциями (вместо join) или оба из них?

3 Ответа

Вы не будете JOINing между MongoDB и MySQL.

Я не уверен, что согласен со всеми вашими утверждениями. Относительная скорость-это то, что лучше всего сопоставить с вашим вариантом использования.

На самом деле вам нужно понять, каковы относительные сильные и слабые стороны этих двух баз данных:

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

Они должны быть основой для вашего выбора.

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

  • RDBMS для чрезвычайно активного OLTP
  • NoSQL
  • проект datawarehousing/BI

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

IMO хранение пользовательских данных в mongodb прекрасно — вы можете выполнять атомарные операции с отдельными документами BSON, поэтому операции, подобные «allocate me this username atomically», выполнимы. С помощью redo logs (—journal) (v1.8+), репликации, slavedelayed replication можно иметь довольно высокую степень безопасности данных-такую же высокую, как и другие продукты БД на бумаге. Главным аргументом против безопасности был бы новый продукт, а старое программное обеспечение всегда безопаснее.

Если вам нужно сделать очень сложные операции ACID — например, бухгалтерский учет-используйте RDBMS.

Кроме того, если вам нужно сделать много отчетов, mysql может быть лучше в данный момент, особенно если набор данных помещается на одном сервере. Утверждение SQL GROUP BY довольно мощное.

MongoDB имеет некоторые приятные функции для поддержки работы с геолокацией. Однако это не обязательно быстрее из коробки, чем MySQL. Было проведено множество контрольных тестов, которые показывают, что MySQL во многих случаях превосходит MongoDB (например, http://mysqlha.blogspot.com/2010/09/mysql-versus-mongodb-yet-another-silly.html ).

Тем не менее, у меня до сих пор не было проблемы с MongoDB потерей информации во время написания. Я бы предложил, чтобы, если вы хотите использовать MongoDB, вы также использовали if для пользователей, что позволит избежать необходимости пересекать базу данных ‘associations’, а затем только переносить пользователей в MySQL, если это станет необходимым.

Похожие вопросы:

У меня есть REST API в NodeJS и Экспресс JS. Вот основная вещь, которую мне нужно реализовать. В mysql есть база данных, и мой узел js server читает базу данных в некоторых определенных условиях и.

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

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

Есть ли смысл использовать комбинацию MySQL и MongoDB. То, что я пытаюсь сделать в основном, это использовать MySQl как тип raw data backup, где все данные хранятся там, но не читаются оттуда.

Я создаю приложение Rails, которое использует MySQL для некоторых моделей и MongoDB для других (через mongo_mapper gem). Мы начали строить тесты cucumber (с capybara и webdriver) для приложения и.

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

В нашем текущем проекте мы используем MongoDB. Недавно появилась просьба перейти на Postgres. Мы не хотим отбрасывать MongoDB и просто мигрировать в Postges сразу. Было бы здорово иметь какой-то.

Я работаю над проектом front-end, основанным на React. Мне просто интересно, есть ли возможность объединить использование Bootstrap 3 и Flexbox в одном проекте, поскольку я хотел бы использовать как.

Я новичок в meteor и mongodb. Я просто хочу знать, как проверить версию mongodb в моем проекте meteor. Когда я проверяю его на использование robomongo, он показывает 2.6.7. Может ли быть две версии.

Возможно ли иметь Postgresql и MongoDB в одном проекте ? Я хотел бы иметь возможность использовать генераторы для обоих, а также.

Ответы на вопросы на собеседование MongoDB.

  • Что такое NoSQL?

NoSQL (Not only SQL) — это ряд технологий, подходов, проектов направленных на реализацию моделей баз данных, имеющих существенные отличия от традиционных СУБД, работающих с языком SQL. Концепция NoSQL не отрицает SQL, она лишь стремится решить проблемы и вопросы, с которыми не достаточно хорошо справляется РСУБД. Чаще всего данные в NoSQL решении представляются в виде хеш-таблиц, деревьев, документов и пр.

  • Какие есть типы хранилищ данных в NoSQL?

  • «ключ-значение» (key-value store)
  • документно-ориентированные (document store)
  • хранилища семейств колонок (column database)
  • графовые базы данных (graph database).

  • Что такое MongoDB?

MongoDb — это документо-ориентированная база данных, в отличие от традиционных реляционных баз данных, таких как MySQL или PostgreSQL не использует табличный способ представления со связями через внешние ключи, основанная на принципе хранении документов в BSON(Binary JSON) формате. Т.е. каждая запись это документ, без жестко заданной схемы, который может содержать вложенные документы.

  • На каком языке написана MongoDB?

MongoDB написана и реализована на С++.

  • Какие языки программирования можно использовать с MongoDB?

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

  • Использует ли таблицы для хранения данных, база данных MongoDB?

Нет. Для хранения данных вместо таблиц, MongoDB использует «Коллекции» (collections).

  • Какие преимущества MongoDB?

  • Документо-ориентированное хранилище (простая и мощная JSON-подобная схема данных)
  • Достаточно гибкий язык для формирования запросов
  • Динамические запросы
  • Полная поддержка индексов
  • Профилирование запросов
  • Быстрые обновления «на месте»
  • Эффективное хранение двоичных данных больших объёмов, напр., фото и видео
  • Журналирование операций, модифицирующих данные в БД
  • Поддержка отказоустойчивости и масштабируемости: асинхронная репликация, набор реплик и шардинг
  • Может работать в соответствии с парадигмой MapReduce
  • Имеет распределенный доступ к данным, расположенных на нескольких серверах

  • Какие недостатки MongoDB?

  • Отсутствует оператор «join». Обычно данные могут быть организованы более денормализованным способом, но на разработчиков ложится дополнительная нагрузка по обеспечению непротиворечивости данных.
  • Нет такого понятия, как «транзакция». Атомарность гарантируется только на уровне целого документа, т.е. частичное обновление документа произойти не может.
  • Отсутствует понятие «изоляции». Любые данные, которые считываются одним клиентом, могут параллельно изменяться другим клиентом.
  • Менее чем более стабильна, не рекомендовано использовать в биллинге
  • Требовательна к ресурсам — память и место на диске

  • Что такое пространство имен в MongoDB?

Пространство имен в MongoDB это конкатенация имени базы данных и названия коллекции. Для например school.students, где school — имя базы данных и students — название коллекции.

  • Что такое репликация?

  • реплисеты(Replica Sets )
  • ведущий-ведомый(Master-Slave).

  • Поддерживает ли MongoDB ограничения внешнего ключа(foreign key)?

  • Как мы можем достичь primary key — foreign key отношения в MongoDB?

По умолчанию MongoDB не поддерживает primary key — foreign key отношения. Тем не менее, мы можем достичь этой концепции путем встраивания одного документа внутри другого. Для например документ «адрес» может быть встроен внутри документа «клиент».

  • Объясните структуру ObjectID в MongoDB.

  • Первые 4 байта, представляющие секунды с эпохи Unix
  • Следующие 3 байта являются идентификатором машины
  • Следующие 2 байта являются идентификатором процесса
  • Последние 3 байта ето случайная величина счетчика:

Для создания нового ObjectID используется следующий код: NewObjectId = ObjectId()

  • Если удалить документ из базыданных, удалится ли он с диска?

Да. Удаление документа из базы данных приведет к его удалению с диска.

  • Что такое индексы в MongoDB?

Индексы в MongoDB работают схожим образом с индексами в реляционных базах данных: они ускоряют выборку и сортировку данных. Индексы создаются с помощью ensureIndex.

  • Сколько индексов создается по умолчанию в MongoDB для новой коллекции?

По умолчанию, MongoDB создает только _id для каждой коллекции.

  • Что такое скрытый запрос в MongoDB?

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

  • Поддерживает ли MongoDB поиск текста?

Да. MongoDB поддерживает создание текстовых индексов для поддержки поиска текста внутри строки. Эта функция, была введена в версии 2.6.

  • Какая команда позволяет получить все индексы определенной коллекции?

  • Что такое Шардинг в MongoDB?

Шардинг — это подход к масштабируемости, когда отдельные части данных хранятся на разных серверах. Шардинг решает проблему горизонтального масштабирования. Примитивный пример: хранить данные пользователей, чьё имя начинается на буквы A-M на одном сервере, а остальных — на другом.

  • По умолчанию, MongoDB пишет и читает данные из primary и secondary наборов реплик. Правда ето или ложь?

Ложь. MongoDB записывает данные только в primary набор реплик.

  • Почему MongoDB не является предпочтительным решением для 32-битных систем?

При работе с 32-разрядной сборкой MongoDB, общий размер хранилища для сервера, включая данные и индексы, составляет 2 гигабайта. По этой причине, не рекомендуеться развертывать MongoDB для продакшина на 32-разрядных машинах.
Если вы используете 64-разрядную сборку MongoDB, практически нет никаких ограничений на размер хранилища.

  • Какая команда,позволяет проверить, являетесь ли вы на главном сервере или нет?

  • Что такое GridFS?

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

Читать еще:  Почему сильно шумит вентилятор в системном блоке?
Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector