SQL против NoSQL – что вы должны использовать для вашего следующего проекта?

Один из наиболее часто задаваемых вопросов – какую базу данных мне использовать …


SQL расшифровывается как язык структурированных запросов. Впервые он был разработан в 1970-х годах группой исследователей из IBM. С другой стороны, базы данных NoSQL впервые были использованы в 1998 году Карло Строцци..

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

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

Структура базы данных

Давайте поговорим о структурировании.

SQL

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

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

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

Например, давайте рассмотрим гипотетическую ситуацию; У нас есть компания с пользователями, и пользователи могут делать заказы на товары. Затем мы можем решить, что пользователи могут создавать несколько заказов, но каждый заказ может быть создан только одним пользователем. Это будут отношения один ко многим, то есть один пользователь ко многим заказам. Следовательно, структура таблицы для обеих таблиц будет выглядеть примерно так:.

В нашей БД у нас может быть таблица пользователей, структурированная как показано ниже,

users_table
—————————————————-
id | имя | электронное письмо
—————————————————–
1 Идрис [Электронная почта защищена]

Кроме того, мы могли бы иметь таблицу заказов

orders_table
———————————————————————————
id | user_id | порядковый номер
———————————————————————————
1 1 20000001

User_id в таблице заказов позволяет легко сопоставить каждый заказ в таблице заказов с пользователем, которому он принадлежит. В случае отношения «один к одному», мы могли бы также указать order_id в users_table, если мы решим получить пользователя по его связанному идентификатору заказа..

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

users_table
————————————————————————————-
id | имя | электронное письмо
————————————————————————————-
1 Идрис [Электронная почта защищена]

и таблица заказов будет

orders_table
———————————————————
id | порядковый номер
———————————————————
1 2000001

а затем сводная таблица будет содержать оба идентификатора в качестве внешних ключей.

users_orders_table
——————————————————————————
id | код заказа | ID пользователя
——————————————————————————
1 1 1

Основываясь на этой структуре, предоставляемой SQL, вы можете удобно писать соединения между таблицами, которые будут предоставлять данные из разных таблиц, объединенных в один запрос..

NoSQL

NoSQL базы данных были построены так, чтобы быть более гибкими, чем базы данных SQL, и содержать большие объемы данных.

В NoSQL DB нет предопределенной схемы или таблиц. Есть Коллекции, и в каждой Коллекции есть Документы. Это позволяет вам сохранять данные в разных формах по мере их поступления. Вы можете выбрать несколько разных документов с разными полями в одной коллекции. Также возможно вручную установить отношения между коллекциями. Однако они не подходят для такой цели. Вместо этого вы можете сохранить все, что нужно для одного запроса, в одну коллекцию..

Если вы человек SQL, вы можете рассматривать Коллекции как таблицы, а Документы – как строки с таблицами. Тем не менее, нет никаких ограничений на столбцы данных, которые вы можете добавить с таблицей.

Возвращаясь к нашему ранее определенному гипотетическому примеру компании с пользователями и заказами.

Коллекция пользователей может быть определена как,

{id: 1, имя: ‘idris’, электронная почта: ‘[Электронная почта защищена]}

И Коллекция заказов может быть определена как,

{id: 1, порядковый номер: 2000001, user_id: 1}

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

{id: 1, порядковый номер: 200001, пользователь {id: 1, имя: ‘idris’, электронная почта: ‘[Электронная почта защищена]}}

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

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

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

пересчет

Давайте рассмотрим, как работает масштабирование.

SQL

Базы данных SQL нельзя масштабировать по горизонтали, а только по вертикали. Что это вообще значит?

Горизонтальное масштабирование означает разделение данных из одной БД на несколько баз данных для облегчения загрузки. Однако данные SQL нельзя разделить на отдельные БД из-за их строгой природы. Правильно масштабировать БД SQL – это увеличивать ЦП, память и дисковое пространство существующего сервера БД, и именно это означает его вертикальное масштабирование..

горизонтальное масштабирование

вертикальное масштабирование


NoSQL

БД NoSQL можно масштабировать как по горизонтали, так и по вертикали. Это связано с гибкостью хранения данных. Таким образом, это позволяет разделять его данные на несколько баз данных, как в случае горизонтального масштабирования. При необходимости он может быть масштабирован по вертикали..

Ключевая вещь, чтобы отметить здесь: Когда дело доходит до масштабирования, базы данных SQL и NoSQL могут эффективно масштабироваться. Однако для баз данных SQL вертикальное масштабирование может быть ограничением; один сервер БД будет иметь ограничение на количество вычислительной мощности, которую он может нести.

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

Что такое шардинг?

Осколок – это процесс разбиения больших таблиц на маленькие куски, которые называются осколками. Разделение может быть сделано путем горизонтального разделения базы данных. Это не следует путать с горизонтальным и вертикальным масштабированием. Горизонтальное разбиение относится к процессу хранения строк таблицы в нескольких узлах базы данных. Вертикальное разбиение, с другой стороны, требует сохранения столбцов таблицы на разных узлах. Это позволяет базе данных эффективно масштабироваться и повышать производительность.

Примеры базы данных

SQL

  • MySQL – очень популярная база данных с открытым исходным кодом. Тем не менее, база данных, удобная для многих разработчиков PHP, также может быть использована с Node.js, C #, C ++, Java, Perl, Ruby и Python..
  • MSSQL – Microsoft SQL обеспечивает большую стабильность, так как его разработка осуществляется непосредственно Microsoft, которая также предлагает некоторую поддержку в плане аварийного восстановления.
  • MariaDB – Он был построен на MySQL создателями MySQL, намереваясь сохранить MariaDB бесплатной навсегда.
  • PostgresSQL – очень популярная база данных с открытым исходным кодом. Гордится тем, что является самой передовой в мире базой данных с открытым исходным кодом.
  • Oracle – Обычно он адаптирован к корпоративным решениям Oracle с некоторыми ограничениями в бесплатной версии..

NoSQL

  • MongoDB – вероятно, самая известная NoSQL DB, распространенная среди разработчиков приложений, работающих со стеком MERN (MongoDB, Express, React, Node) или MEAN-стеком (MongoDB, Express, Angular, Node).
  • Firebase – Представленный в 2011 году и приобретенный Google в 2014 году, широко используется разработчиками веб-приложений и мобильных приложений.
  • Apache Couch DB – основанная на документе NoSQL DB, которая хранит данные в формате JSON.
  • Redis: Это NoSQL DB, вероятно, наиболее известна своим использованием для хранения данных с дополнительным временем жизни. Он также известен своей скоростью.

Вывод

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

TAGS:

  • База данных

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map