Один из наиболее часто задаваемых вопросов — какую базу данных мне использовать …
SQL расшифровывается как язык структурированных запросов.
Впервые он был разработан в 1970-х годах группой исследователей IBM.

С другой стороны, базы данных NoSQL впервые были использованы в 1998 году Карло Строцци.

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

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

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

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

SQL

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

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

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

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

Каждая таблица в базе данных SQL может быть связана, то есть, вы можете иметь отношения между таблицами.

Эти отношения могут быть один ко многим, многие ко многим или один к одному.

Тип ваших отношений зависит от того, что вам нужно.

Например, давайте рассмотрим гипотетическую ситуацию; У нас есть компания с пользователями, и пользователи могут делать заказы на товары.

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

Это будут отношения один ко многим, то есть один пользователь ко многим заказам.

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

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

users_table
----------------------------------------------------
id          |          name       |           email
-----------------------------------------------------
1                    Idris              idris@idrislawal.com
Кроме того, мы могли бы иметь таблицу заказов
orders_table
---------------------------------------------------------------------------------
id                   |             user_id             |             order_number
---------------------------------------------------------------------------------
1                                      1                               20000001
User_id в таблице заказов позволяет легко сопоставить каждый заказ в таблице заказов с пользователем, которому он принадлежит.

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

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

Это позволяет сопоставить несколько записей друг с другом.
Используя приведенный выше пример:
users_table
-------------------------------------------------------------------------------------
id               |                    name                   |                  email
-------------------------------------------------------------------------------------
1                               Idris                             idris@idrislawal.com
и таблица заказов будет такая
orders_table
---------------------------------------------------------
id                      |                    order_number
---------------------------------------------------------
1                                             2000001
и тогда в сводной таблице оба идентификатора будут храниться как внешние ключи.
users_orders_table
------------------------------------------------------------------------------
id               |                  order_id              |           user_id
------------------------------------------------------------------------------
1                                     1                                 1
Основываясь на этой структуре, предоставляемой SQL, вы можете удобно писать соединения между таблицами, которые будут предоставлять данные из разных таблиц, объединенных в один запрос.

NoSQL

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

В NoSQL DB нет предопределенной схемы или таблиц.

Есть Коллекции, и в каждой Коллекции есть Документы.

Это позволяет сохранять данные в разных формах по мере их поступления.

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

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

Однако они не подходят для такой цели.

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

Если вы человек, привыкший к SQL, вы можете рассматривать Коллекции как таблицы, а Документы — как строки с таблицами.

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

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

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

{id: 1, name: 'idris', email: 'idris@idrislawal.com'}
И Коллекция заказов может быть определена как,
{id: 1, order_number: 2000001, user_id:1}
Однако в этом случае мы хотим избежать необходимости вручную объединять обе коллекции (что в данном случае не следует).
Мы можем сохранить записи в Коллекцию, которая будет наиболее читаемой.
Я решил (для этого примера), что это будет коллекция заказов.
{id:1, order_number:200001, user{id:1, name: 'idris', email:'idris@idrislawal.com'}}
В этом случае нам больше не нужно читать из Коллекции пользователей, а только читать из Коллекции заказов, которая теперь содержит все необходимые нам данные.
Ключевой момент, на который следует обратить внимание: если вы создаете приложение, которое выполняет много операций чтения, а не записи, вам больше подойдет вариант NoSQL. Потому что вы можете хранить все свои данные в одной коллекции, и вы можете легко читать из этого источника, чтобы получить все необходимые данные.
Однако для приложения, которое требует большого количества операций записи (около 10000 операций записи в секунду) в таком масштабе, не рекомендуется использовать NoSQL, в котором необходимо записывать одни и те же данные в несколько мест.
В этой ситуации вариант SQL, вероятно, более подходит, когда у вас есть отношения, существующие ко всем таблицам, и одни и те же данные не нужно многократно записывать в несколько мест, обновление данных в одном месте может быть доступно для других таблиц через выход отношения.
Это, конечно, не означает, что каждая из этих баз данных не справляется с масштабированием.

Масштабирование баз данных

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

SQL

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

Горизонтальное масштабирование означает разделение данных из одной БД на несколько баз данных для облегчения загрузки.

Однако данные SQL нельзя разделить на отдельные БД из-за их строгой природы.

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

NoSQL

NoSQL БД можно масштабировать как по горизонтали, так и по вертикали.

Это связано с гибкостью в хранении данных.

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

При необходимости его можно масштабировать по вертикали.


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


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

Однако для крупных бизнес-приложений, реализующих 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 может быть лучшим решением.

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

 

Поделитесь статьей:

Добавить комментарий