Какая команда в mongodb заменяет select из mysql

25 примеров команды SELECT в MySQL

Добавить в избранное

На этом уроке мы расскажем, как использовать команду SELECT в MySQL с несколькими практическими примерами.

1. Основной пример команды SELECT

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

Далее, просмотреть все доступные базы данных.

Выберите базу данных, где вы хотите работать. В этом примере я выбрал базы данных “andreyexbase”, где расположена таблица “worker”, которая используется в качестве примера для всех выбранных команды, приведенные в этой статье.

Основное использование команды SELECT является просмотр строк из таблицы. Ниже приведен пример команды SELECT, где будет отображать все строки из таблицы “worker”.

Или выбрать конкретные столбцы, указав имена столбцов (вместо *, который даст все столбцы).

Примечание: Если вы новичок в MySQL, прочитайте нашу предыдущую статью о том, как создать базу данных MySQL и таблицы, прежде чем продолжить этот учебник.

2. Выберите одну из двух – виртуальная таблица

dual представляет собой виртуальную таблицу. Она на самом деле не существует. Но, вы можете использовать эту таблицу, чтобы выполнить некоторые действия без таблиц.

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

Вы можете также использовать двойную таблицу для просмотра текущей даты и времени. Функция now() в MySQL аналогична функции sysdate() в базе данных Oracle.

Если вы не укажете любую таблицу, MySQL будет считать, что вы хотите использовать двойную. Следующий пример точно такой же, как указано выше. Просто, чтобы избежать путаницы, я рекомендую вам использовать “from dual” в эти ситуации для лучшей читаемости и ясности.

3. Основные условия WHERE для ограничения записей

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

Кроме знака “больше >” вы можете также использовать “равно =”, “не равно! =”, как показано ниже.

4. Строки в условии WHERE

Предыдущий пример показывает, как ограничить записи, основанные на численных условиях. Этот пример объясняет, как ограничить записи на основе строковых значений.

Точное совпадение строк работает как числовое совпадение с помощью “равным =”, как показано ниже. Этот пример покажет всех сотрудников, которые принадлежат к отделу IT.

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

Вы можете также использовать !=. Для отображения всех сотрудников, который не принадлежат к отделу IT, как показано ниже.

Кроме того, можно выполнить частичное совпадение строки с помощью % в ключевых словах. Ниже будут показаны все сотрудников фамилия которых начинается с “And”.

Ниже будут показаны все сотрудники имя которых заканчивается на “ex”.

Вы также можете дать % в обоих направлениях. В этом случае, он будет искать для данного ключевого слова в любом месте строки. Ниже будут показаны все сотрудники, которые содержат “Andr” в их имени в любом месте.

5. Объединение WHERE с OR, AND

Вы можете также использовать OR, AND, NOT в WHERE для объединения нескольких условий. В следующем примере показаны все сотрудники, которые находятся в отделении «IT» и с зарплатой> = 6000. Это будет отображать записи только тогда, когда оба условия выполнены.

Следующий такой же, как и выше, но использует условие OR. Таким образом, это будет отображать записи до тех пор, пока любое из условия совпадет.

6. Объединение значений столбцов с помощью CONCAT в SELECT

Вы можете использовать функцию CONCAT в команде SELECT, объединить значения из нескольких столбцов и отображать их. Следующий пример сочетает в себе имя и отдел (только для отображения), как показано ниже.

7. Общее количество записей Count

Использование COUNT(*) в команде SELECT, чтобы отобразить общее количество записей в таблице.

8. Группировка в команде Select

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

Пожалуйста, обратите внимание, что при использовании GROUP BY, вы можете использовать некоторые функции, чтобы получить более значимый вывод. В приведенном выше примере, мы использовали COUNT(*) группу по командам. Точно так же вы можете использовать sum(), avg(), и т.д., при указании GROUP BY.

9. Использование HAVING вместе с GROUP BY

При использовании GROUP BY, вы можете также использовать HAVING для дальнейшего ограничения записи.

В следующем примере, он отображает только те отделы, где число работника составляет более 1.

10. Определение псевдонима с помощью ключевого слова ‘AS’

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

В следующем примере, даже при том, что настоящее имя столбца ID, он отображается как EmpId.

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

11. Left Join в команде SELECT

В следующем примере команда SELECT объединяет две таблицы. т.е. сотрудник и отдел. Для объединения их, он использует общий столбец между двумя этими таблицами отдела. Колонка “Location” показана на выходе из таблицы отдела.

Вы можете также использовать имя псевдонима таблицы в команде JOIN, как показано ниже. В этом примере я использовал “E” в качестве псевдонима для таблицы сотрудников, и “D” в качестве псевдонима для таблицы отделов. Это делает выбор команды меньше и легче читать.

Примечание: Join сама по себе огромная тема, которую мы будем обсуждать в деталях как отдельный учебник.

12. Анализ производительности с помощью EXPLAIN

Когда ваш запрос на выборку медлителен, или ведет себя таким образом, что вы не понимаете, используйте команду EXPLAIN, которая будет отображать дополнительную информацию, MySQL использует внутренне для выполнения запроса. Это может дать вам некоторое представление о производительности вашего выбора команды MySQL.

13. Форсировать запрос SELECT, используя INDEX

При выполнении запроса на выборку, и объединения двух таблиц, MySQL будет решать, как эффективно использовать любые доступные индексы в таблицах. Ниже приведены несколько способов борьбы с индексами в SELECT.

• USE INDEX (list_of_indexes) – будет использовать один из индексов, указанных для запроса записей из таблицы.
• IGNORE INDEX (list_of_indexes) – будет использовать индексы, определенные для запроса записей из таблицы.
• FORCE INDEX (index_name) – заставит MySQL использовать данный индекс, даже если MySQL делает лучше и быстрее запросы доступные для этой записи.

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

Следующие примеры MySQL использовать worker_emp_nm_idx для этого запроса.

Чтобы отобразить все доступные индексы конкретной таблицы, используйте команду “show index”. В следующем примере отображаются все индексы, доступные в таблице сотрудника.

14. Сортировка записей с помощью ORDER BY

Примечание: по умолчанию будет сортировать по убыванию. Если вы ничего не укажите, он будет по возрастанию.
Следующие записи будут указываться в алфавитном порядке, основанном на столбце DEPT.

Обратите внимание, что по умолчанию он будет сортировать в порядке возрастания. Если вы хотите отсортировать по убыванию, укажите ключевое слово “DESC” после “ORDER BY”, как показано ниже.

Вы также можете указать по нескольким столбцам, как показано ниже.

15. Ограничить количество записей

Вместо того, чтобы отображать все записи, вы можете просто ограничить, сколько записей MySQL должен отображаться с помощью LIMIT, как показано ниже.

Следующий пример будет начинаться с номером записи 0 (который является первой записью), и выдаст 3 записи.

Ниже будут начинаться с номером записи 1 (которая является второй записью), и выдаст 3 записи.

Вы также можете опустить start_record, в этом случае, он всегда будет начинаться с номером записи 0 (т.е. первая запись).

В следующем примере, мы указали только одно значение. Таким образом, это будет исходить из рекордного числа 0, а также отображать 3 записи.

16. Ограничить количество записей с OFFSET

Формат ограничения OFFSET:

Вы также можете использовать ключевое слово OFFSET, где вы будете указывать начальную запись после ключевого слова OFFSET.

Ниже будет отображаться в общей сложности 3 записей. Так как смещение определяется как 1, то начнет со 2-й записи.

17. Получить уникальные значения из столбца

Чтобы отобразить все уникальные значения из столбца, используйте DISTINCT.

Следующий пример покажет все уникальные значения DEPT из таблицы сотрудников.

18. Сумма всех значений в столбце

Чтобы добавить все значения из столбца, используйте функцию sum().

Следующий пример покажет сумму столбца заработной платы для всех работников, которые принадлежат к отделу IT.

19. Среднее значение всех значений в столбце

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

Следующий пример покажет среднюю зарплату каждого и каждого отдела. Объединение GROUP BY с функцией avg().

20. SELECT в команде SELECT

Пример, приведенный ниже, является очень неточным. Там нет никаких причин, чтобы сделать это таким образом. Но это показывает вам, как вы можете использовать команду SELECT. В этом примере “ACTION” дает имя псевдонима для выбора подзапроса. Вы должны указать псевдоним в этом примере. “ACTION” это просто название. Вы можете изменить его как угодно.

21. Использование оператора Select при выводе в файл

Используя SELECT INTO, вы можете сохранить вывод команды в файл.

Вместо того, чтобы отображать выходные данные на экране, следующий пример команды select будет сохранять вывод выбора команды в файл /tmp/worker.txt.

Вы также можете сохранить вывод в файл с разделителями запятыми, указав “FIELDS TERMINATED BY”, как показано в приведенном ниже примере.

22. Выполнение процедур на наборе данных

Кроме того, можно вызвать процедуру MySQL, которая будет обрабатывать данные с выходом команды SELECT.

В следующем примере выполнения процедуры salary_report () на выходе данного команды SELECT.

23. Показать случайную запись из таблицы

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

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

Можно также передать текущую дату и время, как соль, используя функцию now() к команде rand, как показано ниже.

24. Высокий приоритет команды Select

При использовании ключевого слова HIGH_PRIORITY в операторе SELECT, даст конкретному оператору SELECT более высокий приоритет, чем любому обновление в таблице.

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

25. Последовательное чтение в команде Select

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

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

Следующая команда не позволит другому сеансу MySQL изменять записи, которые запрашиваются у оператора SELECT, пока она не прочитает все эти записи.

Обратите внимание, что вы также можете сделать “FOR UPDATE”, как показано ниже, которые будут блокировать другие сеансы “SELECT … LOCK IN SHARE MODE”, пока эта транзакция не закончится.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

Что еще более интересно: если посмотреть на вот это отношение для разных типов баз данных, то видно, что для многих типов — таких, как колунарные базы данных, time series, document stories — open source базы данных наиболее популярны. Только для более старых технологий, таких как реляционные базы данных, или еще более древних, как multivalue база данных, коммерческие лицензии значительно популярнее.

Мы видим, что для многих приложений используют несколько баз данных для того, чтобы задействовать их сильные стороны. Ни одна база данных не оптимизирована для всех всевозможных юзкейсов. Даже если это PostgreSQL [смех на сцене и в зале].

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

Часто что видим, что люди приходят на такие конференции, слушают Facebook или «Яндекс» и говорят: «Ух ты! Сколько вот люди делают интересного. У них технологий разных используется штук 20, и еще штук 10 они написали сами». А потом они тот же самый подход пытаются использовать в своем стартапе из 10 человек, что работает, разумеется, не очень хорошо. Это как раз тот случай, где размер имеет значение.

Подходы к архитектуре

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

Другой подход к архитектуре с использованием разных баз данных — это микросервисы, у каждого из которых может быть своя база данных, которая лучше оптимизирована для задач именно этого сервиса. Как пример: основное хранилище может быть на MySQL, Redis и Memcache — для кэширования, Elastic Search или родной Sphinx — для поиска. И что-то вроде Kafka — чтобы передавать данные в систему аналитики, которая часто делалась на чём-то вроде Hadoop.

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

Если говорить про NoSQL-модели данных, то их тоже достаточно много. Наиболее типичные — это либо key value, либо document, либо wide column базы данных. Примеры: Memcache, MongoDB, Cassandra, соответственно.

Почему в данном случае мы сравниваем именно MySQL и MongoDB? На самом деле причин несколько. Если посмотреть на Ranking баз данных, то мы видим, что MySQL, согласно этому рейтингу, — наиболее популярная реляционная база данных, а MongoDB — наиболее популярная нереляционная база данных. Поэтому их разумно сравнивать.

А ещё у меня есть наибольший опыт в использовании этих двух баз данных. Мы в Percona занимаемся плотно именно с ними, работаем с многими клиентами, помогаем им сделать такой выбор. Еще одна причина: обе технологии изначально ориентированы на разработчиков простых приложений. Для тех людей, для которых PostgreSQL — это слишком сложно.

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

В Percona кроме того, что мы занимаемся поддержкой, консалтингом для этих технологий, у нас есть достаточно много написанного open source софта для обеих технологий. На слайде можно посмотреть. Подробно я рассказывать об этом не буду.

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

Выбор MySQL и MongoDB

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

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

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

Какие есть преимущества у данных систем?

Если говорить про MySQL — это проверенная технология. Понятно, что MySQL используется крупными компаниями более 15 лет. Так как он использует стандарт SQL, есть возможность достаточно простой миграции на другие SQL-базы данных, если захочется. Есть возможность транзакций. Поддерживаются сложные запросы, включая аналитику. И так далее.

С точки зрения MongoDB, здесь преимущество то, что у нас гибкий JSON-формат документов. Для некоторых задач и каким-то разработчикам это удобнее, чем мучиться с добавлением колонок в SQL-базах данных. Не нужно учить SQL — для некоторых это сложно. Простые запросы реже создают проблемы. Если посмотреть на проблемы производительности, в основном они возникают, когда люди пишут сложные запросы с JOIN в кучу таблиц и GROUP BY . Если такой функциональности в системе нет, то создать сложный запрос получается сложнее.

В MongoDB встроена достаточно простая масштабируемость с использованием технологии шардинга. Сложные запросы если возникают, мы их обычно решаем на стороне приложения. То есть, если нам нужно сделать что-то вроде JOIN , мы можем сходить выбрать данные, потом сходить выбрать данные по ссылкам и затем их обработать на стороне приложения. Для людей, которые знают язык SQL, это выглядит как-то убого и ненатурально. Но на самом деле для многих разработка application-серверов такое куда проще, чем разбираться с JOIN .

Подход к разработке и жизненный цикл приложений

Если говорить про приложения, где используется MongoDB, и на чём они фокусируются — это очень быстрая разработка. Потому что всё можно постоянно менять, не нужно постоянно заботиться о строгом формате документа.

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

Очень часто если у вас есть какое-то приложение, с данными в базе данных работает только это приложение. Например, мы сохраняем данные из этого приложения в эту базу данных. Схема на уровне приложения работает хорошо. Если у нас одни и те же данные используются многими приложениями, то это очень неудобно, сложно контролировать.

Здесь возникает также вопрос времени жизни приложения. С MongoDB хорошо делать приложения, у которых очень ограниченный цикл жизни. То есть если мы делаем приложение, которое живёт недолго, например, сайт для запуска фильма или олимпиады. Мы пожили несколько месяцев после этого, и это приложение практически не используется. Если приложение живёт дольше, то тут уже другой вопрос.

Если говорить про распределение преимуществ и недостатков MySQL и MongoDB с точки зрения цикла разработки приложения, то их можно представить так:

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

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

Хорошо это или плохо? Результат — всегда таблица. С одной стороны, это просто, с другой — некоторые структуры данных не всегда хорошо ложатся на таблицу, нам может быть неудобно с этим работать.

Это всё в теории. Если говорить о практическом использовании MySQL, мы знаем, что часто денормализуем данные, иногда для некоторых приложений мы используем что-то подобное: храним JSON, XML или другую структуру в колонках приложения.

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

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

Пример. Мы хотим сохранить контакт-лист с телефона. Понятно, что есть данные, которые хорошо кладутся в одну реляционную табличку: Фамилия, Имя и т.д. Но если посмотреть на телефоны или email-адреса, то у одного человека их может быть несколько. Если подобное хранить в хорошем реляционном виде, то нам неплохо бы это хранить в отдельных таблицах, потом это всё собирать JOIN , что менее удобно, чем хранить это всё в одной коллекции, где находятся иерархические документы.

Следует сказать, что это всё в строго реляционной теории — некоторые базы данных поддерживают массивы. В MySQL поддерживается формат JSON, в который можно засунуть такие вещи, как несколько email-адресов. Или многие годы люди серилизовали это ручками: надо нам сохранить несколько email-адресов, то давайте запишем их через запятую, и дальше приложение разберётся. Но как-то это не очень кошерно.

Термины

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

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

Что касается доступа: там, где мы к реляционным данным используем язык SQL, в MongoDB и многих других NoSQL-базах данных используется такой стандарт, как CRUD. Этот стандарт говорит, что есть операции для создания, чтения, удаления и обновления документов.

Несколько примеров.

Как у нас могут выглядеть наиболее типичные задачи по работе с документами в MySQL и MongoDB:

Вот пример вставки.

Если вы разработчик, который знаком с языком JavaScript, то такой синтаксис, который предоставляет CRUD (MongoDB), для вас будет более естественным, чем синтаксис SQL.

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

&gt вместо простого знака «>». Не очень читаемо, на мой взгляд.

Достаточно легко с помощью интерфейса делать такие вещи, как подсчёт числа строк в таблице или коллекции.

Но если мы делаем более сложные вещи, например, GROUP BY , в MongoDB для этого требуется использовать Aggregation Framework. Это несколько более сложный интерфейс, который показывает, как мы хотим отфильтровать, как мы хотим группировать и т.д. Aggregation Framework уже поддерживает что-то вроде операций JOIN .

Следующий момент — это транзакции и консистентность (ACID). Если пойти и почитать документацию MongoDB, там будет: «Мы поддерживаем ACID-транзакции, но с ограничением». На мой взгляд, стоит сказать: «ACID мы не поддерживаем, но поддерживаем другие минимальные нетранзакционные гарантии».

Какая у нас между ними разница?

Если говорить про MySQL, он поддерживает ACID-транзакции произвольного размера. У нас есть атомарность этих транзакций, у нас есть мультиверсионность, можно выбирать уровень изоляции транзакций, который может начинаться с READ UNCOMMITED и заканчиваться SERIALIZABLE . На уровне узла и репликаций мы можем конфигурировать, как данные хранятся.

Мы можем сконфигурировать у InnoDB, как работать с лог-файлом: сохранять его на диск при коммите транзакции или же делать это периодически. Мы можем сконфигурировать репликацию, включить, например, Semisynchronous Replication, когда у нас данные будут считаться сохранёнными только тогда, когда их копия будет принята на одном из slave’ов.

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

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

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

Производительность

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

Это результаты бенчмарка, который делал Марк Каллаган. Здесь видно, что с точки зрения использования процессора, ввода/вывода MySQL — как InnoDB, так и MyRocks — использует значительно меньше процессора и дискового ввода/вывода на операции бенчмарка Linkbench от Facebook.

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

Что такое масштабируемость в данном контексте? То, насколько легко нам взять наше маленькое приложение и масштабировать его на многие миллионы, может быть, даже на миллиарды пользователей.

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

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

В MySQL в новых версиях весьма хорошая масштабируемость в рамках одного узла для LTP-нагрузок. Если у нас маленькие транзакции, есть какое-нибудь железо, в котором 64 процессора, то масштабируется достаточно хорошо. Аналитика или сложные запросы масштабируются плохо, потому что MySQL может использовать для одного запроса только один поток, что плохо.

Традиционно чтение в MySQL масштабируется с репликацией, запись и размер данных — через шардинг. Если смотреть на все большие компании — Facebook, Twitter — они все используют шардинг. Традиционно шардинг в MySQL используется вручную. Есть некоторые фреймворки для этого. Например, Vitess — это фреймворк, который Google использует для scaling сервиса YouTube, они его выпустили в open source. До этого был framework Jetpants. Стандартного решения для шардинга MySQL не предлагает, часто переход на шардинг требует внимания от разработчиков.

В MongoDB фокус изначально был в масштабируемости на многих узлах. Даже в случаях с маленьким приложением многим рекомендуется использовать шардинг с самого начала. Может, всего пару replica set, потом вы будете расти вместе со своим приложением.

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

Администрирование

Администрирование – это все те вещи, о которых не думают разработчики. По крайней мере в первую очередь. Администрирование — это то, что нам приложение придётся бэкапить, обновлять версии, мониторить, восстановливать при сбоях и так далее.

MySQL достаточно гибок, у него есть много разных подходов. Есть хорошие open source реализации всего, но это множество вариантов порождает сложность. Я часто общаюсь с пользователями, которые только начинают изучать MySQL. Они говорят: «Ёлки-палки, сколько же у вас всего вариантов. Вот только репликация — какую мне использовать: statement-репликацию, raw-репликацию, или mix? А еще есть gtid и стандартная репликация. Почему нельзя сказать „просто работай“?»

В MongoDB всё больше ориентированно на то, что оно работает каким-то одним стандартным образом — есть минимизация администрирования. Но понятно, что это происходит при потере гибкости. Коммьюнити open source решений для MongoDB значительно меньше. Многие вещи в MongoDB с точки зрения рекомендаций достаточно жестко привязаны к Ops Manager — коммерческой разработке MongoDB.

Как в MongoDB, так и в MySQL есть мифы, которые были в прошлом, которые были исправлены, но у людей хорошая память, особенно если что-то не работает. Помню, в MySQL после того как появились транзакции с InnoDB, люди мне лет десять говорили: «А в MySQL нет же транзакций?»

В MongoDB было много разных проблем с производительностью MMAP storage engine: гигантские блокировки, неэффективное использование дискового пространства. Сейчас в стандартном движке WiredTiger уже нет многих из этих проблем. Есть другие проблемы, но не эти.

«Нет контроля схемы» — ещё такой миф. В новых версиях MongoDB можно для каждой коллекции определить на JSON структуру, где данные будут валидироваться. Данные, которые мы пытаемся вставить, и они не соответствуют какому-то формату, можно выкидывать.

«Нет аналога JOIN » — то же самое. В MongoDB это появилось, но нескольких ограниченных вещах. Только на уровне одного шарда и только если мы используем Aggregation Framework, а не в стандартных запросах.

Какие у нас есть мифы в MySQL? Здесь я буду говорить больше о поддержке NoMySQL решений в MySQL, об этом я буду говорить завтра. Следует сказать, что MySQL сейчас тоже можно использовать через интерфейс CRUD’a, использовать в NoSQL режиме примерно как MongoDB.

Типичный пример, где используется MySQL-решение — это сайт электронной коммерции. Когда у нас идёт вопрос о деньгах, часто мы хотим полноценные транзакции и консистентность. Для таких вещей хорошо подходит реляционная структура, которая была проработана, и commerce на реляционных базах данных уже делается многие десятилетия. Так что можно взять один из готовых подходов к структуре данных и использовать его.

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

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

С другой стороны, если не выстрелит, нам хотелось бы, чтобы инфраструктуру можно было бы уменьшить. Во многих играх это идет так: мы запустили игру, у нее есть какой-то пик, приходится делать большой кластер. Потом игра уже выходит из популярности, для неё бэкенд нужно сжимать, сохранять и использовать. В данном случае есть одно приложение (игра), база данных, с одной стороны, несложная, с другой — сильно привязанная к приложению, в котором хранятся все важные для игры параметры.

Часто консистентность базы данных на уровне объектов здесь достаточна, потому что многие вопросы консистентости решаются на уровне приложения. Например, данные одного игрока сохраняет только один application service.

MongoDB основные запросы

Хоть и некоторые писали относительно моего предыдущего топика MongoDB: Создание, обновление и удаление документов, что это пересказ офф. документации, я с этим не полностью согласен. Мне показалось, что информация в нём оказалось кому-то полезной, поэтому выкладываю продолжение.

Find — аналог SELECT в MySQL. Используется для выборки документов из MongoDB. Возвращает массив документов в виде коллекции, если документов нет — пустую коллекцию. Пример:

Вернёт всех пользователей из коллекции.

Вернёт всех пользователей, у которых возраст равен 27.

Можно указывать несколько параметров, например, вот так: Иногда бывает необходимо получить какие то конкретные поля из документов. В этом случае запрос выглядит так: В итоге получим всех пользователей только с полями «username» и «email» + поле «_id», которое возращается всегда по умолчанию. Если поле «_id» или какое-либо другое не нужно, мы можем это указать вот так: Запросы с условием

Операторы: $lt — меньше, $lte — меньше или равно, $gt — больше, $gte — больше или равно, $ne — не равно. Примеры использования: Получаем всех пользователей, возраст которых больше 18 и меньше 30 Получаем всех пользователей, «username» которых не равен “joe”

Допустим, у нас коллекция хранит лотерейные билеты с номерами и нам нужно найти только те, в которых есть победившие номера 390, 754, 454. В таком случае мы используем оператор $in:

т.е. билет должен содержать один из этих номеров. Противоположным оператору $in является $nin. Он, по аналогии, получает только те билеты, где нет, указанных выше, номеров. Оператор $or используется при запросах, когда нужно выбрать документы по совпадению одному из значений. Например, нам нужно выбрать все билеты с номером 547 или где поле «winner» равно true: Оператор $mod используется для выборки ключей, значения которых делятся на первый аргумент и остаток от деления получается равным второму аргументу. Звучит непонятно, вот более наглядно:

Такой запрос вернёт всех пользователей, «user_id» которых равен 1, 6, 11, 16 и так далее. Чтоб получить всех пользователей, кроме вышеуказанных можно использовать оператор $not:

Получим пользователей с «user_id» 2, 3, 4, 5, 7, 8, 9, 10, 12 и так далее. Существует также оператор для проверки существует ли какой то ключ или нет — $exist

Так можно выбрать все документы коллекции, где существует ключ “z” и он равен null.

Все мы знаем, что регулярные выражения очень мощная штука. MongoDB использует Perl-совместимые регулярные выражения. Вот так можно найти всех пользователей с именем joe или Joe:

Вообщем есть где разгуляться. Есть куча сервисов для того же javascript’a, где можно писать и проверять свои регулярки.

Запросы в массивах

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

То вот такой запрос

успешно его найдёт. Если нужно выбрать документы больше, чем по одному элементу массива, то мы можем использовать оператор $all

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

Есть у нас блог, в нём хранятся комментарии. Мы хотим получить первые 10 комментариев. На помощь нам приходит оператор $slice:

findOne — работает аналогично find, но возвращает первый совпавший документ.

Если нужно получить последние 10 комментариев пишем вот так:

Также $slice умеет получать документы из середины:

в этом случае будет пропущено 23 начальных элемента и вернутся элементы с 24 по 34, если это возможно

Команды limit, skip и sort

Для того, чтоб получить ограниченное количество документов по запросу используется команда limit:

Вернёт первых 3-х пользователей. Для того, чтоб пропустить несколько документов и получить все остальные используется команда skip:

Получаем всех пользователей, кроме первых трёх. Для сортировки используется команда sort. Сортировка может быть по возрастанию (1) и по убыванию (- 1). Сортировка может производится по нескольким ключам в порядке их приоритета:

Все эти три команды можно использовать вместе:

db.stock.find( ).limit(50).skip(50).sort( ); Использование команды skip с большими значениями работает не особо быстро. Рассмотрим это на примере пагинации:

Самый простой способ сделать пагинацию это в первый раз вернуть фиксированное количество документов, а потом каждый раз смещать диапазон на это значение

но это будет работать довольно медленно. Допустим мы будет делать выборку относительно даты создания документа:

Сортируем по убыванию и берём первые 100. Чтоб не делать skip мы можем получить дату последнего документа и сделать запрос уже относительно этой даты:

Так можно избежать использования команды skip для больших значений.

Оператор SQL	MongoDB	Описание
$gt	больше
>=	$gte	больше или равно
	$ne	не равно
NOT	$not	отрицание
EXISTS	$exists	проверка существования поля
OR	$or	или
NOT OR	$nor	не или
RLIKE, REGEXP	$regex	соответствие регулярному выражению
LIKE	$elemMatch	соответствие всех полей вложенного документа
—	$size	соответствие размеру массива
—	$type	соответствие, если поле имеет указанный тип

Работа со списками
Для работы со списками предназначены операторы $in, $nin и $all.

Оператор SQL	MongoDB	Описание
IN	$in	входит в список
NOT IN	$nin	не входит в список
ALL	$all	одновременное совпадение набора элементов

Оператор $in извлекает записи для которых заданное значение совпадает хотя бы с одним из списка. Ниже выводится запрос, извлекающий записи, поле title которых совпадает с одним из значений в списке [‘MongoDB’, ‘MySQL’]:

Для обновления используется метод update, первый аргумент которого определяет список обновляемых документов, второй — как отобранные документы модифицируются. Следующая команда добавляет в документ с названием "MongoDB" дополнительное поле nosql, со значением "true":

Если обновлению подвергается только одно поле, следует обязательно использовать оператор $set. Если его опустить, вместо обновления поля, будет обновлен весь документ:

Для удаления дополнительного поля nosql, вместо оператора $set, следует подставить $unset

Для того, чтобы добавить ключевое слово в массив тэгов tags базы данных articles следует воспользоваться оператором $addToSet

Если запросить состав текущей базы данных при помощи метода find(), можно заметить, что обновился только один документ из двух, которые имеют ключевое слово "Redis". Для того, чтобы обновить все документы, следует передать четвертому параметру метода update() значение true, что заставит MongoDB обновить все найденные документы

Ниже приводится сводная таблица по операторам, используемым совместно с методом update()

Оператор	Описание
$set	обновление или создание поля
$unset	удаление поля
$inc	увеличение значения поля на заданное число
$pop	удаляет последний (или первый) элемент массива
$pushAll	помещает несколько элементов в массив
$push	помещает новый элемент в массив
$addToSet	помещает новый элемент в массив (исключаются дубликаты)
$pull	удаляет из массива значение (при его наличии)
$pullAll	удаляет из массива все подходящие значения

Полностью удалить документы из текущей базы данных можно при помощи метода remove()

Точно также, как и другие методы, в качестве параметра метод может принимать селекторы, например, удалить все записи в ключом nosql равным "true" можно при помощи следующей команды

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 хранит коллекцию метаданных — отдельных файлов, содержащих информацию о хранящихся в файловой системе документах.