SQL срещу NoSQL – Кой трябва да използвате за следващия си проект?

Един от най-често задаваните въпроси – каква база данни да използвам …


SQL означава Структуриран език на заявките. За първи път е разработена през 70-те години от екип от изследователи на IBM, базите данни NoSQL, от друга страна, за първи път са използвани през 1998 г. от Карло Строци.

Най-честата разлика между тези две системи от бази данни (DB) е, че SQL е релационен и NoSQL е нерелационен.

Нека се потопим дълбоко в тези две бази данни, за да информираме по-добре решението си, когато следващия път обмисляте база данни за вашия проект.

Структура на базата данни

Нека да поговорим за структурирането.

SQL

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

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

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

Например, нека разгледаме хипотетичната ситуация; имаме компания с потребители и потребителите могат да правят поръчки за продукти. Тогава бихме могли да решим, че потребителите могат да създават множество поръчки, но всяка поръчка може да бъде създадена само от един потребител. Това би било едно към много взаимоотношения, т.е. един потребител към много поръчки. Следователно структурата на таблиците за двете таблици ще изглежда подобно на по-долу.

В нашата БД бихме могли да имаме таблица с потребители, структурирана както по-долу,

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

Също така бихме могли да имаме таблица с поръчки

orders_table
———————————————————————————
id | user_id | Номер на поръчка
———————————————————————————
1 1 20000001

User_id в таблицата с поръчки улеснява картографирането на всяка поръчка в таблицата с поръчки към потребителя, към когото принадлежи. В случай на връзка „Един към един“, бихме могли да имаме order_id и на потребителската таблица, ако решим да получим потребителя чрез неговия свързан идентификационен номер на поръчка.

Защото в много от много ситуации обикновено се включва допълнителна таблица, наречена Pivot таблица. Това позволява да се картографират множество записи един към друг. Използвайки горната инстанция. Бихме имали,

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

и таблицата за поръчки ще бъде

orders_table
———————————————————
id | Номер на поръчка
———————————————————
1 2000001

и след това Pivot таблицата ще държи и двете идентификационни номера като чужди ключове.

users_orders_table
——————————————————————————
id | order_id | user_id
——————————————————————————
1 1 1

Въз основа на тази структура, предоставена от SQL, можете удобно да пишете Съединения между таблици, които ще предоставят данни от различни таблици, обединени заедно в едно запитване.

NoSQL

NoSQL базите данни са изградени, за да бъдат по-гъвкави от SQL БД, също така да съдържат по-големи количества данни.

В NoSQL DB няма предварително дефинирана схема или таблици. Има колекции и във всяка колекция има документи. Това ви позволява да запазвате данни под различни форми, тъй като те идват. Можете да изберете да имате много различни документи с различни полета в една колекция. Възможно е също така ръчно да се изградят отношения между колекциите. Те обаче не са подходящи за такава цел. Вместо това можете да запишете всичко, което е необходимо за една заявка, в същата колекция.

Ако сте човек на SQL, може да мислите за Колекции като таблици и Документи като редове с таблиците. Въпреки това няма ограничения за колоните с данни, които можете да добавите с таблицата.

Да се ​​върнем към по-ранния ни дефиниран хипотетичен случай на компания с потребители и поръчки.

Потребителска колекция може да бъде определена като,

{id: 1, име: ‘idris’, имейл: ‘[Имейл защитен]‘}

И колекцията от поръчки може да бъде определена като,

{id: 1, order_number: 2000001, user_id: 1}

В този случай обаче искаме да избегнем ръчното присъединяване към двете колекции (което в този случай не бива да бъде). Можем да запишем записи в колекцията, която получава най-четеното. Реших (за този пример), че ще бъде колекцията Orders.

{id: 1, order_number: 200001, user {id: 1, name: ‘idris’, имейл: ‘[Имейл защитен]“}}

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

Ключово нещо, което трябва да се отбележи тук: Ако изграждате приложение, което прави много четене от писане, опция NoSQL вероятно е по-подходяща за вас. Защото бихте могли всички ваши данни да бъдат запазени в една и съща колекция и можете да четете от този източник удобно, за да получите всички необходими данни.

За приложение, което изисква много записи (приблизително 10 000 пише в секунда) в този мащаб, не е добра идея да имате опция NoSQL, където трябва да запишете едни и същи данни на множество места. В тази ситуация вероятно е по-подходяща SQL опцията, при която имате отношения, съществуващи към всички таблици, и едни и същи данни не е необходимо да се записват многократно на няколко места, актуализирането на данни на едно място може да бъде достъпно за други таблици чрез излизащите взаимоотношения. Това, разбира се, не означава, че всяка от тези бази данни не може да се справи с мащаба.

мащабиране

Нека да проучим как работи мащабирането.

SQL

SQL БД не могат да бъдат мащабирани хоризонтално, а само вертикално. Какво означава това дори?

Хоризонталното мащабиране означава разделяне на данни от една БД на множество бази данни, за да се улесни натоварването. SQL данните обаче не могат да бъдат разделени на отделни БД поради строгия си характер. Правилното мащабиране на SQL DB е увеличаване на процесора, паметта и дисковото пространство на съществуващия DB сървър и това означава, че го мащабира вертикално.

хоризонтално мащабиране

вертикално мащабиране


NoSQL

NoSQL БД могат да бъдат мащабирани както хоризонтално, така и вертикално. Това се дължи на гъвкавостта в неговото съхранение на данни. Следователно това позволява разделянето на данните му на множество бази данни, какъвто е случаят с хоризонталното мащабиране. Той може също така да бъде мащабиран вертикално, ако е необходимо.

Ключово нещо, което трябва да се отбележи тук: Що се отнася до мащабирането, както SQL, така и NoSQL Базите данни могат да бъдат мащабирани ефективно. Въпреки това, за SQL DB, вертикалното мащабиране може да бъде ограничение; един DB сървър ще има ограничение на количеството изчислителна мощност, което може да носи.

Тук също е важно да се отбележи, че за повечето приложения, които ще изградите, може да не постигнете максимума на компютърните си възможности на сървъра, но е полезно да имате това предвид. Въпреки това, за големи бизнес приложения, прилагащи SQL, популярна опция за преодоляване на това ограничение е от Sharding.

Какво е 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 може да е по-доброто решение. По отношение на мащабируемостта, когато приложението ви достигне много масивен мащаб, може да се окажете, че използвате и двете БД.

ЕТИКЕТИ:

  • База данни

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