чем mongodb лучше mysql

MongoDB vs MySQL (vs Cassandra): А теперь чуть более правильный ответ

На графике — число операций в секунду, (больше — лучше), шкала логарифмическая.
Последняя строка — то, что тестировал автор оригинального топика (неправильное, не в критику — все мы ошибаемся и учимся).

А теперь подробнее об ошибке.

Итак, ошибка оригинала была в том, что он делал SELECT так:

что возвращало Cursor(!), но не сам объект. То есть обращение к базе не происходит (или по крайней мере чтения данных не происходит). А вот что надо было:

Если бы автор проверял бы, что сохраненное значение (INSERT) равняется вытащенному (SELECT) — такой ошибки не было бы.

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

Сам тест: по сути оба в качестве «key-value storage» (сохраняем по primary key + value, выбираем по primary key, читаем value). Да, сферический, да, в вакууме.

Да, внутри теста там есть вызовы assert и str. Разумеется они отжирают часть производительности, но для обоих тестов — их одинаковое число. А нам же просто СРАВНИТЬ производительность надо.

Больше результатов: Core2duo / WinXP SP3.

Больше 10000 записей тестировал — соотношение сохраняется. И вроде ни Mongo, ни MyISAM не сдуваются по скорости.

Я не говорю, что 100% прав (может и я в чем ошибся), так что проверяйте меня тоже.

В комментах fallen протестировал этим же кодом все под Linux + InnoDB_Plugin. Соотношение сил — примерно то же, но ровнее:

Linux + InnoDB_Plugin

«Core i7 920, 2GB RAM, Fedora 12 x64, mysql 5.1.44 + InnoDB 1.0.6 скомпилированные icc, mongodb 1.2.4 x64, sata диск обычный.»

Выводы:

vs Cassandra

И интереса ради добавлена Cassandra + pycassa (под win32) — сразу скажу — с ней у меня никакого опыта и много непонятного (.remove() не удаляет записи, а только очищает их, сами они остаются… + eventual consistency — оооооооочень трудно тестировать!) — полное прыгание с бубном в темноте, так что считайте просто развлекательным тестом.

Йои Хаджи,
вид с Хабра

Источник

MongoDB или как разлюбить SQL

Введение

Масштабировали, масштабировали, да не вымасштабировали

Однако, когда вдруг понимаешь, что одного сервера перестает хватать, и хочется раскидать базу на несколько физических машин, то первое что предлагается — master-slave репликация, при которой запись идёт на одну машину, а чтение — с нескольких. Но при достаточно большом количестве изменений в скором времени master только и будет делать что раздавать логи, и придётся прибегнуть к изощренной настройке, чтобы каждый узел имел один шефствующий сервер (master) и мог иметь несколько подчиненных серверов (slave). Данная схема весьма сложна в реализации и содержит single point of failure (т.е. при выходе из строя одного сервера, все его подчиненные стремительно превращаются в динозавров). Опять же, все эти ухищрения позволят увеличить лишь количество чтений. А если для внесения изменений в состояние базы данных не хватает мощности одного сервера, то приходится распределять нагрузку, храня разные таблицы на разных серверах. Но тогда потеряется связанность. Или приходится разбивать таблицу на несколько частей, храня их в разных местах, согласно заданному закону (например по ID), однако это унесет в могилу прелести JOIN. Чем дальше мы пытаемся масштабировать реляционные базы данных, тем большим удобством мы за это платим. Например, при использовании master-master, мы заплатим auto increment’ами.

Спасут ли нас MemcacheDB и Redis?

Подобные key-value решения существуют довольно давно. На мой взгляд, MemcacheDB это поделка, паразитирующая на добром имени замечательного продукта: данные там абсолютно не связаны между собой, мы можем лишь проводить операции над значением зная ключ. Я потратил уйму времени на написание инструментария, позволяющего выгодно работать с key-value БД вроде MemcacheDB, и это даже работает, однако пришел к тому что простые насущные задачи решаются настолько криво, что невольно думаешь в сторону реляционки: например, нету даже элементарной реализации времени жизни объекта (TTL), т.е. нельзя взять и удалить сессии старше месяца. Это не доставляет.

Авторы Redis пошли чуть дальше в своих извращенных фантазиях и сделали атомарные списки и set’ы в ключах, однако не сильно продвинулись в облегчении жизни программисту.

Более того, всё еще приходится вручную обслуживать кеш ключей, т.е. сохранять нужные ключи в Memcached и брать их из него, что создает уйму проблем с синхронизацией. При этом также отсутствует атомарность операций: возникает гонка между получением объекта и записью в кеш, CAS демотивирует нас своей производительностью.

Что делать если хотим каталог товаров по типу Яндекс.Маркета?

Допустим, мы хотим сделать каталог, в котором осуществляется поиск по таким параметрам как цена, рейтинг, кратность зума у фотоаппарата и количество передач у велосипеда. Допустим, мы используем реляционную базу данных типа MySQL. Что мы должны сделать? Мы должны либо создать таблицу goods, в которой будет как кратность зума, так и количество передач для велосипеда, и к примеру, показатель гибкости щетины зубной щетки (в этом случае мы упремся в лимит полей для таблицы, или потеряем на дисковом пространстве, скорости, и удобстве), либо мы должны завести табличку вида good_id, key, value и делать страшные JOIN’ы для выборки и поиска, не заикаясь о масштабировании.

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

У реляционок налицо серьезная родовая травма.

MongoDB говорите?

MongoDB — резкая как понос объектно-документарная база данных. Идеологически это некий симбиоз между привычной реляционной БД и key-value хранилищем, и на мой взгляд, весьма удачный. С одной стороны, она позволяет делать очень быстрые операции над объектом, зная его идентификатор, а с другой, предоставляет мощнейший инструмент для сложных взаимодействий.

Коллекция — именованное множество объектов, при этом один объект принадлежит лишь одной коллекции.
Объект — совокупность свойств, включая уникальный идентификатор _id.
Свойство — совокупность названия и соответствующего ему типа и значения.
Типы свойств — строка, целое число, число с плавающей точкой, массив, объект, бинарная строка, байт, символ, дата, boolean, null.
Поддерживаются операции выборки (count, group, MapReduce. ), вставки, изменения и удаления. Связей между объектами нет, объекты могут лишь хранить другие объекты в свойствах. Поддерживаются как уникальные, так и композитные индексы. Индексы можно накладывать на свойства вложенных объектов.
Поддерживается репликация (даже подразумевается), реализован fail-over.
Реализован MapReduce и шардинг.
Поскольку объекты могут иметь произвольный набор свойств, для каталога достаточно создать коллекцию goods и складывать туда объекты. При этом поиск будет вестись по индексам.
Резкость MongoDB ярко выражена на insert’ах, они происходят ну очень быстро. Кстати, приятно что формат хранения и формат передачи объектов по сети один и тот же, так что для выборки какого-то объекта надо всего лишь найти его позицию по индексу и вернуть клиенту кусок файла определенной длины — никакой абстракции над storage engine.
В качестве уникального идентификатора используется не auto-increment’ное поле, а 12-байтное уникальное число, генерируемое на клиенте. Таким образом, во-первых нет проблемы с синхронизацией реплик, т.е. можно независимо делать вставки на две разные машины, и конфликта не возникнет. Во-вторых, не будет ерунды с переполнением целого числа, ну и после пересоздания базы данных, поисковики не будут адресовать на новые статьи по старым ссылкам.

MongoDB + Memcached? Покруче чем Бонни и Клайд!

С базой данных более-менее разобрались, теперь подумаем как нам всё это дело кешировать, ведь нам же хочется отдавать горячие пирожки со скоростью Memcached!

Во-первых, кеширование самих объектов. Как многие успели догадаться, или узнать из опыта — в большинстве случаев операция выборки объекта по ID является самой частой. Например, выборка объекта пользователя, выборки этого поста из базы Хабрахабра (аминь), и т. д.

Как мы уже выяснили выше, перекладывать сей труд на приложение неразумно, т.к. мы должны были бы нагородить огород распределенных блокировок. Пойдем другим путем, напишем асинхронное приложение, которое подключится к MongoDB и, прикинувшись slave’ом, будет получать лог изменений, и сбрасывать изменения в Memcached (если объект содержит ключ в свойстве _key). Поскольку приложение асинхронно, это будет происходить быстро, однако гонки возникать не будет. Написать несложно, моя реализация тут. Более того, я еще присобачил туда отправку изменений серверу событий, так что мне стоит только изменить объект откуда угодно (да хоть из консоли), как он тут же будет передан всем подписанным на него клиентам.

Минусы с которыми придется столкнуться.

Finita la comedia!

Страничка проекта — MongoDB.
Найденный бенчмарк MongoDB vs MySQL.

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

Друзья, спасибо за внимание! Буду рад конструктивным комментариям.

Источник

MySQL vs MongoDB

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

MySQL

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

MongoDB

Яркий представитель нереляционных БД, имеющий свои плюсы: 1. Динамическая схема. Позволяет более гибко работать со схемами данных без надобности в изменении самих данных. 2. Масштабируемость. MongoDB масштабируется горизонтально, поэтому вы сможете легко снизить нагрузку на серверы при наличии больших объемов данных. 3. Удобное управление. Отдельный администратор не нужен, а повышенное удобство применения позволяет использовать эту БД как разработчикам, так и системным администраторам. 4. Скорость. База отличается повышенной производительностью при выполнении простых запросов. 5. Гибкость. Вы можете добавлять поля либо колонки без какого-либо вреда для уже существующих данных и производительности СУБД.

Что же выбрать?

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

Источник

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:

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

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

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

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

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

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

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

Когда необходимо выбрать СУБД, главный вопрос обычно заключается в выборе реляционной (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: реляционная СУБД

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

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

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

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

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

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

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

Почему MongoDB

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

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

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

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

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

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

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

Пример:

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

Пример:

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

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

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

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

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

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

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

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

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

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

Возвращаемся к командной строке и запускаем сервис 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.

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

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

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

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

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. Может ли быть две версии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник