ProHoster > بلاګ > اداره > د ډیټابیس ډیزاین اساسات - د PostgreSQL، Cassandra او MongoDB پرتله کول

د ډیټابیس ډیزاین اساسات - د PostgreSQL، Cassandra او MongoDB پرتله کول

سلام ملګرو. مخکې له دې چې د می د رخصتیو دویمې برخې ته لاړ شي، موږ تاسو سره هغه مواد شریکوو چې موږ په کورس کې د نوي جریان د پیل په تمه ژباړلي. "اړیکو DBMS".

د ډیټابیس ډیزاین اساسات - د PostgreSQL، Cassandra او MongoDB پرتله کول

د غوښتنلیک پراختیا کونکي د ډیری عملیاتي ډیټابیسونو پرتله کولو لپاره ډیر وخت تیروي ترڅو هغه غوره کړي چې د ټاکل شوي کاري بار سره مناسب وي. اړتیاو کې ممکن د ساده معلوماتو ماډلینګ، د لیږد تضمین، د لوستلو / لیکلو فعالیت، افقی اندازه کول، او د غلطۍ زغم شامل وي. په دودیز ډول، انتخاب د ډیټابیس کټګورۍ، SQL یا NoSQL سره پیل کیږي، ځکه چې هره کټګورۍ د سوداګرۍ بندونو روښانه سیټ وړاندې کوي. د ټیټ ځنډ او لوړ تولید په شرایطو کې لوړ فعالیت عموما د غیر سوداګریزې اړتیا په توګه لیدل کیږي او له همدې امله د هر ډول نمونې ډیټابیس لپاره اړین دی.

د دې مقالې هدف د غوښتنلیک پراختیا کونکو سره مرسته کول دي چې د غوښتنلیک ډیټا ماډلینګ شرایطو کې د SQL او NoSQL ترمنځ سم انتخاب وکړي. موږ به یو SQL ډیټابیس وګورو، یعنې PostgreSQL، او دوه NoSQL ډیټابیسونه، Cassandra او MongoDB، ترڅو د ډیټابیس ډیزاین اساسات پوښښ کړي، لکه د میزونو جوړول، دوی ډکول، د میز څخه ډاټا لوستل، او حذف کول. په راتلونکې مقاله کې، موږ به ډاډ ترلاسه کړو چې شاخصونه، لیږدونه، JOINs، TTL لارښوونې، او د JSON پر بنسټ ډیټابیس ډیزاین وګورئ.

د SQL او NoSQL ترمنځ توپیر څه دی؟

د ایس کیو ایل ډیټابیسونه د ACID لیږد تضمین له لارې د غوښتنلیک انعطاف لوړوي ، په بیله بیا د موجوده نورمال شوي ارتباطي ډیټابیس ماډلونو په سر کې په غیر متوقع لارو کې د JOINs په کارولو سره د معلوماتو پوښتنې کولو وړتیا.

د دوی واحد / واحد نوډ جوړښت او د بې ځایه کیدو لپاره د ماسټر غلام نقل ماډل کارولو ته په پام سره ، دودیز SQL ډیټابیس دوه مهمې ځانګړتیاوې نلري - د خطي لیکلو توزیع وړتیا (د بیلګې په توګه په ډیری نوډونو کې اتوماتیک تقسیم کول) او اتوماتیک/صفر ډیټا ضایع کول. دا پدې مانا ده چې د ترلاسه شوي معلوماتو مقدار نشي کولی د یو واحد نوډ د لیکلو اعظمي حد څخه ډیر شي. برسېره پردې، د ځینې لنډمهاله معلوماتو ضایع باید د غلطۍ زغم په پام کې ونیول شي (په یوه شریک شوي جوړښت کې). دلته تاسو باید په یاد ولرئ چې وروستي ژمنې لاهم د غلام کاپي کې منعکس شوي ندي. په SQL ډیټابیسونو کې د غیر کم وخت تازه معلومات ترلاسه کول هم ستونزمن دي.

د NoSQL ډیټابیسونه معمولا د طبیعت لخوا ویشل کیږي، د بیلګې په توګه. په دوی کې، ډاټا په برخو ویشل شوي او په څو نوډونو ویشل شوي. دوی غیر نورمال کولو ته اړتیا لري. دا پدې مانا ده چې داخل شوي معلومات باید څو ځله کاپي شي ترڅو ځانګړي غوښتنو ته ځواب ووایی چې تاسو یې لیږئ. ټولیز هدف د لوستلو پرمهال د موجود شارډونو شمیر کمولو سره لوړ فعالیت ترلاسه کول دي. دا پدې معنی ده چې NoSQL تاسو ته اړتیا لري چې خپلې پوښتنې موډل کړئ، پداسې حال کې چې SQL تاسو ته اړتیا لري چې خپل ډاټا موډل کړئ.

NoSQL په توزیع شوي کلستر کې د لوړ فعالیت په ترلاسه کولو تمرکز کوي او دا د ډیری ډیټابیس ډیزاین سوداګرۍ لپاره اصلي دلیل دی چې پکې د ACID لیږد ضایع کول ، JOINs ، او دوامداره نړیوال ثانوي شاخصونه شامل دي.

یو دلیل شتون لري پداسې حال کې چې د NoSQL ډیټابیس د خطي لیکلو توزیع او د لوړې غلطۍ زغم چمتو کوي ، د لیږد تضمین له لاسه ورکول دوی د ماموریت مهم ډیټا لپاره مناسب نه کوي.

لاندې جدول ښیې چې څنګه په NoSQL کې د ډیټا ماډلینګ له SQL څخه توپیر لري.

د ډیټابیس ډیزاین اساسات - د PostgreSQL، Cassandra او MongoDB پرتله کول

SQL او NoSQL: ولې دواړه اړین دي؟

د ریښتیني نړۍ غوښتنلیکونه د لوی شمیر کاروونکو سره لکه Amazon.com، Netflix، Uber، او Airbnb، د پیچلو، څو اړخیزو کارونو ترسره کولو دنده لري. د مثال په توګه، د ای کامرس غوښتنلیک لکه Amazon.com اړتیا لري چې لږ وزن لرونکي، لوړ مهم معلومات لکه د کاروونکي معلومات، محصولات، فرمایشونه، رسیدونه، د درنو، لږ حساس معلوماتو لکه د محصول بیاکتنې، د ملاتړ پیغامونه، د کاروونکي فعالیت، د کارونکي بیاکتنې او سپارښتنې. په طبیعي ډول، دا غوښتنلیکونه لږترلږه د یو ایس کیو ایل ډیټابیس سره لږترلږه یو NoSQL ډیټابیس باندې تکیه کوي. په سیمه ایزو او نړیوالو سیسټمونو کې، د NoSQL ډیټابیس د جیو توزیع شوي کیچ په توګه کار کوي د ډیټا لپاره چې په یوه ځانګړي سیمه کې د باوري سرچینې SQL ډیټابیس کې زیرمه شوي.

یوګابایټ DB څنګه SQL او NoSQL سره یوځای کوي؟

د لوګ-اورینټ مخلوط ذخیره کولو انجن کې جوړ شوی، اتوماتیک شارډینګ، د توزیع شوي توزیع شوي توافق نقل او د ACID توزیع شوي لیږدونه (د ګوګل سپنر لخوا هڅول شوي)، یوګابایټ DB د نړۍ لومړی د خلاصې سرچینې ډیټابیس دی چې په ورته وخت کې د NoSQL (Cassandra & Redis) سره مطابقت لري. SQL (PostgreSQL). لکه څنګه چې په لاندې جدول کې ښودل شوي، YCQL، د یوګابایټ DB API د کیساندرا سره مطابقت لري، د واحد او څو کلیدي ACID معاملو مفکورې او نړیوال ثانوي شاخصونه NoSQL API ته اضافه کوي، په دې توګه د لیږد د NoSQL ډیټابیسونو دور پیل کوي. برسیره پردې، YCQL، د یوګابایټ DB API د PostgreSQL سره مطابقت لري، د SQL API ته د خطي لیکلو اندازه کولو او اتوماتیک غلطی زغم مفکورې اضافه کوي، نړۍ ته توزیع شوي SQL ډیټابیسونه راوړي. ځکه چې یوګا بایټ DB په طبیعت کې لیږدونکی دی ، نو د NoSQL API اوس د ماموریت مهم ډیټا په شرایطو کې کارول کیدی شي.

د ډیټابیس ډیزاین اساسات - د PostgreSQL، Cassandra او MongoDB پرتله کول

لکه څنګه چې مخکې په مقاله کې ویل شوي "د YSQL معرفي کول: د یوګابایټ DB لپاره د PostgreSQL مطابقت لرونکی توزیع شوی SQL API"، په YugaByte DB کې د SQL یا NoSQL ترمنځ انتخاب په بشپړ ډول د اصلي کاري بار ځانګړتیاو پورې اړه لري:

  • که ستاسو لومړني کاري بار څو کلیدي یوځای کولو عملیات وي، نو کله چې د YSQL غوره کول، پوه شئ چې ستاسو کیلي ممکن په ډیری نوډونو کې ویشل شوي وي، په پایله کې د NoSQL په پرتله د لوړ ځنډ او/یا ټیټ ټرپوټ پایله ده.
  • که نه نو، د دوو NoSQL APIs څخه یو غوره کړئ، په پام کې نیولو سره چې تاسو به په یو وخت کې د یو نوډ څخه د پوښتنو په پایله کې ښه فعالیت ترلاسه کړئ. یوګابایټ DB کولی شي د ریښتیني نړۍ ، پیچلي غوښتنلیکونو لپاره د واحد عملیاتي ډیټابیس په توګه خدمت وکړي چې په ورته وخت کې د ډیری کاري بارونو اداره کولو ته اړتیا لري.

په راتلونکې برخه کې د ډیټا ماډلینګ لابراتوار د PostgreSQL او Cassandra API مطابقت لرونکي YugaByte DB ډیټابیسونو پراساس دی ، د اصلي ډیټابیسونو سره مخالف. دا تګلاره د ورته ډیټابیس کلستر د دوه مختلف APIs (په دوه مختلف بندرونو کې) سره د متقابل عمل په اسانۍ ټینګار کوي ، د دوه مختلف ډیټابیسونو بشپړ خپلواک کلسترونو کارولو سره مخالف.
په لاندې برخو کې، موږ به د ډیټا ماډلینګ لابراتوار ته یو نظر وګورو ترڅو توپیرونه او د پوښښ شوي ډیټابیس ځینې مشترکات روښانه کړي.

د ډیټا ماډلینګ لابراتوار

د ډیټابیس نصب کول

د ډیټا ماډل ډیزاین باندې ټینګار ته په پام سره (د پیچلي ګمارنې جوړښتونو پرځای) ، موږ به په محلي ماشین کې د ډاکر کانټینرونو کې ډیټابیسونه نصب کړو او بیا به د دوی اړوند کمانډ لاین شیلونو په کارولو سره له دوی سره اړیکه ونیسو.

PostgreSQL او Cassandra متوافق یوګابایټ DB ډیټابیس

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

د کمانډ لاین لاسرسی

راځئ چې د اړونده APIs لپاره د کمانډ لاین شیل په کارولو سره ډیټابیسونو سره وصل شو.

پوسټری ایس ایس ایل

psql د PostgreSQL سره د تعامل لپاره د کمانډ لاین شیل دی. د کارولو اسانتیا لپاره، یوګابایټ DB د بن فولډر کې د psql سره راځي.

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

Cassandra

cqlsh د CQL (Cassandra Query Language) له لارې د کاسندرا او د دې مناسب ډیټابیسونو سره متقابل عمل کولو لپاره د کمانډ لاین شیل دی. د کارولو اسانتیا لپاره، یوګابایټ DB سره راځي cqlsh په کتالګو کې bin.
په یاد ولرئ چې CQL د SQL څخه الهام اخیستی او د میزونو، قطارونو، کالمونو او شاخصونو ورته مفکورې لري. په هرصورت، د NoSQL ژبې په توګه، دا یو مشخص محدودیتونه اضافه کوي، چې ډیری یې موږ به په نورو مقالو کې هم پوښښ کړو.

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

MongoDB

mongo د MongoDB سره د تعامل لپاره د کمانډ لاین شیل دی. دا د MongoDB نصب کولو بن ډایرکټر کې موندل کیدی شي.

docker exec -it my-mongo bash 
cd bin
mongo

د میز جوړول

اوس موږ کولی شو د ډیټابیس سره اړیکه ونیسو ترڅو د کمانډ لاین په کارولو سره مختلف عملیات ترسره کړو. راځئ چې د یو میز په جوړولو سره پیل وکړو چې د مختلفو هنرمندانو لخوا لیکل شوي سندرې په اړه معلومات ذخیره کړي. دا سندرې کیدای شي د البم برخه وي. همدارنګه د سندرې لپاره اختیاري ځانګړتیاوې د خوشې کیدو کال، قیمت، ژانر او درجه بندي دي. موږ اړتیا لرو د اضافي ځانګړتیاو حساب وکړو چې ممکن په راتلونکي کې د "ټاګ" ساحې له لارې ورته اړتیا وي. دا کولی شي د کلیدي ارزښت جوړو په بڼه نیمه جوړښت شوي ډاټا ذخیره کړي.

پوسټری ایس ایس ایل

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

Cassandra

په Cassandra کې د میز جوړول د PostgreSQL سره ورته دي. یو له اصلي توپیرونو څخه د بشپړتیا محدودیتونو نشتوالی دی (د مثال په توګه NULL)، مګر دا د غوښتنلیک مسؤلیت دی، نه د NoSQL ډیټابیس. لومړنۍ کیلي د برخې کولو کیلي لري (په لاندې مثال کې د هنرمند کالم) او د کلستر کولو کالمونو سیټ (په لاندې مثال کې د سندرې سرلیک کالم). د برخې کولو کیلي ټاکي چې کوم ویش/شارډ قطار باید ځای په ځای شي، او د کلستر کولو کالمونه په ګوته کوي چې ډاټا باید په اوسني شارډ کې څنګه تنظیم شي.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

MongoDB ډاټا په ډیټابیسونو (ډیټابیس) کې تنظیموي (په کیسانډرا کې د کیسپیس سره ورته)، چیرې چې ټولګه شتون لري (د میزونو سره ورته) چې اسناد لري (په میز کې د قطارونو سره ورته). په MongoDB کې، په اصل کې د ابتدايي سکیما تعریف کولو ته اړتیا نشته. ټیم "د ډیټابیس کارول"، لاندې ښودل شوی، په لومړي کال کې ډیټابیس انسټیټیوټ کوي او د نوي رامینځته شوي ډیټابیس لپاره شرایط بدلوي. حتی ټولګه په ښکاره ډول رامینځته کیدو ته اړتیا نلري؛ دوی په اوتومات ډول رامینځته کیږي ، په ساده ډول کله چې تاسو په نوي ټولګه کې لومړی سند اضافه کړئ. په یاد ولرئ چې MongoDB د ډیفالټ په واسطه د ازموینې ډیټابیس کاروي ، نو د ځانګړي ډیټابیس مشخص کولو پرته د راټولولو هر ډول عملیات به په ډیفالټ ډول پرمخ ځي. 

use myNewDatabase;

د میز په اړه معلومات ترلاسه کول
پوسټری ایس ایس ایل

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Cassandra 

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

میز ته د معلوماتو داخلول
پوسټری ایس ایس ایل

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Cassandra

په ټولیزه توګه بیان INSERT په Cassandra کې په PostgreSQL کې ورته ورته ښکاري. په هرصورت، په سیمانټیک کې یو لوی توپیر شتون لري. په Cassandra کې INSERT په حقیقت کې یو عملیات دی UPSERT، چیرې چې وروستي ارزښتونه په قطار کې اضافه کیږي که چیرې قطار دمخه شتون ولري.

د معلوماتو داخلول د PostgreSQL سره ورته دي INSERT د لوړو

.

MongoDB

که څه هم MongoDB د کاسیندرا په څیر د NoSQL ډیټابیس دی ، د دې داخلولو عملیات د کیسینډرا سیمانټیک چلند سره هیڅ شی نلري. په MongoDB کې دننه کړئ () هیڅ فرصت نلري UPSERT، کوم چې دا د PostgreSQL سره ورته کوي. پرته د ډیفالټ ډیټا اضافه کول _idspecified په ټولګه کې د نوي سند اضافه کولو لامل کیږي.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

د جدول پوښتنه

شاید د پوښتنې جوړونې په شرایطو کې د SQL او NoSQL تر مینځ خورا مهم توپیر کارول شوې ژبه ده FROM и WHERE. SQL د بیان وروسته اجازه ورکوي FROM ډیری جدولونه غوره کړئ، او بیان سره WHERE کیدای شي هر ډول پیچلتیا وي (د عملیاتو په شمول JOIN د میزونو ترمنځ). په هرصورت، NoSQL په دې باندې سخت محدودیت وضع کوي FROM، او یوازې د یو ټاکل شوي میز سره کار وکړئ ، او دننه WHERE, لومړنۍ کیلي باید تل مشخص شي. دا د NoSQL فعالیت فشار سره اړیکه لري چې موږ دمخه یې په اړه خبرې وکړې. دا هیله د هر ډول کراس میز او کراس کلیدي تعامل کې د هر ممکنه کمښت لامل کیږي. دا کولی شي د انټر نوډ اړیکو کې لوی ځنډ معرفي کړي کله چې غوښتنې ته ځواب ووایی او له همدې امله په عمومي توګه غوره مخنیوی کیږي. د مثال په توګه، Cassandra پوښتنو ته اړتیا لري چې په ځینو ځانګړو آپریټرونو پورې محدود وي (یوازې =, IN, <, >, =>, <=) د برخې کولو کیلي کې، پرته له دې چې د ثانوي شاخص غوښتنه وکړي (یوازې = آپریټر دلته اجازه لري).

پوسټری ایس ایس ایل

لاندې د پوښتنو درې مثالونه دي چې د SQL ډیټابیس لخوا په اسانۍ سره اجرا کیدی شي.

  • د یو هنرمند لخوا ټولې سندرې ښکاره کړئ؛
  • د هنرمند لخوا ټولې سندرې ښکاره کړئ چې د سرلیک لومړۍ برخې سره سمون لري؛
  • د یو هنرمند لخوا ټولې سندرې ښکاره کړئ چې په سرلیک کې یوه ځانګړې کلمه ولري او قیمت یې له 1.00 څخه کم وي. 
SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Cassandra

پورته لیست شوي د PostgreSQL پوښتنو څخه ، یوازې لومړی به په کاسندرا کې بدل نه وي کار کوي ، ځکه چې آپریټر LIKE په کلستر کولو کالمونو کې نشي پلي کیدی لکه SongTitle. په دې حالت کې، یوازې چلونکي اجازه لري = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

لکه څنګه چې په تیرو مثالونو کې ښودل شوي، په MongoDB کې د پوښتنو رامینځته کولو اصلي میتود دی db.collection.find(). دا طریقه په ښکاره ډول د ټولګې نوم لري (music په لاندې مثال کې)، نو د ډیری راټولولو پوښتنه کول منع دي.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

د میز ټول قطارونه لوستل

د ټولو قطارونو لوستل په ساده ډول د پوښتنې نمونې یوه ځانګړې قضیه ده چې موږ مخکې ولیدل.

پوسټری ایس ایس ایل

SELECT * 
FROM Music;

Cassandra

پورته د PostgreSQL مثال سره ورته.

MongoDB

db.music.find( {} );

په جدول کې د معلوماتو ایډیټ کول

پوسټری ایس ایس ایل

PostgreSQL لارښوونې وړاندې کوي UPDATE د معلوماتو بدلولو لپاره. هغه هیڅ فرصت نلري UPSERT، نو دا بیان به ناکام شي که چیرې قطار نور په ډیټابیس کې نه وي.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Cassandra لري UPDATE د PostgreSQL سره ورته. UPDATE ورته سیمانټیک لري UPSERT, ورته INSERT.

پورته د PostgreSQL مثال سره ورته.

MongoDB
عملیات تازه () په MongoDB کې کولی شي یو موجود سند په بشپړ ډول تازه کړي یا یوازې ځینې ساحې تازه کړي. په ډیفالټ ، دا یوازې یو سند تازه کوي د سیمانټیک غیر فعال شوي UPSERT. د ډیری اسنادو او ورته چلند تازه کول UPSERT د عملیاتو لپاره د اضافي بیرغونو په ترتیبولو سره پلي کیدی شي. د مثال په توګه، په لاندې مثال کې، د یو ځانګړي هنرمند ژانر د هغه د سندرې پراساس تازه کیږي.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

د میز څخه ډاټا لرې کول

پوسټری ایس ایس ایل

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

پورته د PostgreSQL مثال سره ورته.

MongoDB

MongoDB د اسنادو حذف کولو لپاره دوه ډوله عملیات لري - ړنګول() /deleteMany() и لرې کړئ (). دواړه ډولونه اسناد حذف کوي مګر مختلف پایلې بیرته راوړي. 

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

د میز ړنګول

پوسټری ایس ایس ایل

DROP TABLE Music;

Cassandra

پورته د PostgreSQL مثال سره ورته.

MongoDB

db.music.drop();

پایلې

د SQL او NoSQL ترمنځ د غوره کولو په اړه بحث د 10 کلونو څخه ډیر وخت نیسي. د دې بحث لپاره دوه اصلي اړخونه شتون لري: د ډیټابیس انجن جوړښت (مختلف، د لیږد SQL vs ویشل شوی، غیر لیږدونکي NoSQL) او د ډیټابیس ډیزاین طریقه (په SQL کې ستاسو د معلوماتو ماډل کول او په NoSQL کې ستاسو د پوښتنو ماډل کول).

د یوګابایټ DB په څیر د توزیع شوي لیږد ډیټابیس سره ، د ډیټابیس جوړښت په اړه بحث په اسانۍ سره آرام کیدی شي. لکه څنګه چې د ډیټا حجم د هغه څه څخه لوی کیږي چې یو واحد نوډ ته لیکل کیدی شي ، یو بشپړ توزیع شوی جوړښت چې د اتوماتیک شارډینګ / بیا توازن سره د خطي لیکلو توزیع ملاتړ کوي اړین کیږي.

سربیره پردې ، لکه څنګه چې په یوه مقاله کې ویل شوي ګوګل کلاډ,مقابله، په کلکه ثابته معمارۍ اوس ډیر دي، د غیر لیږدونکي، په نهایت کې ثابت معمارۍ په پرتله د غوره پرمختیا چټکتیا چمتو کولو لپاره کارول کیږي.

د ډیټابیس ډیزاین بحث ته بیرته راګرځیدل، دا سمه ده چې ووایو چې دواړه ډیزاین طریقې (SQL او NoSQL) د هر پیچلي ریښتینې نړۍ غوښتنلیک لپاره اړین دي. د SQL "ډیټا ماډلینګ" طریقه پراختیا کونکو ته اجازه ورکوي چې په اسانۍ سره د بدلولو سوداګرۍ اړتیاوې پوره کړي، پداسې حال کې چې د NoSQL "پوښتنې ماډلینګ" طریقه ورته پراختیا ورکونکو ته اجازه ورکوي چې د ټیټ ځنډ او لوړې کچې سره د ډیټا لوی مقدار کې کار وکړي. دا د همدې دلیل لپاره دی چې یوګا بایټ DB د یوې لارې ته وده ورکولو پرځای په عام کور کې SQL او NoSQL APIs چمتو کوي. برسیره پردې، د PostgreSQL او Cassandra په شمول د مشهور ډیټابیس ژبو سره مطابقت چمتو کولو سره، یوګابایټ DB ډاډ ورکوي چې پراختیا کونکي اړتیا نلري د ویشل شوي، خورا منظم ډیټابیس انجن سره کار کولو لپاره بله ژبه زده کړي.

پدې مقاله کې، موږ وګورو چې څنګه د ډیټابیس ډیزاین اساسات د PostgreSQL، Cassandra، او MongoDB ترمنځ توپیر لري. په راتلونکو مقالو کې، موږ به د ډیزاین پرمختللي مفکورې لکه شاخصونه، لیږدونه، JOINs، TTL لارښوونې، او JSON اسنادو کې ډوب کړو.

موږ تاسو ته د اونۍ پای کې ښه آرام غواړو او تاسو ته بلنه درکوو وړیا ویبینار، کوم چې به د می په 14 نیټه ترسره شي.

سرچینه: www.habr.com

Add a comment