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


Оглавление (нажмите, чтобы открыть):

Разница между SQL и MySQL. Разница между 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.

База данных играет важную роль для каждого современного веб-приложения. Благодаря динамической природе веб-приложений сейчас, даже простейшие приложения требуют некоторых механизмов хранения, доступа и изменения данных (вот почему в Hostinger мы предлагаем для наших клиентов с премиум и бизнес аккаунтами). Естественно, поскольку важность баз данных стремительно растёт, реляционные системы управления базами данных или реляционные СУБД набирают свою популярность (Relational Database Management Systems – RDBMS)

Что такое SQL сервер?

SQL сервер также известен, как Microsoft SQL Сервер, появился значительно раньше, чем MySQL. Microsoft разработал SQL сервер в 80х, с обещанием разработать надёжную и расширяемую реляционную СУБД. Они остаются ядром качества SQL сервера по прошествии всех этих лет, и предоставляют незаменимое решение для крупномасштабного корпоративного программного обеспечения.

SQL сервер больше подходит для разработчиков, использующих.NET в качестве языка разработки, как конкурирующей связке PHP для MySQL. Это весьма логично, так как обе платформы принадлежать Microsoft.

Ключевые различия между MySQL и SQL сервером

Теперь, после краткого знакомства с системами, давайте посмотрим на несколько ключевых различий между MySQL и SQL сервером:

  • Среда
    Как упоминалось ранее, SQL сервер лучше работает с.NET, в то время как MySQL может был использован с практически любыми другими языками, наиболее распространённая связка с PHP. Не лишним будет также сказать, что SQL сервер может быть запущен только лиш под ОС Windows, но за последние годы это условие изменилось, когда Microsoft анонсировала поддержку Linux для SQL сервера . Версия для Linux всё ещё зреет и имеет незавершённых вид, что значит мы рекомендуем вам использовать ОС Windows при работе с SQL сервером и переключатся на Linux, если работаете с СУБД MySQL.
  • Синтаксис
    Для большинства людей это наиболее важное различие в этих двух системах. Знакомство с одним набором правил синтаксиса может значительно повлиять на ваше решение относительно того, какая система подходит вам больше. Хотя MySQL и SQL сервер базируются на SQL, различия синтаксиса всё же ощутимы и заслуживают внимания. Например, давайте посмотрим на этот фрагмент:

SELECT age FROM person ORDER BY age ASC LIMIT 1 OFFSET 2

Microsoft SQL Server

SELECT TOP 3 WITH TIES * FROM person ORDER BY age ASC

Обе цепочки кода достигают одного и того же результата – возвращают 3 записи со значением самого молодого возраста из таблицы имён людей. Но синтаксис сильно отличается. Конечно, синтаксис – это субъективный параметр оценки, поэтому мы не может тут давать рекомендацию; выбирайте то, что кажется вам более интуитивно понятным. Полный список описательных различий между MySQL и SQL сервером можно найти (англ.).

  • SQL сервер больше, чем реляционная СУБД
    Главное преимущество платного ПО в сравнении с бесплатным – это особая поддержка, которую вы получаете. В данном случае, преимущество ещё более значимое, так как SQL сервер поддерживается одной из самых больших компаний в мире. Microsoft создало дополнительный инструменты для SQL сервера, которые привязываются к реляционной СУБД, включая инструменты для анализа данных. Система также имеет сервер отчётов – Служба отчётов SQL Сервера, равно как и инструмент ETL. Это делает SQL сервер швейцарским армейский ножом среди реляционных СУБД. Вы можете получить подобные функции и в MySQL, но вам придётся искать в интернете сторонние решения – что многим не подойдёт.
  • Система хранения данных
    Другим большим различием между MySQL и SQL сервером, которое иногда упускают, это система хранения данных. SQL сервер использует единую систему, разработанную Microsoft, в сравнении с множеством движков, предлагаемых MySQL. Это даёт разработчикам, использующим MySQL больше гибкости, поскольку они могут выбирать разные системы для разных таблиц, основываясь на скорости, надёжности или каких-то других параметрах. Популярный движок MySQL – это InnoDB, который немного теряет в скорости, но обеспечивает усиленную надёжность. Другой известный – MyISAM.
  • Отмена запроса
    Немногие это знают, но кардинальным различием между MySQL и SQL сервером является то, что MySQL не позволяет вам отменить запрос в середине его выполнения. Это значит, что, как только команда запущена на выполнение, вам лучше надеяться, что любой ущерб, который она может сделать, является обратимым. SQL сервер, с другой стороны, позволяет вам отменить запрос на пол пути его выполнения. Это различие может быть несущественным для администраторов, так как они обычно выполняют скрипты команд, и это редко требует отмены во время их выполнения, чего не всегда скажешь о разработчиках.
  • Безопасность
    Очевидно не требуется тщательного рассмотрения вопроса, когда идёт речь о сравнении различий в безопасности в MySQL с SQL сервера. Обе системы совместимы с EC2, что означает вы в безопасности, выбирая любую из двух. Нужно отметить, что величие Microsoft сказалось и здесь наличием в SQL сервере собственной, ультрасовременной системы безопасности. Выделенный инструмент безопасности – анализатор Microsoft Baseline Security Analyzer (MBSA) – гарантирует надёжную защиту для SQL сервера. Поэтому, если безопасность имеет ключевое значение для вас, выбор очевиден.
  • Стоимость
    Здесь SQL сервер становится гораздо менее привлекательным, и MySQL зарабатывает большие очки. Microsoft требует, чтобы вы покупали лицензии для запуска нескольких баз данных на SQL сервер, есть бесплатная версия, но она предназначена только для ознакомления с реляционной СУБД. Напротив, MySQL использует лицензию GNU, что делает её полностью свободной. Однако, если вам нужна поддержка или помощь для MySQL, вам нужно будет заплатить за нее.
  • Поддержка сообщества
    Что переносит нас к следующей точке. За поддержка MySQL вам вряд ли придётся платить, за исключением, быть может, редких случаев, благодаря вкладу большого сообщества в его поддержку. Преимущество огромного сообщества в том, что большинству людей не нужно обращаться за специальной помощью – можно просто искать в Интернете и находить массу решений.
  • IDE
    Важно отметить, что обе реляционные СУБД поддерживаются различными интегрированными средами разработки (IDE). Эти инструменты предлагают слаженную среду для разработки, и вы можете тщательно выбрать именно то, что лучше всего подходит для ваших потребностей. MySQL может похвастаться Oracle Enterprise Manager, в то время как SQL сервер использует Management Studio (SSMS). Оба имеют свои плюсы и минусы и могут сбить с толку, если у вас нет чётких критериев для обоснования своего решения.

Заключение

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

В этом руководстве мы обсудили две наиболее распространенные реляционные СУБД – MySQL и Microsoft SQL сервер. Мы рассмотрели несколько ключевых различий между MySQL и SQL сервером, даже одного из которых может быть достаточно, чтобы сделать выбор.

В конечном счёте, выбор за вами. Как правило, если вы разрабатываете приложения среднего и малого размера и преимущественно используете PHP, переходите к MySQL. Принимая во внимание, что если вы заинтересованы в создании крупномасштабных, безопасных, устойчивых корпоративных приложений, SQL сервер может вам подойти куда больше.

Отличия MySQL от стандартного SQL

В состав сервера MySQL входит ряд расширений, которых, возможно, вы не найдете в других базах данных SQL. Помните, что если вы используете их, ваш код перестанет быть переносимым на другие серверы SQL. В некоторых случаях вы можете писать код, включающий расширения MySQL, но остающийся переносимым, используя для этого форму комментариев /*! . */. В этом случае сервер MySQL разбирает и выполняет код внутри комментария, как и любые другие SQL-операторы, а все другие серверы SQL расширение проигнорируют. Например: SELECT /*! STRAIGHT_JOIN */ имя_столбца FROM таблица1, таблица2 WHERE . Если после символа «!» добавить номер версии, синтаксис внутри комментария будет выполняться только сервером MySQL указанной и более поздних версий: CREATE /*132302 TEMPORARY */ TABLE t (a INT); Это означает, что если работа выполняется в версии MySQL 3.23.02 или более позд­ней, то ключевое слово TEMPORARY будет использовано. В приведенном ниже списке описаны расширения MySQL по категориям.

  • Организация данных на диске.

Сервер MySQL отображает каждую базу данных на подкаталог внутри каталога данных MySQL, а таблицы внутри базы — на имена файлов в этом каталоге. От­сюда вытекает несколько следствий:

  1. Имена баз данных и таблиц MySQL зависят от регистра в средах операцион­ ных систем, в которых имена файлов чувствительны к регистру символов (большинство Unix-систем).
  2. Можно использовать стандартные системные команды для резервного копиро­ вания, переименования, перемещения, удаления и копирования таблиц, управляемых механизмами хранения My ISAM или ISAM.

Например, чтобы переименовать таблицу MylSAM, потребуется переименовать файлы.MYD, .MYI и. frra, ко­торые относятся к таблице.Имена баз данных, таблиц, индексов, столбцов и псевдонимы могут начинаться сцифры (но не должны состоять только из цифр).

  • Общий синтаксис языка.
  1. Строки могут ограничиваться и одиночными и двойными кавычками.
  2. Символ «V используется в строках как управляющий.
  3. Внутри SQL-операторов можно получать доступ к таблицам из разных баз дан­ ных посредством синтаксиса имя_ базы_ да нных. имя таблицы. Некоторые серверы SQL предоставляют ту же функциональность, но называют ее пространством пользователя (User space). Сервер MySQL не поддерживает табличных про­ странств, как в следующем операторе: CREATE TABLE ralph.my_table.. .IN my_tablespace.


  1. Операторы ANALYZE TABLE, CHECK TABLE, OPTIMIZE TABLE И REPAIR TABLE.
  2. Операторы CREATE DATABASE И DROP DATABASE.
  3. Оператор DO.
  4. EXPLAIN SELECT — для получения описания способа объединения таблиц в за­ просе.
  5. Операторы FLUSH и RESET.
  6. Оператор SET.
  7. Оператор show.
  8. LOAD DATA INFILE. Во многих случаях этот синтаксис совместим с аналогич­ ным синтаксисом Oracle.
  9. RENAME TABLE.
  10. REPLACE вместо DELETE + INSERT.
  11. Конструкции CHANGE имя_столбца, DROP имя_столбца, DROP INDEX, IGNORE и RENAME в операторе ALTER TABLE. Использование множественных конструкций ADD, ALTER, DROP И CHANGE в операторе ALTER TABLE.
  12. Использование имен индексов, индексов в префиксах полей, а также конст­ рукций INDEX ИЛИ KEY В операторе CREATE TABLE.
  13. Использование IF EXISTS вместе с DROP TABLE.
  14. Можно удалять несколько таблиц одним оператором DROP TABLE.
  15. Конструкции ORDER BY и LIMIT В операторах UPDATE И DELETE.
  16. Синтаксис INSERT INTO. SET имя_столбца = .
  17. Конструкция DELAYED в операторах INSERT и REPLACE.
  18. Конструкция LOW_PRIORITY В операторах INSERT, REPLACE, DELETE И UPDATE.
  19. Использование INTO OUTFILE и STRAIGHT_JOIN в операторе SELECT.
  20. ОПЦИЯ SQL_SMALL_RESULT оператора SELECT.

Нет необходимости перечислять все выбранные столбцы в конструкции GROUP BY. Это обеспечивает лучшую производительность для некоторых очень спе­ цифических, но вполне нормальных запросов.

  • Можно применять ASC или DESC вместе с GROUP BY.
  • Имеется возможность присваивать значения переменным с помощью операции присваивания:= в операторах:

    mysql; SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg -; FROM test_table; mysql; SELECT @tl:=(@t2:=l)[email protected]:=4,@tl,@t2,@t3; м Типы столбцов. Типы столбцов mediumint, set, enum и различные варианты типов blob и text. Атрибуты столбцов AUTO_INCREMENT, BINARY, NULL, UNSIGNED И ZEROFILL.

    • Функции и операции.
    1. Чтобы облегчить жизнь пользователям, привыкшим к другим SQL-средам, сервер MySQL поддерживает псевдонимы для многих функций. Например, все строковые функции поддерживают как стандартный синтаксис SQL, так и син­ таксис ODBC.
    2. Сервер MySQL воспринимает операции и | | как логическое И (AND) и логическое ИЛИ (OR), по аналогии с языком программирования С. В кон­ тексте сервера MySQL операции | | и OR являются синонимами, равно как и и AND. По этой причине MySQL не поддерживает стандартную SQL-операцию | | для конкатенации строк. Вместо этого необходимо применять функцию CONCAT (). Поскольку CONCAT () принимает любое количество аргументов, пре­ образовать все операции | | очень легко.
    3. Использование COUNT(DISTINCT список), где список содержит более одного элемента.
    4. Все сравнения строк по умолчанию чувствительны к регистру, а порядок сор­ тировки определяется текущим выбранным набором символов (по умолчанию ISO-8859-1 Latinl). Если это не подходит, потребуется объявить столбец с ат­ рибутом BINARY либо воспользоваться приведением к BINARY, что заставит вы­ полнять сравнение и сортировку в соответствии с кодами символов, а не в лек­ сикографическом порядке.
    5. Операция % является синонимом функции MOD (). То есть, выражение N % м эквивалентно MOD (N, м). «%» поддерживается для удобства программистов на языке С и достижения совместимости с СУБД PostgresSQL.
    6. Операции =, о,=, ;=, ;, «, »,=;, AND, OR и LIKE могут применяться для сравнения столбцов слева от конструкции from в операторах SELECT, например: mysql; SELECT col1=1 AND col2=2 FROM имя таблицы;
    7. Функция LAST_INSERT_ID () возвращает самое последнее значение AUTO_INCREMENT.
    8. LIKE можно применять к числовым столбцам.
    9. Расширенные операции обработки регулярных выражений REGEXP и NOT REGEXP.
    1. Функции C0NCAT () и CHAR () принимают один и более аргументов.
    2. Функции BIT_COUNT(), CASE, ELT(), FROM_DAYS(), FORMAT(), IF(), PASSWORD!), ENCRYPT (),MD5(), ENCODE(), DECODE (), PERIOD_ADD(), PERIOD_DIFF(), TO_DAYS () И WEEKDAY !).
    3. Применение TRIMO для усечения подстрок. Стандартный язык SQL поддер­ живает только удаление последовательностей одинаковых символов.
    4. Возможность в конструкции GROUP BY обращаться к функциям STD (), BIT__OR(),BIT_AND(),BIT_XOR() И GROUP_CONCAT().

    Для ознакомления с перечнем новых расширений, которые планируется добавить в сервер MySQL, а также с их приоритетностью, просмотрите список TODO по адресу http://dev.mysql.com/doc/mysql/en/TODO.html. В настоящем руководстве представле­на последняя на данный момент версия списка TODO. См. также раздел MySQL и будущее (списки TODO).

    Прежде, чем приступить к статье, объяснющей разницу между SQL и MySQL , я поздравлю Вас с Новым годом , годом кролика. Желаю в Новом году Вам побольше удачи, побольше целеустремлённости и побольше упорства. Ведь главное в жизни — это достигать своих целей , а они достигаются только упорными людьми. Будьте упорны и настойчивы, и тогда в Новом году Вы будете победителем в любой сфере ! А теперь вернёмся к делу.

    Я достаточно часто встречаю вопрос: «Какая разница между SQL и MySQL «, и я решил ответить на этот вопрос, несмотря на всю его абсурдность. Ведь с тем же успехом можно спросить: «Какая разница между сервером Apache и PHP «, но это почему-то никто не спрашивает.

    В общем, отвечаю на вопрос. SQL — это язык запросов для управления СУБД (система управления базами данных ). А MySQL — это одна из таких СУБД . В частности, помимо MySQL существуют и другие СУБД : Oracle , MS SQL Server , PostgreSQL и много других. И чтобы работать (сделать выборку, вставить новую запись, добавить новую таблицу и так далее) с любой из этих СУБД необходим язык запросов, и таким языком и является SQL .

    • SQL — язык запросов для управления СУБД .
    • MySQL — это одна из множества других СУБД .

    Надеюсь, я ответил на этот один из самых популярных вопросов среди новичков, которые только начинают заниматься базами данных. Хотя нет, Вы не новички, Вы молодцы ! Как показывает практика, люди не двигаются дальше HTML и CSS (редко JavaScript). И если Вы решили заниматься базами данных, то Вы уже герой! Так что Вы не новички, а просто начинающие познавать действительно важные и, в общем-то, сложные вещи. Удачи Вам в этом!

    Хочется задать вот какой вопрос. Насколько велики различия между SQL -диалектами у разных СУБД? Например, у MySQL, PostgreSQL, MSSQL, Oracle. То есть, конечно, понятно, что SQL — это стандарт. Но одинаково ли все СУБД его поддерживают?

    Сам я работал только с MySQL. И создавая серьёзный проект (PHP) с прицелом на будущее, хочется на архитектурном уровне предусмотреть возможность работы с другими СУБД. И сейчас решаю, как это лучше сделать. Достаточно ли будет создать функцию-обертку для вызова SQL-запроса или придётся создавать функцию для каждого действия с БД, которая в зависимости от выбранной СУБД будет посылать запросы для СУБД на понятном ей SQL-диалекте?

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

    «Различия не столько в диалекте (хотя они есть, и их не так мало)»

    Гм, а если строго придерживаться SQL -стандарта, могу я расчитывать на адекватную их работу во всех СУБД?

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

    Собственно, всё, что хочется — это SELECT, UPDATE, REPLACE, INSERT. Довольно простые условия.

    Хотя, на этом думается, стоит ли вообще распылять себя на разные БД (тем более, такие, какие вряд ли будут на хостинге — вроде Oracle) и сконцентрироваться на максимальной поддержке и качества кода для одной-двух СУБД?

    • В MySQL 4.0 нет поддержки вложенных запросов(отказ от вложенных запросов или ограничение версий)
    • В Pg (в Orcale вроде тоже) нет возможности сортировать по полям не входящим в DISTINCT выборку(вложенные запросы)
    • В Pg отвратительная оптимизация DISTINCT запросов(обходится усложнением логики построения запроса)
    • СУБД по разному сортируют NULLы (ничего не поделать, возможно можно настроить на сервере)
    • В Oracle нет LIMIT, OFFSET(эмуляция через вложенные запросы)
    • По разному интерпретируются начальные и конечные пробелы в CHAR полях (приходится приводить к одному виду)
    • В MySQL при обычных настройках обрезается строка при превышении длинны без сообщении о ошибке
    • В MySQL поиск обычно case insensetive, а в Pg нужно для этого использовать LOWER или ILIKE, оба варианта могут замедлить производительность (не помню какой быстрее).
    • В Pg нет возможности использовать альяс в конструкции FROM до его определния.
    • Разный подход к обработке строк: кодировки, валидность, длинна, экранирование.

    Это маленький список того, что вспомнилось сходу.

    Вам проще будет пользоваться готовой библиотекой абстракции, типа Pear:: DB .

    Я эту фразу с недавних пор считаю в крайней степени не правдой.
    Ибо уровнем абстракции придется учиться пользоваться отдельно. Зачастую различия в синтаксисе встречаются там, где их совсем не ждешь. И, хоть и в большинстве ADBL есть инструменты «универсализации», не всегда догадаешся, в каком случае надо что-то искать а в каком не надо.

    З.Ы. Для меня совсем недавно стало откровением что в MSSQL»е нет даже примерного аналога offset»а или rownum(). (для мускуля: limit a,b). В результате adodb»шный лимит пришлось юзать да и тот тормозил (что естественно)

    Ну, я думаю это понятно, что чем универсальней какая-либо библиотека — тем меньше оптимизаций под performance в ней будет. Т.е. вся абстракция сводится только к простейшим вещам. Если нужно писать более сложные запросы, к примеру с большим количеством JOIN»ов или SubSelect»ов — тогда, имхо, только руками. Если я не прав — поправьте.

    p.s.
    я всегда, по возможности, стараюсь жёстко зацепиться за платформу, и пользовать её по максимуму. (Правда и софт в основном пишу по заказу, под конкретную платформу)

    Вообще, правильное решение тут — вынесение всего общения с базой на отдельный уровень модели. Тогда при возможном портировании с SQLLite на Oracle потребуется переписать только этот уровень. Пытаться же писать совместимые SQL -запросы, мне кажется, бесполезно — слишком большой бардак в диалектах.

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

    Василий Свиридов[досье] Чем большое количество присоединений и подзапросов отличается от малого? Мне кажется ничем. И система, которая умеет строить одно присоединение, может строить и 10-ть.

    2all: Вопрос в дизайне таких систем, достаточно сложно разработать гибкий дизайн, который позволит в полной мере использовать расширения той или иной СУБД, потому что иногда просто невозможно сделать приемлимую эмуляцию поведения на других БД. В таких случаях приходится жертвовать производительность и/или гибкостью.

    Давид Мзареулян[досье] Где-то так, так как задача прикладного характера и не является отдельным законченным продуктом, а только инструментом, то разрабатываться и развиваться должна только в рамках конкретных проектов.

    Закиров Руслан[досье] Отличается тем, что человек, имхо, сможет намного более эффективно соптимизировать сложный запрос, нежели скрипт. Хотя-бы потому, что человек может при этом учитывать схему базы и он знает, где можно жертвовать производительностью, а где — ну никак нельзя. (Моя аргументация правда начинает уходить от абстракции, так что на этом я закончу. А то оффтоп злостный пойдёт;))

    Тенденции баз данных в 2020 – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных

    Главное меню » Базы данных » Тенденции баз данных в 2020 – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных


    SQL против NoSQL

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

    Базы данных SQL

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

    Базы данных NoSQL

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

    В течение десятилетий SQL значительно опережал нереляционные альтернативы, но NoSQL быстро сокращает разрыв с такими популярными базами данных, как MongoDB, Redis и Cassandra. Хотя многие организации предпочитают переходить с устаревших баз данных, таких как Oracle, не все переходят на NoSQL. Исходя из наших выводов, SQL по-прежнему удерживает 60% при растущем спросе на такие системы, как PostgreSQL:

    Использование базы данных SQL: 60,48%

    Использование базы данных NoSQL: 39,52%

    Самые популярные базы данных

    Итак, какие базы данных наиболее популярны в 2020 году? Зная, что SQL использовали более 3/5 респондентов, вы можете предположить, что Oracle украл шоу. Угадай еще раз. MySQL доминировал в этом отчете с 38,9% использования, за ним следуют MongoDB с 24,6%, PostgreSQL с 17,4%, Redis с 8,4% и Cassandra с 3,0%. Oracle отставал от этих репортеров баз данных всего на 1,8%, а пользователи CouchDB, Berkeley DB, Microsoft SQL Server, Redshift, Firebase, Elasticsearch и InfluxDB объединили нашу категорию Other на 2,4%.

    Хотя эти цифры могут шокировать, нельзя забывать о росте популярности MySQL, MongoDB и PostgreSQL. Итак, как этот опрос сравнивается с наиболее известным источником тенденций системы управления базами данных? Рейтинг DB-Engines – Отчет о популярности Trend ставит этих лидеров в пятерку лидеров, но Oracle по-прежнему занимает первое место, а Microsoft SQL Server – третье.

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

    Использование одной базы данных и использование нескольких баз данных

    За последние десять лет использование нескольких типов баз данных значительно возросло по сравнению с традиционной стратегией, когда все яйца складываются в одну корзину. Сколько так? Почти половина организаций, с которыми мы говорили, на самом деле используют более одного типа базы данных для своих приложений, чем одну базу данных! 44,3% сообщили, что используют несколько баз данных, а 55,7% работают с одной:

    Тенденции баз данных в 2020 году – SQL против NoSQL, Лучшие базы данных, Использование одной или нескольких баз данных.

    SQL и NoSQL несколько комбинаций баз данных

    Итак, зная, что почти половина наших респондентов объединяют несколько баз данных для поддержки своих продуктов, какие типы систем управления базами данных они используют вместе? Это меньше шок, 75,6% использования нескольких типов баз данных состоит из комбинации баз данных SQL и NoSQL. Это подтверждает тот случай, что для многих организаций один размер подходит не всем. Хотя у вас может быть предпочтение по сравнению с SQL по сравнению с NoSQL, нельзя отрицать тот факт, что оба они предлагают явные преимущества другого. Вместо того чтобы ограничивать вашу организацию одним типом базы данных, развивайте (или разрабатывайте) свою стратегию данных для совместимости, чтобы эти мощные системы управления базами данных могли дополнять друг друга и заполнять пробелы в ваших потребностях в данных!

    Использование базы данных SQL + NoSQL: 75,6%

    Использование базы данных SQL + SQL: 14,6%

    Использование базы данных NoSQL + NoSQL: 9,8%

    Самые популярные множественные комбинации типов баз данных

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

    Очевидный победитель с более чем 1/3 использования нескольких типов баз данных – это комбинация MySQL и MongoDB. Хотя MongoDB часто считается альтернативой MySQL, две базы данных хорошо работают вместе при правильном проектировании. Вторым по популярности сочетанием были MySQL и PostgreSQL вместе. Эти две базы данных SQL являются явными конкурентами, но могут совместно использоваться для хранения различных наборов данных. Как вы можете видеть на приведенном выше графике раздела, представление MySQL и PostgreSQL на 9,76% составляет большую часть использования SQL + SQL в нескольких базах данных.

    MySQL + MongoDB: 34,15%

    MySQL + PostgreSQL: 9,76%

    MongoDB + PostgreSQL: 7,32%

    MongoDB + Redis: 7,32%

    MySQL + MongoDB + PostgreSQL: 4,88%

    MySQL + MongoDB + PostgreSQL + Redis: 4,88%

    Наиболее трудоемкая задача управления базой данных

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

    Мониторинг занял первое место с 12,6% от наших респондентов, едва опередив резервные копии, управляя дисковым пространством, масштабированием и объединением таблиц, которые все заняли второе место с 11,6% каждый. Автономным номером три было поддержание и перераспределение изменений между представлениями и хранимыми программами на уровне 8,7%, и снова связь под номером 4 с 7,2% для каждой очистки и настройки базы данных. Обновления заняли пятое место с 6,5%, а дюжина других задач составила 11,6% в другой категории, включая миграции, запросы, сравнение, настройку и репликацию.

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

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

    Время ответа на запрос было не только самым отслеживаемым показателем, но и большинством с 51,8% ответов! Мы ожидали, что это приведет к 30,8% из отчета «Задача управления PostgreSQL, который отнимает больше всего времени», который мы составили в октябре 2020 года, но значительно расширился, когда мы расширили этот вопрос до всех систем управления базами данных. Скорость запросов – это чрезвычайно важный показатель, который нужно отслеживать на постоянной основе, чтобы вы могли определить медленные запросы, которые могут повлиять на производительность вашего приложения. Многие администраторы баз данных используют инструмент Slow Query Analyzer для выявления проблемных запросов, просмотра того, с каким запросом он связан, понимания их запросов по временному диапазону и поиска самых популярных запросов, вызывающих нагрузку на чтение в вашей системе, для идентификации тех запросов, которые не проиндексированы.

    Второе место заняла достоверность с 18,2% респондентов. Излишне говорить, что хотя перебои в работе происходят реже, чем медленные запросы, если ваши базы данных выйдут из строя, это окажет самое серьезное влияние на вашу производительность. Вот почему крайне важно внедрить инфраструктуру высокой доступности для ваших производственных развертываний, чтобы поддерживать ваши базы данных в оперативном режиме, если в одном из ваших центров обработки данных произойдет сбой.

    Затем память заняла третье место с 8,2% ответов. Чем больше у вас памяти, тем лучше должна работать ваша база данных. Как понимание, так и мониторинг использования памяти должны занимать важное место в вашем списке, так как нехватка или исчерпание памяти приведет к тому, что ваша база данных будет читать и записывать данные на диск, что значительно медленнее.

    Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

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

    Сравнить несравнимое: json в PostgreSQL vs Mysql vs Mongodb

    As such, there’s really no “standard” benchmark that will inform you about the best technology to use for your application. Only your requirements, your data, and your infrastructure can tell you what you need to know.

    Для начала немного философии. NoSql окружает и от этого никуда не убежать (хотя не очень то и хотелось). Оставим вопросы о глубинных причинах за рамками данного текста, отметим лишь, что этот тренд отражается не только в появлении новых NoSql решений и развитии старых. Еще одна грань — смешение противоположностей, а именно поддержка хранения schema-less данных в традиционных реляционных базах. В этой серой области на стыке реляционной модели хранения данных и всего остального кроется головокружительное количество возможностей. Но, как и всегда, нужно уметь найти баланс, который подходит именно для ваших данных. Это бывает трудно, в первую очередь из-за того, что приходится сравнивать мало сравнимые вещи, например, производительность NoSql решения с традиционной базой данных. В этой небольшой заметке будет предложена такая попытка и приведено сравнение производительности работы с jsonb в PostgreSQL с json в Mysql и с bson в Mongodb.

    Что, черт возьми, вообще происходит?

    Краткие вести с полей:

    • PostgreSQL 9.4 — новый тип данных jsonb, поддержка которого будет немного расширена в грядущей PostgreSQL 9.5
    • Mysql 5.7.7 — новый тип данных json

    и ряд других примеров, о которых расскажу в следующий раз. Замечательно то, что эти типы данных предполагают не текстовое, а бинарное хранение json, что делает работу с ним гораздо шустрее. Базовый функционал везде идентичен, т.к. это очевидные требования — создать, выбрать, обновить, удалить. Самое древнейшее, почти пещерное, желание человека в этой ситуации — провести ряд benchmark’ов. PostgreSQL & Mysql выбраны, т.к. реализация поддержки json очень похожа в обоих случаях (к тому же они находятся в одинаковой весовой категории), ну а Mongodb — как старожил NoSql мира. Работа, проведенная EnterpriseDB, немного в этом плане устарела, но ее можно взять, в качестве первого шага для дороги в тысячу ли. На данный момент целью данной дороги является не показать, кто быстрее/медленее в искусственных условиях, а постараться дать нейтральную оценку и получить feedback.

    Исходные данные и некоторые детали

    pg_nosql_benchmark от EnterpriseDB предполагает достаточно очевидный путь — сначала генерируется заданный объем данных разного вида с легкими флуктуациями, который затем записывается в исследуемую базу и по нему происходят выборки.
    Функционал для работы с Mysql в нем отсутствует, поэтому его понадобилось реализовать на основе аналогичного для PostgreSQL. На данном этапе есть только одна тонкость, когда мы задумываемся об индексах — дело в том, что в Mysql не реализовано
    индексирование json на прямую, поэтому приходится создавать виртуальные колонки и индексировать уже их. Помимо этого, меня смутило то, что для mongodb часть сгенерированных данных размером превышает 4096 байт и не вмещается в буфер mongo shell, т.е. просто отбрасывается. В качестве хака получилось выполнять insert’ы из js файла (который еще и приходится разбивать несколько chunk’ов, т.к. один не может быть больше 2GB).

    Со всеми полученными изменениями проверки проводились для следующих случаев:

    • PostgreSQL 9.5 beta1, gin
    • PostgreSQL 9.5 beta1, jsonb_path_ops
    • PostgreSQL 9.5 beta1, jsquery
    • Mysql 5.7.9
    • Mongodb 3.2.0 storage engine WiredTiger
    • Mongodb 3.2.0 storage engine MMAPv1

    Каждый из них был развернут на отдельном m4.xlarge инстансе с ubuntu 14.04 x64 на борту с настройками по умолчанию, тесты проводились на количестве записей, равном 1000000. Для тестов с jsquery надо прочитать readme и не забыть
    установить bison, flex, libpq-dev и даже postgresql-server-dev-9.5. Результаты будут сохранены в json файл, который можно визуализировать с помощью matplotlib (см. здесь).

    Картинки


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

    Insert

    Select

    Update

    Еще одним изменением относительно оригинального кода pg_nosql_benchmark было добавление тестов на обновление.
    Здесь явным лидером оказалась Mongodb, скорее всего за счет того, что в PostgreSQL и Mysql обновление даже одного значения
    на данным момент означает перезапись всего поля.

    Table/index size

    I have a bad feeling about this

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

    Подключение к базе данных

    Цель лекции: Рассмотреть основные особенности поддерживаемых баз данных; ознакомились со структурой файла миграции; рассмотреть особенности использования Django с NoSQL, реализовали простейший проект MongoDB на Django.

    Ключевые термины: Django, база, фреймворк, файл , SQL , миграция, проект, данные, field , class , url, python , схема, модель, слияние

    Django — это фреймворк с агностическим подходом к базе данных, это означает, что поля базы данных , предоставляемых Django предназначены для работы в разных базах данных, таких как SQLite, Oracle , MySQL и PostgreSQL. Действительно, они также работают с некоторыми сторонними базами данных. PostgreSQL является небольшой базой данных для Django в рабочей фазе, в то время как для окружения разработки используется SQLite, и вы в конечном итоге проделаете много работы, если не захотите использовать СУБД для вашего проекта. Эта лекция даст вам подробную разницу между двумя типами и покажет вам, что лучше подходит для Django, и, так же, как мы действительно можем их имплементировать в наш проект Django.

    Прежде всего, давайте посмотрим на разницу между SQL и NoSQL.

    SQL против NoSQL

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

    Мы поговорим о высокоуровневых различиях между SQL и NoSQL. Ниже приведены различия между ними:

    SQL база данных (RDBMS) База данных NoSQL
    SQL базы данных являются реляционными базами данных (СУБД) Баз данных NoSQL- нереляционные или распределенные базы данных
    SQL базы данных основаны на таблицах и ее отношения с другими таблицами NoSQL -документальная, пары ключ -значение, графические базы данных или хранение широких столбцов
    База данных SQL хранит свои данные в строках таблицы NoSQL — это коллекция значений пара-ключ документов, графических данных или широкостолбцовых хранилищ
    SQL базы данных имеют предопределенные схемы NoSQL имеет динамическую схему
    Базы данных SQL вертикально масштабируемы Базы данных SQL горизонтально масштабируемы
    Примеры баз данных SQL: MySQL, Oracle, SQLite, PostgreSQL и MS SQL Примеры баз данных NoSQL: MongoDB, BigTable, Redis, RavenDB, Cassandra, HBase, Neo4j и CouchDB

    Давайте попробуем понять основные особенности некоторых из известных баз данных SQL и NoSQL.

    Базы данных SQL

    Следующие разделы посвящены различным SQL базами данных и их использованию.

    MySQL – open source

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

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

    PostgreSQL

    Как упоминалось ранее, PostgreSQL является наиболее популярной базы данных в рамках сообщества Django. Он также имеет широкий набор функций, поддерживаемый основными базами данных.

    Развитие расширенных запросов и особенностей PostgresSQL сделали возможным достигнуть комплексной строки обычного запроса SQL в гораздо более простой строке для записи запроса. Однако имплементация массивов, hstore, JSON и так далее сложнее с помощью обычных SQL баз данных.

    NoSQL базы данных

    Эта концепция была введена, когда горизонтальное масштабирование было непросто осуществить и базы данных на основе реляционных СУБД не могли масштабироваться, так как должны были. Часто этот термин расшифровывается Not Only SQL (Не только SQL ). Он предоставляет механизм для хранения и извлечения данных, отличных от традиционных методов SQL .

    MongoDB

    MongoDB – одна из самых популярных документальных NoSQL баз данных, так как она хранит данные в JSON-подобных документах. Это нереляционная база данных с динамической схемой. Она была разработана основателями компании DoubleClick. Она написана на C++ и в настоящее время используется в некоторых крупных компаниях, таких как The New York Times, Craigslist и MTV Networks. Ниже приведены некоторые преимущества и сильные стороны MongoDB:

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

    CouchDB

    CouchDB является также документальной базой данных NoSQL. Он хранит данные в виде документов JSON. Ниже приведены некоторые преимущества и сильные стороны CouchDB:

    • Без схемы: будучи членом семейства NoSQL, она также имеет свойство без схемы, которое делает ее более гибким, поскольку у него есть формат документов JSON для хранения данных
    • HTTP-запрос: вы можете получить доступ к вашей документальной базе данных, используя веб-браузер
    • Разрешение конфликтов: Имеется автоматическая система разрешения конфликтов, которая является полезной, когда вы собираетесь использовать распределенную базу данных
    • Легкость репликации: репликация довольно проста

    Redis

    Redis является еще одной базой данных NoSQL open source, которая используется главным образом в связи с молниеносной скоростью. Она написана на языке ANSI С. Ниже приведены некоторые преимущества и сильные стороны Redis:

    Ответы на вопросы на собеседование 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 использует «Коллекции» (collections).

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

    The SQL vs NoSQL Difference: MySQL vs MongoDB

    When it comes to choosing a database, one of the biggest decisions is picking a relational (SQL) or non-relational (NoSQL) data structure. While both are viable options, there are certain key differences between the two that users must keep in mind when making a decision.

    Here, we break down the most important distinctions and discuss two of the key players in the relational vs non-relational debate: MySQL and MongoDB. Read this article and many more on Xplenty’s blog:

    Что такое NoSQL?

    Высокопроизводительные нереляционные базы данных с гибкими моделями данных

    Что такое базы данных NoSQL?

    Базы данных NoSQL специально созданы для определенных моделей данных и обладают гибкими схемами, что позволяет разрабатывать современные приложения. Базы данных NoSQL получили широкое распространение в связи с простотой разработки, функциональностью и производительностью при любых масштабах. В них применяются различные модели данных, в том числе документные, графовые, поисковые, с использованием пар «ключ‑значение» и хранением данных в памяти. Ресурсы, представленные на этой странице, помогут разобраться с базами данных NoSQL и начать работу с ними.

    Как работает база данных NoSQL (нереляционная БД)?

    В базах данных NoSQL для доступа к данным и управления ими применяются различные модели данных, в том числе документная, графовая, поисковая, с использованием пар «ключ‑значение» и хранением данных в памяти. Базы данных таких типов оптимизированы для приложений, которые работают с большим объемом данных, нуждаются в низкой задержке и гибких моделях данных. Все это достигается путем смягчения жестких требований к непротиворечивости данных, характерных для других типов БД.

    Рассмотрим пример моделирования схемы для простой базы данных книг.

    • В реляционной базе данных запись о книге часто разделяется на несколько частей (или «нормализуется») и хранится в отдельных таблицах, отношения между которыми определяются ограничениями первичных и внешних ключей. В этом примере в таблице «Книги» имеются столбцы «ISBN», «Название книги» и «Номер издания», в таблице «Авторы» – столбцы «ИД автора» и «Имя автора», а в таблице «Автор–ISBN» – столбцы «Автор» и «ISBN». Реляционная модель создана таким образом, чтобы обеспечить целостность ссылочных данных между таблицами в базе данных. Данные нормализованы для снижения избыточности и в целом оптимизированы для хранения.
    • В базе данных NoSQL запись о книге обычно хранится как документ JSON. Для каждой книги, или элемента, значения «ISBN», «Название книги», «Номер издания», «Имя автора и «ИД автора» хранятся в качестве атрибутов в едином документе. В такой модели данные оптимизированы для интуитивно понятной разработки и горизонтальной масштабируемости.

    Для чего можно использовать базы данных NoSQL?

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

    • Гибкость. Как правило, базы данных NoSQL предлагают гибкие схемы, что позволяет осуществлять разработку быстрее и обеспечивает возможность поэтапной реализации. Благодаря использованию гибких моделей данных БД NoSQL хорошо подходят для частично структурированных и неструктурированных данных.
    • Масштабируемость. Базы данных NoSQL рассчитаны на масштабирование с использованием распределенных кластеров аппаратного обеспечения, а не путем добавления дорогих надежных серверов. Некоторые поставщики облачных услуг проводят эти операции в фоновом режиме, обеспечивая полностью управляемый сервис.
    • Высокая производительность. Базы данных NoSQL оптимизированы для конкретных моделей данных (например, документной, графовой или с использованием пар «ключ‑значение») и шаблонов доступа, что позволяет достичь более высокой производительности по сравнению с реляционными базами данных.
    • Широкие функциональные возможности. Базы данных NoSQL предоставляют API и типы данных с широкой функциональностью, которые специально разработаны для соответствующих моделей данных.

    Типы баз данных NoSQL

    БД на основе пар «ключ‑значение». Базы данных с использованием пар «ключ‑значение» поддерживают высокую разделяемость и обеспечивают беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД. Хорошими примерами использования для баз данных типа «ключ‑значение» являются игровые, рекламные приложения и приложения IoT. Amazon DynamoDB обеспечивает стабильную работу БД с задержкой не более нескольких миллисекунд при любом масштабе. Такая устойчивая производительность послужила основной причиной переноса Snapchat Stories в сервис DynamoDB, поскольку эта возможность Snapchat связана с самой большой нагрузкой на запись в хранилище.

    Документ В коде приложения данные часто представлены как объект или документ в формате, подобном JSON, поскольку для разработчиков это эффективная и интуитивная модель данных. Документные базы данных позволяют разработчикам хранить и запрашивать данные в БД с помощью той же документной модели, которую они используют в коде приложения. Гибкий, полуструктурированный, иерархический характер документов и документных баз данных позволяет им развиваться в соответствии с потребностями приложений. Документная модель хорошо работает в каталогах, пользовательских профилях и системах управления контентом, где каждый документ уникален и изменяется со временем. Amazon DocumentDB (совместимая с MongoDB) и MongoDB — распространенные документные базы данных, которые предоставляют функциональные и интуитивно понятные API для гибкой разработки.


    Графовые БД. Графовые базы данных упрощают разработку и запуск приложений, работающих с наборами сложносвязанных данных. Типичные примеры использования графовых баз данных – социальные сети, сервисы рекомендаций, системы выявления мошенничества и графы знаний. Amazon Neptune – это полностью управляемый сервис графовых баз данных. Neptune поддерживает модель Property Graph и Resource Description Framework (RDF), предоставляя на выбор два графовых API: TinkerPop и RDF / SPARQL. К числу распространенных графовых БД относятся Neo4j и Giraph.

    БД в памяти. Часто в игровых и рекламных приложениях используются таблицы лидеров, хранение сессий и аналитика в реальном времени. Такие возможности требуют отклика в пределах нескольких микросекунд, при этом резкое возрастание трафика возможно в любой момент. Amazon ElastiCache предлагает Memcached и Redis для обработки высокопроизводительных рабочих нагрузок с низкой задержкой, которые нельзя обработать с помощью дисковых хранилищ данных. Такие рабочие нагрузки характерны, например, для сети McDonald’s. Еще одним примером специально разработанного хранилища данных является Amazon DynamoDB Accelerator (DAX). DAX позволяет DynamoDB считывать данные в несколько раз быстрее.

    Поисковые БД. Многие приложения формируют журналы, чтобы разработчикам было проще выявлять и устранять неполадки. Amazon Elasticsearch Service (Amazon ES) – специально разработанный сервис для визуализации и аналитики автоматически генерируемых потоков данных в режиме, близком к реальному времени, путем индексирования, агрегации частично структурированных журналов и метрик и поиска по ним. Amazon ES – это также мощная высокопроизводительная поисковая система для полнотекстового поиска. Компания Expedia задействует более 150 доменов Amazon ES, 30 ТБ данных и 30 миллиардов документов для разнообразных особо важных примеров использования – от операционного мониторинга и устранения неисправностей до отслеживания стека распределенных приложений и оптимизации затрат.

    Сравнение баз данных SQL (реляционных) и NoSQL (нереляционных)

    В течение десятилетий центральное место в разработке приложений занимала реляционная модель данных, которая использовалась в реляционных базах данных, таких как Oracle, DB2, SQL Server, MySQL и PostgreSQL. Но в середине – конце 2000‑х годов заметное распространение стали получать и другие модели данных. Для обозначения появившихся классов БД и моделей данных был введен термин «NoSQL». Часто «NoSQL» используется в качестве синонима к термину «нереляционный».

    Существует множество типов БД NoSQL с различными особенностями, но в таблице ниже приведены основные отличия баз данных NoSQL от SQL.

    Подходящие рабочие нагрузки

    Реляционная модель нормализует данные и преобразует их в таблицы, состоящие из строк и столбцов. Схема жестко задает таблицы, строки, столбцы, индексы, отношения между таблицами и прочие элементы базы данных. Такая БД обеспечивает целостность ссылочных данных в отношениях между таблицами.

    Реляционные базы данных обеспечивают набор свойств ACID: атомарность, непротиворечивость, изолированность, надежность.

    • Атомарность требует, чтобы транзакция выполнялась полностью или не выполнялась вообще.
    • Непротиворечивость означает, что сразу по завершении транзакции данные должны соответствовать схеме базы данных.
    • Изолированность требует, чтобы параллельные транзакции выполнялись отдельно друг от друга.
    • Надежность подразумевает способность восстанавливаться до последнего сохраненного состояния после непредвиденного сбоя в системе или перебоя в подаче питания.
    Реляционные базы данных Базы данных NoSQL
    Реляционные БД предназначены для транзакционных и строго непротиворечивых приложений обработки транзакций в режиме реального времени (OLTP) и хорошо подходят для аналитической обработки в режиме реального времени (OLAP). Базы данных NoSQL (на основе пар «ключ‑значение», документные, графовые и работающие в памяти) ориентированы на OLTP для целого ряда шаблонов доступа к данным, в том числе для приложений с низкой задержкой. Поисковые БД NoSQL предназначены для аналитики частично структурированных данных.
    Модель данных В базах данных NoSQL применяются различные модели данных, в том числе документные, графовые, поисковые, с использованием пар «ключ‑значение» и хранением данных в памяти.
    Свойства ACID Базы данных NoSQL зачастую предлагают компромисс, смягчая жесткие требования свойств ACID ради более гибкой модели данных, которая допускает горизонтальное масштабирование. Благодаря этому БД NoSQL – отличный выбор для примеров использования с высокой пропускной способностью и низкой задержкой, в которых требуется горизонтальное масштабирование, не ограниченное рамками одного инстанса.
    Производительность Производительность главным образом зависит от дисковой подсистемы. Для обеспечения максимальной производительности часто требуется оптимизация запросов, индексов и структуры таблицы. Производительность обычно зависит от размера кластера базового аппаратного обеспечения, задержки сети и вызывающего приложения.
    Масштабирование Реляционные базы данных обычно масштабируются путем увеличения вычислительных возможностей аппаратного обеспечения или добавления отдельных копий для рабочих нагрузок чтения. Базы данных NoSQL обычно поддерживают высокую разделяемость благодаря шаблонам доступа на основе пар «ключ‑значение» с возможностью масштабирования на основе распределенной архитектуры. Это повышает пропускную способность и обеспечивает устойчивую производительность почти в неограниченных масштабах.
    API Запросы на запись и извлечение данных составляются на языке SQL. Эти запросы анализирует и выполняет реляционная база данных. Объектно‑ориентированные API позволяют разработчикам приложений без труда осуществлять запись и извлечение структур данных, размещенных в памяти. Благодаря использованию ключей секций приложения могут вести поиск по парам «ключ‑значение», наборам столбцов или частично структурированным документам, содержащим серийные объекты и атрибуты приложений.

    Сравнение терминологии SQL и NoSQL

    В следующей таблице приведено сравнение терминологии некоторых баз данных NoSQL с терминологией баз данных SQL.

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

    .collapse»>Содержание

    Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2020.

    Если посмотреть такой известный 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.

    The SQL vs NoSQL Difference: MySQL vs MongoDB

    When it comes to choosing a database, one of the biggest decisions is picking a relational (SQL) or non-relational (NoSQL) data structure. While both are viable options, there are certain key differences between the two that users must keep in mind when making a decision.

    Here, we break down the most important distinctions and discuss two of the key players in the relational vs non-relational debate: MySQL and MongoDB. Read this article and many more on Xplenty’s blog:

    MySQL против MonoDB 1000 читает

    Я очень волновался о MongoDb и тестировал его в последнее время. У меня была таблица с сообщениями в MySQL с примерно 20 миллионами записей, индексированных только в поле под названием «id».

    Я хотел сравнить скорость с MongoDB, и я провел тест, который будет получать и печатать 15 записей случайным образом из наших огромных баз данных. Я запросил около 1000 раз каждый для mysql и MongoDB, и я удивлен, что не вижу большой разницы в скорости. Возможно, MongoDB в 1,1 раза быстрее. Это очень разочаровывает. Есть ли что-то, что я делаю неправильно? Я знаю, что мои тесты не идеальны, но MySQL наравне с MongoDb, когда дело доходит до чтения интенсивных обязанностей.

    • У меня есть двухъядерный + (2 потока) i7 cpu и 4GB ram
    • У меня есть 20 разделов на MySQL каждый из 1 миллиона записей

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

    Пример кода для тестирования MySQL

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

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

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

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

    В MongoDB для извлечения всего объекта вам необходимо выполнить:

    • Один индексный поиск в коллекции (при условии, что объект извлекается с помощью id)
    • Получить содержимое одной страницы базы данных (фактический двоичный json-документ)

    Итак, поиск в b-tree и чтение двоичной страницы. Log (n) + 1 IO. Если индексы могут полностью находиться в памяти, тогда 1 IO.

    В MySQL с 20 таблицами вы должны выполнить:

    • Один индексный поиск в корневой таблице (опять же, предполагая, что объект извлекается id)
    • С кластерным индексом мы можем предположить, что значения для корневой строки находятся в индексе
    • 20 + поиск диапазона (надеюсь, по индексу) для объекта pk value
    • Они, вероятно, не являются кластеризованными индексами, поэтому те же 20 + поиск данных, когда мы выясним, что представляют собой соответствующие дочерние строки.

    Таким образом, общая сумма для mysql, даже если предположить, что все индексы находятся в памяти (что сложнее, чем в 20 раз больше), это около 20 запросов диапазона.

    Эти поисковые запросы диапазона, вероятно, состоят из случайных IO — разные таблицы, безусловно, будут находиться в разных местах на диске, и возможно, что разные строки в одном и том же диапазоне в одной таблице для объекта могут не быть смежными (в зависимости от того, как объект обновлен и т.д.).

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

    Именно так MongoDB может повысить производительность в некоторых случаях использования.

    Мастер Йода рекомендует:  OAuth 2.0 – хороший, плохой, злой…
  • Добавить комментарий