مبانی مدل سازی داده - PostgreSQL در مقابل کاساندرا و MongoDB

توسعه دهندگان برنامه معمولاً زمان زیادی را صرف ارزیابی چندین بانک اطلاعاتی عملیاتی می کنند تا دریابند که یک پایگاه داده مناسب برای نیازهای کاری خود است. این نیازها شامل مدل سازی داده های ساده ، تضمین های معامله ، عملکرد خواندن / نوشتن ، مقیاس بندی افقی و تحمل خطا است. به طور سنتی ، این انتخاب با دسته بندی پایگاه داده SQL در برابر NoSQL شروع می شود زیرا هر دسته مجموعه مشخصی از معاملات را ارائه می دهند. عملکرد بالا از نظر تأخیر کم و توان زیاد معمولاً به عنوان یک نیاز غیر سازش پذیر تلقی می شود و از این رو در هر پایگاه داده انتخاب شده انتظار می رود.

این پست با هدف کمک به توسعه دهندگان برنامه کاربردی ، انتخاب SQL در مقابل NoSQL را در زمینه نیازهای مدل سازی داده های یک برنامه ، درک کرده است. ما از یک بانک اطلاعاتی SQL ، یعنی PostgreSQL و 2 پایگاه داده NoSQL یعنی Cassandra و MongoDB استفاده می کنیم ، به عنوان نمونه برای توضیح اصول اولیه مدل سازی داده مانند ایجاد جداول ، درج داده ها ، انجام اسکن ها و حذف داده ها. در پست بعدی ، مباحث پیشرفته ای از قبیل ایندکس ها ، معاملات ، پیوستگی ها ، بخشنامه های زمان زندگی (TTL) و مدل سازی داده های مبتنی بر JSON را پوشش خواهیم داد.

NoSQL چگونه از SQL در مدل سازی داده ها فرق می کند؟

بانکهای اطلاعاتی SQL ، چابکی کاربرد را از طریق ضمانتهای معامله ای ACID و همچنین توانایی آنها در جستجوی داده ها با استفاده از JOIN به روشهای پیش بینی نشده در بالای مدلهای داده موجود رابطه عادی ، افزایش می دهد.

با توجه به معماری یکپارچه / تک گره ای آنها و استفاده از یک مدل تکرار استاد برده برای افزونگی ، پایگاه داده های سنتی SQL دو قابلیت مهم را از دست نمی دهند - مقیاس پذیری نوشتن خطی (یعنی خرد کردن اتوماتیک در چندین گره) و شکست خودکار یا صفر از بین رفتن داده ها. این بدان معنی است که حجم داده های مصرف شده نمی توانند از حداکثر توان نوشتن یک گره واحد تجاوز کنند. بعلاوه ، با توجه به اینکه تعهدات اخیر هنوز در ماکت برده ها نشان داده نشده بودند ، باید از بین رفتن موقت داده ها در مورد شکست (در معماریهای ذخیره سازی اشتراکی مشترک) پیش بینی شود. ارتقاء صفر خرابی نیز در دنیای بانک اطلاعاتی SQL بسیار دشوار است.

DBS های NoSQL معمولاً در طبیعت توزیع می شوند که داده ها در گره های مختلف تقسیم می شوند یا به صورت خرد می شوند. آنها تغییر شکل دادن را اجباری می کنند ، به این معنی که داده های درج شده نیز باید چندین بار کپی برداری شوند تا به درخواست های خاصی که در ذهن دارید ارائه دهید. هدف اصلی استخراج کارایی بالا با کاهش صریح تعداد محافظ قابل دسترسی در زمان خواندن است. از این رو این بیانیه که NoSQL از شما الزام می کند برای نمایش داده های خود در حالی که SQL شما را ملزم به الگوبرداری از داده های خود می کند.

تمرکز NoSQL در دستیابی به عملکرد بالا در یک خوشه توزیع شده به عنوان اصلی ترین دلیل برای سازش مدل سازی داده های چندگانه که شامل از دست دادن معاملات ACID ، JOIN ها و شاخصهای ثانویه جهانی ثابتی است ، بیان شده است.

تصور کلی این است که حتی اگر پایگاه داده های NoSQL مقیاس پذیری نوشتن خطی و تحمل گسل زیاد را ارائه می دهند ، از دست دادن ضمانت های معامله ای باعث می شود که آنها برای داده های حساس ماموریت نا مناسب باشند.

جدول زیر نحوه تفاوت مدل سازی داده های NoSQL را با SQL نشان می دهد.

SQL در مقابل NoSQL - تفاوتهای مدل سازی داده های کلیدی

SQL و NoSQL: چرا به هر دو نیاز دارید؟

اکثر برنامه های موجود در دنیای واقعی با تجربیات جذاب کاربر مانند Amazon.com ، Netflix ، Uber و Airbnb با مخلوط پیچیده ای از بارهای کاری متعدد داخلی تولید می شوند. به عنوان مثال. یک برنامه تجارت الکترونیکی مانند Amazon.com باید داده های بسیار با اهمیت و بسیار پراهمیت مانند کاربران ، محصولات ، سفارشات ، فاکتورها را در کنار داده های با حجم بالا و دارای اهمیت بسیار کمتری مانند بررسی محصولات ، پیام های Helpdesk ، ذخیره کند. فعالیت کاربر ، توصیه های کاربر. به طور طبیعی ، این برنامه ها به حداقل یک پایگاه داده SQL در کنار حداقل یک پایگاه داده NoSQL تکیه دارند. در استقرارهای چند منطقه ای و جهانی ، پایگاه داده NoSQL همچنین به عنوان حافظه پنهان جغرافیایی برای داده های ذخیره شده در منبع حقیقت ، یعنی پایگاه داده SQL که در یک منطقه واحد کار می کند ، عمل می کند.

چگونه YugaByte DB SQL و NoSQL را در هسته اصلی پایگاه داده مشترک جمع می کند؟

ساخته شده با ترکیبی منحصر به فرد از موتور ذخیره سازی ادغام ساختار ، ورود به سیستم خودکار ، تکثیر اجسام توزیع شده در هر تکه و معاملات ACID توزیع شده (با الهام از Google Spanner) ، YugaByte DB اولین پایگاه داده منبع باز در جهان است که هم NoSQL (کاساندرا و Redis) است. سازگار) و SQL (PostgreSQL سازگار) به طور همزمان. همانطور که در جدول زیر نشان داده شده است ، YCQL ، API سازگار با Cassandra با YaaByte DB ، مفهوم معاملات ACID تک کلیدی و چند کلیدی و شاخص های ثانویه جهانی را به API های NoSQL اضافه می کند و بدین ترتیب در عصر NoSQL تراکنش ایجاد می شود. علاوه بر این ، YSQL ، API سازگار با PostgreSQL با YugaByte DB ، می افزاید: مفاهیم مقیاس خط نوشتن و تحمل خودکار خطا به یک API SQL ، بنابراین دنیای SQL توزیع شده را به وجود می آورد. از آنجا که YugaByte DB در هسته معامله است ، حتی API های NoSQL هم اکنون می توانند در زمینه داده های مهم برای ماموریت استفاده شوند.

YugaByte DB - SQL و NoSQL در هسته اصلی پایگاه داده

همانطور که قبلاً در معرفی YSQL شرح داده شده بود: یک API SQL توزیع شده سازگار با PostgreSQL برای YugaByte DB ، انتخاب SQL در مقابل NoSQL در YugaByte DB کاملاً به ویژگی های بار کار اکثریت بستگی دارد.

  • اگر حجم کار اکثریت عملیات چند کلید با JOINS است ، پس YSQL را با این درک انتخاب کنید که کلیدهای شما ممکن است در چندین گره توزیع شوند که منجر به تأخیر بیشتر و / یا توان کمتری نسبت به NoSQL می شود.
  • در غیر این صورت ، هر دو API NoSQL را با این درک انتخاب کنید که از مزایای عملکرد بالاتر ناشی از نمایش داده شد که در ابتدا از یک گره ارائه می شود ، سود بیشتری کسب خواهید کرد. YugaByte DB می تواند به عنوان یک پایگاه داده عملیاتی یکپارچه برای برنامه های پیچیده در دنیای واقعی که معمولاً دارای چندین بار کار برای مدیریت در همان زمان هستند ، خدمت کند.

آزمایشگاه مدل سازی داده ها در بخش بعدی مبتنی بر API های سازگار با YugaByte DB PostgreSQL و Cassandra است و برخلاف پایگاه داده های اصلی. این رویکرد ، سادگی تعامل با دو API مختلف (بر روی دو پورت مختلف) از یک خوشه پایگاه داده مشابه را بر خلاف استفاده از خوشه های کاملاً مستقل از دو پایگاه داده متفاوت برجسته می کند.

در بخش های بعدی با استفاده از مدل سازی داده ها به آزمایشگاه می پردازیم تا بسیاری از تفاوت ها و چند اشتراک بین بانکهای اطلاعاتی مختلف را نشان دهیم.

آزمایشگاه مدل سازی داده ها

پایگاه داده ها را نصب کنید

با توجه به تمرکز روی مدل سازی داده ها (و نه روی معماری های استقرار پیچیده) ، ما پایگاه های داده را در ظروف داکر روی دستگاه های محلی خود نصب می کنیم و سپس با استفاده از پوسته های مربوط به خط فرمان مربوطه ، با آنها تعامل خواهیم داشت.

YugaByte DB ، یک پایگاه داده سازگار با PostgreSQL و Cassandra

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

MongoDB

docker run - نام my-mongo -d mongo: آخرین

با استفاده از Command Line Shell دسترسی پیدا کنید

سپس با استفاده از پوسته های خط فرمان برای 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 -it me-mongo bash
سطل سی دی
مونگو

ایجاد یک جدول

اکنون می توانیم برای عملیات مختلف با استفاده از پوسته خط فرمان با بانک اطلاعاتی ارتباط برقرار کنیم. بیایید با ایجاد یک جدول که اطلاعات مربوط به آهنگهای منتشر شده توسط هنرمندان را ذخیره می کند ، شروع کنیم. این ترانه ها گاه بخشی از یک آلبوم هستند. سایر خصوصیات اختیاری یک آهنگ سال انتشار ، قیمت ، ژانر و رتبه منتقدان است. ما به ویژگیهای اضافی نیاز داریم که در آینده از طریق فیلد "برچسب ها" نیاز دارند که می تواند داده های نیمه ساختار یافته را به عنوان جفت ارزش کلیدی ذخیره کند.

PostgreSQL

ایجاد جدول موسیقی (
    هنرمند VARCHAR (20) NULL ،
    SongTitle VARCHAR (30) NULL نیست ،
    AlbumTitle VARCHAR (25) ،
    سال INT ،
    قیمت FLOAT ،
    ژانر VARCHAR (10) ،
    CriticRating FLOAT ،
    برچسب ها متن ،
    کلید اصلی (هنرمند ، SongTitle)
)؛

کاساندرا

ایجاد جدول در Cassandra بسیار شبیه به PostgreSQL است. یک تفاوت بزرگ عدم ​​محدودیت یکپارچگی (مانند NULL) است که مسئولیت برنامه و نه بانک اطلاعاتی در دنیای NoSQL است. کلید اصلی از کلید پارتیشن (ستون Artist در مثال زیر) و مجموعه ستون های خوشه بندی (ستون SongTitle در مثال زیر) تشکیل شده است. کلید پارتیشن مشخص می کند که کدام پارتیشن / قسمت برای قرار دادن ردیف در ستونها قرار دارد و ستونهای خوشه بندی چگونگی سازماندهی داده ها را در یک بخش مشخص مشخص می کنند.

ایجاد KEYSPACE myapp؛
استفاده از myapp؛
ایجاد جدول موسیقی (
    TEXT هنرمند ،
    TEXT SongTitle ،
    AlbumTitle TEXT ،
    سال INT ،
    قیمت FLOAT ،
    TEXT ژانر ،
    CriticRating FLOAT ،
    برچسب ها متن ،
    کلید اصلی (هنرمند ، SongTitle)
)؛

MongoDB

MongoDB داده هایی را در Databases (معادل Cassandra Keyspace) که دارای مجموعه هایی (معادل جداول) هستند که دارای اسناد هستند (معادل یک Row در یک جدول) سازماندهی می کند. به عنوان یک پایگاه داده "طرحریزی" ، تعریف طرحواره قبل از زمان در MongoDB ضروری نیست. دستور "استفاده از بانک اطلاعاتی" که در زیر نشان داده شده است ، اولین باری که در کنار تغییر متن به پایگاه داده جدید ایجاد شده ، یک پایگاه داده را فوراً می کند. حتی مجموعه ها نیازی به ایجاد صریح ندارند بلکه فقط با وارد کردن اولین سند در یک مجموعه جدید به طور خودکار ایجاد می شوند. توجه داشته باشید که پایگاه داده پیش فرض MongoDB امتحان شده است بنابراین هرگونه عملیات سطح جمع آوری بدون مشخص کردن بانک اطلاعاتی در این زمینه پیش فرض انجام می شود.

از myNewDatabase استفاده کنید؛

اطلاعات مربوط به یک جدول را بدست آورید

PostgreSQL

موسیقی
جدول "public.music"
    ستون | نوع | همبستگی | قابل اعتبار است پیش فرض
-------------- + ----------------------- + ----------- + ---------- + --------
 هنرمند | شخصیت متفاوت است (20) | | تهی نیست |
 ترانه | شخصیت متفاوت است (30) | | تهی نیست |
 آلبوم عنوان | شخصیت متفاوت است (25) | | |
 سال | عدد صحیح | | |
 قیمت | دقت دو برابر | | |
 ژانر | شخصیت متفاوت است (10) | | |
 انتقاد | دقت دو برابر | | |
 برچسب ها | متن | | |
فهرستها:
    "music_pkey" کلید اصلی ، btree (هنرمند ، ترانه)

کاساندرا

جدول موسیقی DESCRIBE؛
ایجاد جدول myapp.music (
    متن هنرمند ،
    متن آهنگ
    متن آلبوم
    سال بین المللی ،
    قیمت شناور ،
    متن ژانر ،
    متن برچسب ها ،
    کلید اصلی (هنرمند ، ترانه)
) با سفارش کلاستر توسط (متن ترانه ASC)
    AND default_time_to_live = 0
    و معاملات = {'enabled': 'false'}؛

MongoDB

از myNewDatabase استفاده کنید؛
نمایش مجموعه ها؛

قرار دادن داده ها در یک جدول

PostgreSQL

INSERT INTO موسیقی
    (هنرمند ، SongTitle ، AlbumTitle ،
    سال ، قیمت ، ژانر ، انتقاد ،
    برچسب ها)
ارزش های(
    "هیچ کس را نمی شناسید" ، "امروز با من تماس بگیرید" ، "چیزی مشهور" ،
    2015 ، 2.14 ، "کشور" ، 7.8 ،
    '{"آهنگسازان": ["اسمیت" ، "جونز" ، "دیویس"] ، "LongInSeconds": 214'
)؛
INSERT INTO موسیقی
    (هنرمند ، SongTitle ، AlbumTitle ،
    قیمت ، ژانر ، CriticRating)
ارزش های(
    "هیچ کس را نمی شناسید" ، "نقطه سگ من" ، "هی الان" ،
    1.98 ، 'کشور' ، 8.4
)؛
INSERT INTO موسیقی
    (هنرمند ، SongTitle ، AlbumTitle ،
    قیمت ، ژانر)
ارزش های(
    "The Acme Band" ، "Look Out، World" ، "Buck Here Here شروع می شود" ،
    0.99 ، "راک"
)؛
INSERT INTO موسیقی
    (هنرمند ، SongTitle ، AlbumTitle ،
    قیمت ، ژانر ،
    برچسب ها)
ارزش های(
    "گروه Acme" ، "هنوز در عشق" ، "Buck Here Here شروع می شود" ،
    2.47 ، "راک" ،
    '{"radioStationsPlaying": ["KHCR" ، "KBQX" ، "WTNR" ، "WJJH"] ، "tourDates": {"سیاتل": "20150625" ، "Cleveland": "20150630"} ، "rotation": سنگین}'
)؛

کاساندرا

جمله های Cassandra INSERT بسیار شبیه به PostgreSQL به طور کلی هستند. با این حال ، یک تفاوت بزرگ در معناشناسی وجود دارد. INSERT در واقع یک عملیات سربازآمیز در کاساندرا است که در صورت وجود ردیف ، ردیف با آخرین مقادیر به روز می شود.

مشابه گفته های PostgreSQL INSERT در بالا.

MongoDB

حتی اگر MongoDB همچنین یک پایگاه داده NoSQL مشابه Cassandra است ، عملکرد درج آن دارای عملکرد معنایی همانند Cassandra نیست. درج MongoDB () امکان تأیید ندارد که آن را شبیه به PostgreSQL کند. رفتار پیش فرض درج بدون هیچ _id Specified منجر به ایجاد سند جدیدی به مجموعه می شود.

db.music.insert ({
هنرمند: "کسی که شما می شناسید" ،
   songTitle: "امروز با من صدا کن" ،
    albumTitle: "تا حدودی مشهور" ،
    سال: 2015 ،
    قیمت: 2.14 ،
    ژانر: "کشور" ،
    برچسب ها: {
آهنگسازان: ["اسمیت" ، "جونز" ، "دیویس"] ،
LengthInSeconds: 214
}
   }
)؛
db.music.insert ({
    هنرمند: "کسی که شما می شناسید" ،
    songTitle: "نقطه سگ من" ،
    albumTitle: "سلام الان" ،
    قیمت: 1.98 ،
    ژانر: "کشور" ،
    kritRating: 8.4
   }
)؛
db.music.insert ({
    هنرمند: "گروه Acme" ،
    songTitle: "نگاه کن ، جهانی" ،
    albumTitle: "The Buck Here Here"
    قیمت: 0.99 ،
    ژانر: "راک"
   }
)؛
db.music.insert ({
    هنرمند: "گروه Acme" ،
    songTitle: "هنوز در عشق" ،
    albumTitle: "The Buck Here Here"
    قیمت: 2.47 ،
    ژانر: "راک" ،
    برچسب ها: {
        radioStationsPlaying: ["KHCR" ، "KBQX" ، "WTNR" ، "WJJH"] ،
        تورهای تاریخ: {
            سیاتل: "20150625" ،
            کلیولند: "20150630"
        ،
        چرخش: "سنگین"
}
    }
)؛

یک جدول پرس و جو کنید

احتمالاً مهمترین تفاوت بین SQL و NoSQL از نظر سؤالات مدل سازی در استفاده از بندهای FROM و WHERE است. SQL اجازه می دهد تا از FROM جداول مختلفی وجود داشته باشد و بند WHERE از پیچیدگی های دلخواه (از جمله عضویت در جداول) برخوردار است. با این حال ، NoSQL تمایل دارد محدودیت سختی را در بند FROM ایجاد کند تا فقط یک جدول مشخص شده باشد و بند WHERE همیشه کلید اصلی مشخص شده را داشته باشد. این امر به دلیل تمرکز بالای عملکرد NoSQL است که قبلاً در مورد آن صحبت کردیم و هدف آن کاهش هرگونه تعامل بین جدول و کلید متقابل است. چنین تعامل ممکن است ارتباط گره متقاطع با تأخیر بالا را به زمان پاسخ پرس و جو وارد کند و از این رو به طور کلی از آن جلوگیری می شود. به عنوان مثال. Cassandra مستلزم این است که نمایشگرها توسط اپراتورها (فقط = ، IN ، <،> ، => ، <= مجاز هستند) در کلیدهای پارتیشن محدود می شوند ، به جز هنگام پرسیدن یک فهرست ثانویه (فقط در صورتی که فقط = اپراتور مجاز است).

PostgreSQL

در زیر 3 نوع نمایش داده شد که به راحتی توسط یک پایگاه داده SQL ارائه می شود.

  • همه آهنگ های یک هنرمند را برگردانید
  • همه آهنگ های یک هنرمند را برگردانید ، مطابق با قسمت اول عنوان
  • تمام آهنگ های یک هنرمند را با یک کلمه خاص در عنوان برگردانید اما فقط در صورتی که قیمت کمتر از 1.00 باشد
SELECT * از موسیقی
WHERE Artist = 'هیچ کس نمی دانید'؛
SELECT * از موسیقی
WHERE Artist = 'هیچ کس را نمی شناسید' و SongTitle LIKE 'تماس٪'؛
SELECT * از موسیقی
WHERE Artist = "هیچ کس را نمی شناسید" و SongTitle LIKE "٪ امروز٪"
و قیمت> 1.00؛

کاساندرا

از سؤالات PostgreSQL که در بالا ذکر شد ، تنها اولین نفر با Cassandra اصلاح نشده کار خواهد کرد زیرا اپراتور LIKE در ستونهای خوشه بندی مانند SongTitle مجاز نیست. فقط = و عملگرهای IN در این مورد مجاز هستند.

SELECT * از موسیقی
WHERE Artist = 'هیچ کس نمی دانید'؛
SELECT * از موسیقی
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 = 'هنوز در عشق'؛

کاساندرا

Cassandra همچنین یک عبارت UPDATE مشابه PostgreSQL دارد. UPDATE نیز همان معنای بیانیه INSERT را تأیید می کند.

همان جمله اظهارات PostgreSQL UPDATE در بالا.

MongoDB

عملیات () به روزرسانی MongoDB می تواند یک سند موجود را به طور کامل بروزرسانی کند یا فقط می تواند زمینه های خاص را بروزرسانی کند. به طور پیش فرض ، فقط یک سند را با معناشناسی برجسته خاموش به روز می کند. با تنظیم پرچم های اضافی در عملیات ، به روزرسانی های چند سند و رفتار تأیید را می توان فعال کرد. به عنوان مثال. مثال زیر ژانر یک هنرمند خاص را در بین ترانه های این هنرمند به روز می کند.

db.music.update (
  artist "هنرمند": "گروه Acme"} ،
  {
    $ $: {
      "ژانر": "دیسکو"
    }
  ،
  "چند": true ، "upsert": true
)؛

حذف داده ها از یک جدول

PostgreSQL

حذف از موسیقی
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out، World'؛

کاساندرا

همان جمله اظهارات PostgreSQL DELETE در بالا.

MongoDB

MongoDB دو نوع عملیات برای رسیدگی به حذف اسناد دارد - DeleteOne () / DeleteMany () و حذف (). هر دو سند (ها) را حذف می کنند اما نتایج متفاوتی دارند.

db.music.deleteMany ({
        هنرمند: "گروه Acme"
    }
)؛

جداول را بردارید

PostgreSQL

DROP TABLE موسیقی؛

کاساندرا

مشابه جمله بالا PostgreSQL DROP TABLE؛

MongoDB

db.music.drop ()؛

خلاصه

بحث SQL و NoSQL اکنون بیش از یک دهه است که رواج دارد. دو جنبه از این بحث وجود دارد: معماری اصلی بانک اطلاعاتی (یکپارچه ، SQL معاملاتی در مقابل ، توزیع بدون تراکنش NoSQL) و روش مدل سازی داده ها (داده های خود را در SQL در مقابل مدل های نمایش داده های خود در NoSQL).

با استفاده از یک بانک اطلاعاتی توزیع شده و معامله ای مانند YugaByte DB ، می توان بخشی از معماری اصلی این بانک اطلاعات را به راحتی استراحت کرد. از آنجا که حجم داده ها فراتر از آنچه که می توانند در یک گره واحد نوشته شوند ، رشد می کنند ، یک معماری کاملاً توزیع شده که امکان مقیاس پذیری نوشتن خطی را با استفاده از خرد کردن / تغییر مجدد خودکار فراهم می کند. علاوه بر این ، همانطور که در این پست از Google Cloud شرح داده شده است ، معماری های معامله گر ، کاملاً سازگار اکنون برای ارائه پیشرفت و توسعه چابکی عملیات نسبت به معماری های غیر معاملاتی و در نهایت سازگار پذیرفته شده اند.

با توجه به بحث مدل سازی داده ها ، منصفانه است كه بگوییم كه هر دو روش مدل سازی داده SQL و NoSQL برای هر برنامه پیچیده دنیای واقعی ضروری است. مدل SQL-data-data-data شما به توسعه دهندگان می پردازد که راحت تر بتوانند نیازهای تجاری را تغییر دهند در حالی که رویکرد مدل-پرس و جوهای NoSQL شما به همان توسعه دهندگان این امکان را می دهد تا حجم داده های بزرگ را با تأخیر کم و توان بالا مدیریت کنند. این دقیقاً به همین دلیل است که YugaByte DB هر دو API SQL و NoSQL را در هسته مشترک به جای ترویج این که یک رویکرد کاملاً بهتر از روش دیگر است ، پیاده سازی می کند. علاوه بر این ، با اطمینان از سازگاری سیم با زبانهای پایگاه داده های رایج از جمله PostgreSQL و Cassandra ، YugaByte DB تضمین می کند که توسعه دهندگان به منظور بهره مندی از هسته پایگاه داده کاملاً توزیع شده ، زبان دیگری یاد نگرفته اند.

این پست به ما در درک چگونگی تفاوت مبانی مدل سازی داده بین PostgreSQL ، Cassandra و MongoDB کمک می کند. در پست های بعدی این مجموعه ، ما به مفاهیم پیشرفته مدل سازی داده ها مانند شاخص ها ، معاملات ، JOIN ها ، دستورالعمل های TTL و اسناد JSON می پردازیم.

بعدی چیست؟

  • YugaByte DB را با بانکهای اطلاعاتی مانند Amazon DynamoDB ، Cassandra ، MongoDB و Azure Cosmos DB مقایسه کنید.
  • با YugaByte DB در macOS ، Linux ، Docker و Kubernetes شروع کنید.
  • برای کسب اطلاعات بیشتر در مورد صدور مجوز ، قیمت گذاری یا برنامه ریزی یک بررسی اجمالی فنی با ما تماس بگیرید.

در ابتدا در وبلاگ پایگاه داده YugaByte منتشر شد.