Асновы мадэлявання дадзеных - PostgreSQL vs. Cassandra vs. MongoDB

Распрацоўшчыкі прыкладанняў звычайна марнуюць значную колькасць часу на ацэнку некалькіх аперацыйных баз дадзеных, каб знайсці тую базу дадзеных, якая найлепшым чынам адпавядае іх патрэбнасцям у рабочай нагрузцы. Гэтыя патрэбы ўключаюць у сябе спрошчанае мадэляванне дадзеных, гарантыі транзакцый, прадукцыйнасць чытання / запісу, гарызантальнае маштабаванне і дапушчальныя памылкі. Традыцыйна гэты выбар пачынаецца з катэгорый баз дадзеных SQL супраць NoSQL, паколькі кожная катэгорыя ўяўляе сабой выразны набор кампрамісаў. Высокая прадукцыйнасць ва ўмовах нізкай затрымкі і высокай прапускной здольнасці звычайна разглядаецца як некамерцыйнае патрабаванне і таму чакаецца ў любой абранай базе дадзеных.

Гэты пост накіраваны на тое, каб дапамагчы распрацоўшчыкам прыкладанняў зразумець выбар SQL супраць NoSQL у кантэксце прыкладання, якое мадэлюе дадзеныя. Мы выкарыстоўваем базу дадзеных SQL, а менавіта PostgreSQL і 2 базы дадзеных NoSQL, а менавіта Cassandra і MongoDB, у якасці прыкладаў для тлумачэння асноў мадэлявання дадзеных, такіх як стварэнне табліц, устаўка дадзеных, правядзенне сканавання і выдаленне дадзеных. У далейшым паведамленні мы раскажам пра дадатковыя тэмы, такія як індэксы, транзакцыі, аб'яднання, дырэктывы "TTL" і мадэляванне дакументальных дадзеных на аснове JSON.

Чым NoSQL адрозніваецца ад SQL пры мадэляванні дадзеных?

Базы дадзеных SQL павялічваюць спрытнасць прыкладанняў за кошт транзакцыйных гарантый ACID, а таксама з магчымасцю запытаць дадзеныя з выкарыстаннем JOIN непрадбачанымі спосабамі на базе існуючых нармалізаваных мадэляў рэляцыйных дадзеных.

Улічваючы іх маналітную / аднавузловую архітэктуру і выкарыстанне мадэлі рэпрадукцыі майстра-ведома, для традыцыйных баз дадзеных SQL адсутнічаюць дзве важныя магчымасці - лінейная маштабаванасць запісу (г.зн. аўтаматычная рэзкасць праз некалькі вузлоў) і аднаўленне страты аўтаматычнай / нулявой інфармацыі. Гэта азначае, што аб'ём дадзеных, прынятых не можа перавышаць максімальную прапускную здольнасць аднаго вузла. Акрамя таго, варта чакаць некаторай часовай страты дадзеных пры аднаўленні (у архітэктуры захоўвання дадзеных агульнага карыстання), улічваючы, што нядаўнія дакументы яшчэ не з'явіліся ў рэпліцы. У свеце баз дадзеных SQL таксама немагчыма дасягнуць нулявога перыяду прастою.

Базы дадзеных NoSQL звычайна распаўсюджваюцца ў прыродзе, дзе дадзеныя размяркоўваюцца альбо падзяляюцца на некалькі вузлоў. Яны наказваюць дэнармалізацыю, а значыць, устаўляемыя дадзеныя таксама павінны быць скапіяваны некалькі разоў, каб яны служылі канкрэтным запытам. Галоўнай мэтай з'яўляецца атрыманне высокай прадукцыйнасці шляхам выразнага памяншэння колькасці чарапкоў, якія звяртаюцца за час чытання. Такім чынам, сцвярджэнне, што NoSQL патрабуе ад вас мадэлявання запытаў, у той час як SQL патрабуе ад вас мадэлявання дадзеных.

Фокус NoSQL на дасягненні высокай прадукцыйнасці ў размеркаваным кластары паказаны ў якасці асноўнага абгрунтавання для шматлікіх кампрамісаў мадэлявання дадзеных, якія ўключаюць страту транзакцый ACID, JOIN і паслядоўных глабальных другасных індэксаў.

Агульнае меркаванне складаецца ў тым, што, нягледзячы на ​​тое, што базы дадзеных NoSQL забяспечваюць лінейную маштабаванасць запісу і высокую талерантнасць да памылак, страта транзакцыйных гарантый робіць іх непрыдатнымі для крытычна важных дадзеных.

У наступнай табліцы падрабязна распазнаецца мадэляванне дадзеных NoSQL ад SQL.

SQL супраць NoSQL - адрозненні ў мадэляванні ключавых дадзеных

SQL і NoSQL: навошта вам абодва?

Большасць прыкладанняў у рэальным свеце з прывабным карыстацкім досведам, такія як Amazon.com, Netflix, Uber і Airbnb, працуюць унутрана, пры дапамозе складанай сумесі з некалькіх нагрузак. Напр. прыкладанне для электроннай камерцыі, падобнае Amazon.com, павінна захоўваць дадзеныя з нізкім аб'ёмам і вельмі важныя для місіі, такія як карыстальнікі, прадукты, заказы, рахункі-фактуры, а таксама дадзеныя аб высокім аб'ёме і менш важныя для місіі, такія як агляды прадукцыі, паведамленні службы даведачнай службы, актыўнасць карыстальніка, рэкамендацыі карыстальніка. Натуральна, што гэтыя прыкладання абапіраюцца на хаця б адну базу дадзеных SQL разам з хаця б адной базай дадзеных NoSQL. У шматрэгіянальных і глабальных разгортках база дадзеных NoSQL таксама дзейнічае як геа размеркаваны кэш для дадзеных, якія захоўваюцца ў крыніцы праўды, базы дадзеных SQL, якія працуюць у адным рэгіёне.

Як YugaByte DB аб'ядноўвае SQL і NoSQL на агульную базу дадзеных?

Пабудаваны на унікальнай камбінацыі рухавікоў захоўвання аб'яднаных сістэм зліцця, аўтаматычнага накручвання, размеркаванай рэплікацыі кансенсусу і размеркаваных транзакцый ACID (натхнёнай Google Spanner), YugaByte DB з'яўляецца першай у свеце базай дадзеных з адкрытым зыходным кодам, якая з'яўляецца адначасова NoSQL (Cassandra & Redis сумяшчальны) і SQL (PostgreSQL сумяшчальны) адначасова. Як паказана ў табліцы ніжэй, YCQL, сумяшчальны API Касандры YbaByte DB, дадае ў API API NoSQL паняцце транзакцый з адным ключом і мноствам ключавых ACID і глабальных другасных індэксаў, такім чынам, у эру Transactional NoSQL. Акрамя таго, YSQL, сумяшчальны з API PostgreSQL DB YugaByte DB, дадае паняцці пра лінейнае маштабаванне запісу і аўтаматычную талерантнасць да адказаў у API SQL, ствараючы такім чынам свет размеркаванай SQL. Паколькі база дадзеных YugaByte з'яўляецца асноўнай трансакцыяй, нават API NoSQL зараз могуць выкарыстоўвацца ў кантэксце важных для місіі дадзеных.

YugaByte DB - SQL & NoSQL у Адзінай базавай базе дадзеных

Як ужо было апісана ў Прадстаўленні YSQL: Сумяшчальны з PostgreSQL размеркаваных API SQL для YugaByte DB, выбар SQL у параўнанні з NoSQL у базе DB YugaByte залежыць выключна ад характарыстык нагрузкі большасці.

  • Калі асноўная нагрузка складаецца з ключавых аперацый з JOINS, выберыце YSQL з разуменнем таго, што вашы ключы могуць быць размеркаваны па некалькіх вузлах, што прывядзе да большай затрымкі і / або ніжэйшай прапускной здольнасці, чым NoSQL.
  • У адваротным выпадку выберыце любы з двух API NoSQL з разуменнем таго, што вы атрымаеце больш высокія выгады ад прадукцыйнасці ў выніку запытаў, якія ў асноўным абслугоўваюцца з аднаго вузла за адзін раз. YugaByte DB можа служыць адзінай аперацыйнай базай дадзеных для складаных прыкладанняў рэальнага свету, якія звычайна маюць некалькі рабочых нагрузак адначасова.

Лабараторыя мадэлявання дадзеных у наступным раздзеле заснавана на сумяшчальных API API PostgreSQL і Касандры YugaByte ў адрозненне ад арыгінальных баз дадзеных. Такі падыход падкрэслівае прастату ўзаемадзеяння з двума рознымі API (на двух розных портах) аднаго і таго ж кластара баз дадзеных у адрозненне ад выкарыстання цалкам незалежных кластараў дзвюх розных баз дадзеных.

У наступных раздзелах мы прагледзім лабараторыю мадэлявання дадзеных, каб праілюстраваць мноства адрозненняў і некалькі агульных паміж рознымі базамі дадзеных.

Лабараторыя мадэлявання дадзеных

Усталюйце базы дадзеных

Улічваючы акцэнт на мадэляванні дадзеных (а не на складаных архітэктурах разгортвання), мы ўсталёўваем базы дадзеных у кантэйнеры Docker на нашых лакальных машынах, а потым узаемадзейнічаем з імі, выкарыстоўваючы адпаведныя абалонкі каманднага радка.

YugaByte DB, сумяшчальная база дадзеных PostgreSQL і Cassandra

mkdir ~ / yugabyte && cd ~ / yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
докер цягнуць yugabytedb / yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo: апошняя

Доступ з дапамогай абалонкі каманднага радка

Далей падключаемся да баз дадзеных, выкарыстоўваючы абалонкі каманднага радка для адпаведных API.

PostgreSQL

psql - абалонка каманднага радка для ўзаемадзеяння з PostgreSQL. Для зручнасці выкарыстання, YugaByte DB пастаўляецца з версіяй psql у сваім каталогу смецця.

docker exec -it yb-postgres-n1 / home / yugabyte / postgres / bin / psql -p 5433 -U postgres

Касандра

cqlsh - абалонка каманднага радка для ўзаемадзеяння з Cassandra і сумяшчальнымі базамі дадзеных праз CQL (мова запыту Cassandra). Для зручнасці выкарыстання, YugaByte DB пастаўляецца з версіяй cqlsh у сваім каталогу смецця.

Звярніце ўвагу, што CQL моцна натхняе SQL з падобным паняццем табліц, радкоў, слупкоў і індэксаў. Аднак, як мова NoSQL, яна дадае пэўны набор абмежаванняў, большасць з якіх мы разгледзім падчас нашага блога.

docker exec -it yb-tserver-n1 / home / yugabyte / bin / cqlsh

MongoDB

mongo - абалонка каманднага радка для ўзаемадзеяння з MongoDB. Яго можна знайсці ў каталогу смецця ўстаноўкі MongoDB.

docker exec - гэта мой манга
CD bin
манга

Стварыце табліцу

Цяпер мы можам узаемадзейнічаць з базай дадзеных для розных аперацый з дапамогай абалонкі каманднага радка. Пачнем са стварэння табліцы, якая захоўвае інфармацыю пра песні, апублікаваныя артыстамі. Гэтыя песні часам з'яўляюцца часткай альбома. Іншыя неабавязковыя атрыбуты песні - год выпуску, кошт, жанр і рэйтынг крытыкаў. Нам трэба ўлічыць дадатковыя атрыбуты, якія нам могуць спатрэбіцца ў будучыні праз поле "тэгі", якое можа захоўваць паўструктураваныя дадзеныя як пары ключавых значэнняў.

PostgreSQL

СТВАРЫЦЬ ТАБЛІЦУ Музыка (
    Мастак VARCHAR (20) NOT NULL,
    SongTitle VARCHAR (30) НЕ NULL,
    AlbumTitle VARCHAR (25),
    Год INT,
    Кошт FLOAT,
    Жанр VARCHAR (10),
    КРЫТЫЧНЫ FLOAT,
    Тэгі TEXT,
    ПЕРШЫ КЛЮЧ (выканаўца, SongTitle)
);

Касандра

Стварэнне табліцы ў Касандры вельмі падобна на табліцу PostgreSQL. Адно з вялікіх адрозненняў - недахоп цэласнасці (напрыклад, НЕ NULL), які нясе адказнасць за прыкладанне, а не базы дадзеных у свеце NoSQL. Першасны ключ складаецца з ключа раздзела (слупка выканаўцы ў прыкладзе ніжэй) і набору слупкоў кластэрызацыі (слупка SongTitle у прыкладзе ніжэй). Ключ раздзела вызначае, у якім раздзеле / ​​фрагменце размясціць радок, а калонкі кластара вызначаюць, як павінны быць арганізаваны дадзеныя ў дадзеным фрагменце.

СТВОРЧАЦЬ КЛЮЧАЙ myapp;
ВЫКАРЫСТАЦЬ myapp;
СТВАРЫЦЬ ТАБЛІЦУ Музыка (
    Тэкст выканаўцы,
    ТЭКСТ SongTitle,
    TEXT AlbumTitle,
    Год INT,
    Кошт FLOAT,
    Жанр TEXT,
    КРЫТЫЧНЫ FLOAT,
    Тэгі TEXT,
    ПЕРШЫ КЛЮЧ (выканаўца, SongTitle)
);

MongoDB

MongoDB арганізуе дадзеныя ў базы дадзеных (эквівалентныя кассандравай прасторы Касандры), якія маюць калекцыі (эквівалентныя табліцам), якія маюць дакументы (эквівалентныя радкам у табліцы). У базе дадзеных "без схемы", вызначэнне MongoDB датэрмінова не трэба. Прыведзеная ніжэй каманда "выкарыстоўваць базу дадзеных" стварае базу дадзеных у першы раз, калі яна выклікаецца разам са зменай кантэксту ў нядаўна створанай базе дадзеных. Нават калекцыі не трэба ствараць відавочна, а ствараць аўтаматычна, проста ўставіўшы першы дакумент у новую калекцыю. Звярніце ўвагу, што база дадзеных па змаўчанні MongoDB з'яўляецца тэставай, таму ў гэтым кантэксце па змаўчанні будзе зроблена аперацыя ўзроўню збору без вызначэння базы дадзеных.

выкарыстоўваць myNewDatabase;

Атрымаць інфармацыю пра табліцу

PostgreSQL

\ d Музыка
Табліца "public.music"
    Калонка | Тып | Збор | Змяненне | Па змаўчанні
-------------- + ----------------------- + ----------- + ---------- + --------
 мастак | характар ​​рознай (20) | | не нулявы |
 песні | характар ​​рознага характару (30) | | не нулявы |
 альбом | характар ​​рознага характару (25) | | |
 год | цэлы лік | | |
 цана | двайная дакладнасць | | |
 жанр | характар ​​рознага характару (10) | | |
 крытыкуючы | двайная дакладнасць | | |
 тэгі | тэкст | | |
Індэксы:
    "music_pkey" PRIMARY KEY, btree (выканаўца, песня)

Касандра

АПІСНЫЯ ТАБЛІЧНАЯ МУЗЫКА;
СТВАРЫЦЬ ТАБЛІЦУ myapp.music (
    тэкст мастака,
    тэкст песні,
    тэкст альбома
    год Int,
    кошт паплаўка,
    жанравы тэкст,
    Тэкст тэгаў,
    ПЕРШЫ КЛЮЧ (выканаўца, песня)
) З ЗАКАЗАМ КЛАСТЫРУВАННЯ (песенька ASC)
    І default_time_to_live = 0
    І транзакцыі = {'уключаны': 'false'};

MongoDB

выкарыстоўваць myNewDatabase;
паказаць калекцыі;

Устаўце дадзеныя ў табліцу

PostgreSQL

УСТАВЯЦЬ У музыку
    (Выканаўца, SongTitle, AlbumTitle,
    Год, Кошт, Жанр, Крытыкі,
    Тэгі)
ЦЕНЫ (
    "Нікога не ведаеш", "Патэлефануй мне сёння", "Некалькі вядомым",
    2015, 2.14, "Краіна", 7.8,
    '{"Кампазітары": ["Сміт", "Джонс", "Дэвіс"], "LengthInSeconds": 214}'
);
УСТАВЯЦЬ У музыку
    (Выканаўца, SongTitle, AlbumTitle,
    Кошт, жанр, рэйтынг крытыкаў)
ЦЕНЫ (
    "Нікога не ведаеш", "Мая сабака", "Эй зараз",
    1,98, «Краіна», 8.4
);
УСТАВЯЦЬ У музыку
    (Выканаўца, SongTitle, AlbumTitle,
    Кошт, жанр)
ЦЕНЫ (
    "The Acme Band", "Look out, world", "Buck пачынаецца тут",
    0,99, "Рок"
);
УСТАВЯЦЬ У музыку
    (Выканаўца, SongTitle, AlbumTitle,
    Кошт, жанр,
    Тэгі)
ЦЕНЫ (
    "The Acme Band", "Усё яшчэ закаханы", "Бак пачынае тут",
    2,47, «Рок»,
    '{"radioStationPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": {"Сіэтл": "20150625", "Кліўленд": "20150630"}, "паварот": Цяжкі} '
);

Касандра

Заява Cassandra INSERT выглядае вельмі падобна на PostgreSQL у цэлым. Аднак у семантыцы ёсць адна вялікая розніца. INSERT - гэта рэчаіснасць у Касандры, дзе радок абнаўляецца з апошнімі значэннямі, калі радок ужо існуе.

Гэтак жа, як у выказваннях PostgreSQL INSERT вышэй.

MongoDB

Нават нягледзячы на ​​тое, што MongoDB таксама мае базу дадзеных NoSQL, падобную на Касандру, яе аперацыя па ўстаўцы не мае таго ж сэнсавага паводзінаў, як Касандра. MongoDB insert () не мае магчымасці дапаўнення, што робіць яго падобным на PostgreSQL. Паводзіны ўстаўкі па змаўчанні без _idspecified прывядзе да дадання новага дакумента ў калекцыю.

db.music.insert ({
мастак: "Нікога не ведаеш",
   songTitle: "Патэлефануй мне сёння",
    albumTitle: "Некалькі вядомых",
    год: 2015,
    цана: 2,14,
    жанр: "Краіна",
    тэгі: {
Кампазітары: ["Сміт", "Джонс", "Дэвіс"],
LengthInSeconds: 214
}
   }
);
db.music.insert ({
    мастак: "Нікога не ведаеш",
    songTitle: "Мая сабака",
    albumTitle: "Эй зараз",
    цана: 1,98,
    жанр: "Краіна",
    рэйтынг крытыкаў: 8.4
   }
);
db.music.insert ({
    выканаўца: "The Acme Band",
    songTitle: "Глядзі, свет",
    albumTitle: "Бак пачынае тут",
    цана: 0,99,
    жанр: "Рок"
   }
);
db.music.insert ({
    выканаўца: "The Acme Band",
    songTitle: "Усё яшчэ закаханы",
    albumTitle: "Бак пачынае тут",
    цана: 2,47,
    жанр: "Рок",
    тэгі: {
        Прайграванне радыё: ["KHCR", "KBQX", "WTNR", "WJJH"],
        tourDates: {
            Сіэтл: "20150625",
            Кліўленд: "20150630"
        },
        кручэнне: "Цяжкі"
}
    }
);

Запыт у табліцу

Магчыма, самае істотнае адрозненне паміж SQL і NoSQL у плане запытаў мадэлявання - у выкарыстанні прапаноў FROM і WHERE. SQL дазваляе фразе FROM ўключаць некалькі табліц, а пункт WHERE можа мець адвольную складанасць (уключаючы JOIN па табліцах). Аднак NoSQL імкнецца паставіць жорсткае абмежаванне на пункт FROM, каб указана толькі адна табліца і ўказаны WHERE, каб заўсёды быў указаны першасны ключ. Гэта звязана з высокай эфектыўнасцю кампаніі NoSQL, якую мы абмяркоўвалі раней, і накіравана на тое, каб знізіць любое ўзаемадзеянне за сталом і крыж-накрыж. Такое ўзаемадзеянне можа ўвесці высокую затрымку камунікацыі між узламі ў час адказу на запыт, а значыць, лепш наогул пазбягаць. Напр. Касандра патрабуе, каб запыты былі абмежаваныя аператарамі (толькі =, IN, <,>, =>, <= дазволены) на ключах раздзелаў, за выключэннем выпадкаў, калі запытваецца другасны індэкс (дзе дазволены толькі аператар).

PostgreSQL

Ніжэй прыведзены 3 тыпы запытаў, якія лёгка абслугоўваюцца ў базе дадзеных SQL.

  • Вярнуць усе песні выканаўцы
  • Вярніце ўсе песні выканаўцы, якія адпавядаюць першай частцы назвы
  • Вярніце ўсе песні выканаўцы з канкрэтным словам у загалоўку, але толькі ў тым выпадку, калі цана менш за 1,00
ВЫБАРЫ * З музыкі
WHERE Artist = 'Нікога не ведаеш';
ВЫБАРЫ * З музыкі
WHERE Artist = 'Нікога не ведаеш' І SongTitle ПАДАБАЕЦЦА 'Call%';
ВЫБАРЫ * З музыкі
WHERE Artist = 'Нікога не ведаеш' AND SongTitle LIKE '% Today%'
І цана> 1,00;

Касандра

З пералічаных вышэй запытаў PostgreSQL толькі першы будзе працаваць з нязмененай Касандрай, паколькі аператар LIKE не дазволены ў кластарных слупках, такіх як SongTitle. У гэтым выпадку дазволены толькі аператары = і IN.

ВЫБАРЫ * З музыкі
WHERE Artist = 'Нікога не ведаеш';
ВЫБАРЫ * З музыкі
WHERE Artist = 'Нікога не ведаеш' і SongTitle IN ('Патэлефануй мне сёння', 'Мая сабака')
І цана> 1,00;

MongoDB

Як паказана ў папярэдніх прыкладах, асноўным метадам запыту MongoDB з'яўляецца метад db.collection.find (). Гэты спосаб кваліфікаваны па назве калекцыі (музыка ў прыкладзе ніжэй), які будзе запытвацца вельмі выразна, таму запыт па калекцыях яўна забаронены.

db.music.find ({
  мастак: "Нікога не ведаеш"
 }
);
db.music.find ({
  мастак: "Нікога не ведаеш",
  songTitle: / Патэлефануйце /
 }
);

Чытайце ўсе радкі з табліцы

Чытанне ўсіх радкоў - гэта проста прыватны выпадак з агульнага запыту, які мы назіралі раней.

PostgreSQL

ВЫБАРЫ *
З музыкі;

Касандра

Гэтак жа, як у заяве PostgreSQL SELECT вышэй.

MongoDB

db.music.find ({});

Змена дадзеных у табліцы

PostgreSQL

PostgreSQL забяспечвае аперацыю UPDATE для змены дадзеных. Гэта не дапускае магчымасці ўключэння, таму заява будзе збой, калі радок ужо не існуе ў базе дадзеных.

Абнаўленне Музыка
Жанр SET = 'Дыскатэка'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Усё яшчэ закаханы';

Касандра

Касандра таксама мае UPDATE заяву, падобную на PostgreSQL. Абнавіць таксама тую ж семантыку, што і ў выказванні INSERT.

Гэтак жа, як і ў заяве PostgreSQL UPDATE вышэй.

MongoDB

Аперацыя MongoDB update () можа цалкам абнавіць існуючы дакумент альбо абнавіць толькі асобныя палі. Па змаўчанні ён абнаўляе толькі адзін дакумент з выключанай семантыкай. Абнаўленні некалькіх дакументаў і паводзіны версіі можна ўключыць, усталяваўшы дадатковыя сцягі падчас аперацыі. Напр. прыклад ніжэй: абнаўляе жанр пэўнага выканаўцы ў песнях выканаўцы.

db.music.update (
  {"artist": "The Acme Band"},
  {
    $ набор: {
      "жанр": "Дыскатэка"
    }
  },
  {"multi": true, "upsert": true}
);

Выдаліць дадзеныя з табліцы

PostgreSQL

УДАЛІЦЬ З МУЗЫКІ
WHERE Artist = 'The Acme Band' AND SongTitle = 'Паглядзі, свет';

Касандра

Тое ж, што і ў заяве PostgreSQL DELETE вышэй.

MongoDB

MongoDB мае два тыпы аперацый па апрацоўцы выдалення дакументаў - deleteOne () / deleteMany () і выдаленне (). Абодва выдаляць дакументы, але маюць розныя вынікі вяртання.

db.music.deleteMany ({
        выканаўца: "The Acme Band"
    }
);

Выдаліце ​​табліцу

PostgreSQL

DROP ТАБЛІКА Музыка;

Касандра

Тое ж, што і ў выказванні PostgreSQL DROP TABLE вышэй;

MongoDB

db.music.drop ();

Рэзюмэ

Дыскусія SQL супраць NoSQL працягваецца ўжо дзесяць гадоў. Ёсць два аспекты гэтай дыскусіі: архітэктура асноўнай базы дадзеных (маналітная, транзакцыйная SQL у параўнанні з размеркаваным, не транзакцыйным NoSQL) і падыход да мадэлявання дадзеных (мадэлюйце дадзеныя ў SQL і мадэлюйце свае запыты ў NoSQL).

Дзякуючы распаўсюджанай транзакцыйнай базе дадзеных, такой як DB YugaByte, асноўная архітэктура базы дадзеных у спрэчках можа лёгка адпачыць. Па меры таго, як аб'ёмы дадзеных растуць за рамкі таго, што можна запісаць у адзін вузел, цалкам неабходна размеркаваць архітэктуру, якая забяспечвае маштабаванасць лінейнага запісу з аўтаматычным рэзаннем / балансаваннем. Акрамя таго, як апісана ў гэтым паведамленні ад Google Cloud, транзакцыйныя, моцна паслядоўныя архітэктуры цяпер шырока прыняты для стварэння больш высокага ўзроўню распрацоўшчыка і аператыўнасці, чым не транзакцыйныя, у канчатковым выніку паслядоўныя архітэктуры.

Прыступаючы да дыскусіі па мадэляванні дадзеных, справядліва сказаць, што і SQL, і падыходы да мадэлявання дадзеных NoSQL маюць важнае значэнне для любога складанага прыкладання ў рэальным свеце. Мадэль падыходу SQL да вашай мадэлі дазваляе распрацоўшчыкам лягчэй змяняць змены патрабаванняў бізнесу, у той час як мадэль падыходу NoSQL-вашы запыты дазваляе тым самым распрацоўшчыкам кіраваць вялікімі аб'ёмамі дадзеных з нізкай затрымкай і высокай прапускной здольнасцю. Менавіта таму YugaByte DB рэалізуе як SQL, так і NoSQL API на агульным ядры, а не прасоўваць гэты падыход строга лепш, чым іншы. Акрамя таго, забяспечваючы сумяшчальнасць драты з папулярнымі мовамі баз дадзеных, уключаючы PostgreSQL і Cassandra, YugaByte DB гарантуе, што распрацоўшчыкі не вывучаюць іншую мову, каб атрымаць выгаду з распаўсюджанага строга паслядоўнага ядра базы дадзеных.

Гэты пост дапамог нам зразумець, чым асновы мадэлявання дадзеных адрозніваюцца паміж PostgreSQL, Cassandra і MongoDB. У наступных паведамленнях у серыі мы будзем паглыбляцца ў перадавыя канцэпцыі мадэлявання дадзеных, такія як індэксы, транзакцыі, JOIN, дырэктывы TTL і дакументы JSON.

Што далей?

  • Параўнайце базы дадзеных YugaByte з базамі дадзеных, як Amazon DynamoDB, Cassandra, MongoDB і Azure Cosmos DB.
  • Пачніце з YugaByte DB на macOS, Linux, Docker і Kubernetes.
  • Звяжыцеся з намі, каб даведацца больш пра ліцэнзаванне, кошт альбо запланаваць тэхнічны агляд.

Першапачаткова апублікаваны ў блогу базы даных YugaByte.