منبع اصلی نوشتار زیر در این لینک قرار دارد

آموزش آپگرید دیتابیس MongoDB 4.0 به نسخه MongoDB 4.2

mongodb

در این مطلب قصد داریم تا دیتابیس MongoDB 4.0  که در حالت Standalone می باشد  را به نسخه ی MongoDB 4.2 آپگرید کنیم. قبل از هر کاری بهتر است که از داده ها و دیتابیس های خود نسخه پشتیبان (Backup) تهیه کنید. برای آپگرید به نسخه ی MongoDB 4.2 باید حتما نسخه ی MongoDB سری […] ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

آموزش نصب و پیکربندی دیتابیس MongoDB 4.2

mongodb

دیتابیس MongoDB یک دیتابیس NoSQL می باشد که با زبان ++C نوشته شده است و به صورت Open Source منتشر می شود. این دیتابیس برای high scalability, performance و availability طراحی شده است. در این مطلب قصد داریم تا نسخه ی MongoDB 4.2 را بر روی Fedora, RHEL و CentOS  نصب کنیم. توجه داشته باشید […] ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

آموزش Upgrade کردن دیتابیس Couchbase Server

در مطالب قبلی نحوه نصب دیتابیس Couchbase server و همچنین نحوه ی کلاستر کردن دیتابیس Couchbase server آموزش داده شد.در این مطلب قصد داریم تا نسخه ی Couchbase Server خود را Upgrade کنیم. برای Upgrade کردن دیتابیس Couchbase Server کافیست تا مراحل زیر را انجام داد. ۱- ابتدا نسخه جدید Couchbase Server را از سایت […] ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

آموزش Backup و Restore دیتابیس Couchbase server

در مطالب قبلی روش نصب دیتابیس Couchbase Server و همچنین نحوه ی کلاستر کردن Couchbase Server  آموزش داده شد.در این مطلب قصد دارم تا نحوه ی تهیه نسخه ی پشتیبان (Backup) و همچنین روش بازیابی (Restore) کردن نسخه ی پشتیبان Couchbase Server نسخه ی ۴٫۱ آموزش داده شود.   تهیه نسخه پشتیبان (Backup) :   […] ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

آموزش Cluster کردن دیتابیس Couchbase Server

در مطالب قبلی دیتابیس Couchbase معرفی شد و نحوه ی نصب آن بر روی توزیع CentOS 7.x آموزش داده شد.در این مطلب قصد دارم تا روش Cluster کردن دیتابیس Couchbase را خدمت شما عزیزان آموزش دهم. در این سناریو از سه Node استفاده خواهد شد که روی آنها CentOS 7.x نصب شده است و قصد […] ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

اندر مزایای پایگاه داده های گراف محور و OrientDB

در روز های اخیر کاری داشتم که نیاز داشتم یکسری اطلاعات رو که باهم ارتباط دارند مدل کنم.بعد از کلی تفکر تونستم اونارو روی گراف وزن دار جهت دار مدل کنم.بعد اومدم توی برنامه ازش استفاده کنم.از قبل میدونم که گراف رو میتونم روی ماتریس مجاورت مدل کرد تا راحت تر ذخیره کنم ولی وقتی … ادامه خواندن اندر مزایای پایگاه داده های گراف محور و OrientDB ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

کوئری بر روی آیتم های فیلد از نوع آرایه در mongodb

درصورتی که قصد داشته باشیم document هایی از یک collection خاص را براساس شرطی بر روی یکی از فیلد های از نوع آرایه ای آنها پیدا کنیم میتونیم از عبارت $elemMatch بصورت زیر استفاده کنیم:

مثال اول:

فرض میکنیم collection ما شامل موارد زیر باشد:

{ _id: 1, results: [ 82, 85, 88 ] }
{ _id: 2, results: [ 75, 88, 89 ] }

در این صورت برای پیدا کردن document هایی که قیلد result آنها دارای عدد ۸۸ است بصورت زیر عمل میکنیم:

db.collection.find({
results: { $elemMatch: 88 }
})

همچنین میتوان از شرط های پیچیده تری استفاده نمود:

db.collection.find({
results: {
$elemMatch: { $gte: 80, $lt: 85 }
}
})

مثال دوم (آیتم های آرایه از نوع آبجکت):

فرض میکنیم collection ما شامل موارد زیر باشد:

{ _id: 1, results: [ { product: "abc", score: 10 }, { product: "xyz", score: 5 } ] }
{ _id: 2, results: [ { product: "abc", score: 8 }, { product: "xyz", score: 7 } ] }
{ _id: 3, results: [ { product: "abc", score: 7 }, { product: "xyz", score: 8 } ] }

برای یافتن مواردی که در آنها product ی با مقدار score بزرگتر مساوی 8 باشد بصورت زیر عمل میکنیم:

db.collection.find({
results: {
$elemMatch: {
product: "xyz",
score: { $gte: 8 }
}
}
})

ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

پایگاه داده NoSQL

مقدمه 

در ادامه صبحت‌های که در پیشگفتار مطلب قضیه CAP در سیستم‌های توزیع شده، در این مطلب به معرفی پایگاه‌های داده NoSQL (نواس‌کیوال) می‌پردازم. این مطلب شامل معرفی نوع پایگاه داده NoSQL و ویژگی‌های آن است. در نهایت در مورد توضیحاتی در زمینه Polyglot Persistence ارائه خواهم کرد.

محدودیت های RDBMS و پیدایش جنبش NoSQL

همزمان با فراگیری دسترسی به وب در سطح جهان و با افزایش سرعت و حجم تولید اطلاعات، پایگاه‌های RDBMS مانند MySQL با محدودیت‌هایی مواجه شدند. این محدودیت ها عبارتند از:
  1. گسترش دادن  آن‌ها (Scalability) دشوار است.
  2. معماری آن‌ها به گونه‌ای است که در دسترس بودن تمام سیستم (Availability) دشوار نموده است.
  3. در ساختار و نوع ذخیره سازی اطلاعات محدودیت دارند.
  4. نحوه رشد آن‌ها به صورت Scale up است. به معنی اینکه برای افزایش کارایی باید سخت افزار هر سیستم را تقویت نمایید. در نتیجه هزینه تهیه و نگهداری سیستم‌ها به شدت افزایش می‌یابد.

پایگاه داده NoSQL چیست؟

عبارت NoSQL مخفف Not Only SQL بوده و به جنبش پدید آمدن مجموعه پایگاه‌های داده‌ای اطلاق می‌شود که مفاهیم متقاوتی با پایگاه های داده RDBMS مانند MySQL دارند. از جمله این مفاهیم می‌توان به موارد زیر اشاره کرد:
  • رابطه‌ای (Relational) نیستند. Join و مواردی از این قبیل که شامل رابطه‌ای بین چند جدول است، در NoSQL وجود ندارد.
  • به صورت افقی رشد می‌کنند. اصطلاحا Scale out یا Horizontally Scalable هستند. البته تمامی پایگاه‌های NoSQL امکان Scale out شدن را ندارد و برخی نیز به سختی Scale out می‌شوند.
  • امکان کنترل و مدیریت Availability (در دسترس بودن سرویس) ساده‌تر است.
  • گستره بیشتری از انواع داده و ساختارها را پشتیبانی می‌نمایند.

انواع پایگاه‌های داده NoSQL

انواع پایگاه های داده NoSQL
انواع پایگاه های داده NoSQL
یکی از مهمترین ویژگی‌های جنبش پایگاه‌های داده NoSQL پشتیبانی نمودن گستره عظیمی از انواع ساختار داده‌ها است. این ویژگی باعث انعطاف پذیری در مدل سازی و ذخیره اطلاعات شده است. از این رو پایگاه‌های داده NoSQL بر اساس مدل‌سازی اطلاعات به دسته‌بندی‌های زیر تقسیم می‌شوند:
  • Column: Cassandra, HBase
  • Document: CouchDB, Couchbase, MongoDB
  • Key-value: Dynamo, Redis, Riak
  • Graph: Neo4J, InfiniteGraph
  • Multi-model: OrientDB, FoundationDB
در نظر داشته باشید که انواع پایگاه‌های داده NoSQL برای منظورهای مختلفی طراحی شده است. به معنی آنکه هر کدام مزیت‌های خاص خود را دارند. به همین جهت در هنگام انتخاب پایگاه داده، عامل‌های زیر را در نظر گرفته و بررسی نمایید:
  1. نوع اطلاعاتی که قصد ذخیره سازی آن‌ها را دارید. 
  2. مدل سازی اطلاعات برای ذخیره و خواندن آن‌ها.
  3. میزان اطلاعات ورودی و خروجی سیستم.
  4. اهمیت Consistency و Availability در مدل تجاری‌تان. مطلب قضیه CAP در سیستم‌های توزیع شده را مطالعه نمایید.
  5. در دسترس بودن نیروی متخصص و مستندات کافی برای نگهداری سیستم (Maintenance)
نکته: با توجه به موارد قید شده در بالا، لزوما نمیتوان نوع خاصی از پایگاه‌های داده RDBMS یا NoSQL را به عنوان بهترین راه حل برای تمام بخش‌های یک سیستم در نظر گرفت. مارتین فاولر مفهوم Polyglot Persistence را برای توضیح بیشتر در این زمینه ارائه کرده است.

منظور از Polyglot Persistence چیست؟

هدف از Polyglot Persistence انتخاب و استفاده مناسب از پایگاه‌های داده متفاوت برای بخش‌های مختلف یک سیستم است. به بیان دیگر ممکن است در یک سیستم شما از چندین پایگاه داده استفاده نمایید. عبارت Polyglot به معنای دانستن زبان‌های مختلف بوده و Persistence نیز به معنای ادامه حیات است. با این اوصاف، مفهوم Polyglot Persistence یعنی ادامه حیات با استفاده از شناختن زبان‌های مختلف (در اصل و در اینجا، پایگاه‌های داده مختلف) است. به بیانی ساده‌تر، مفهوم Polyglot Persistence، همانند Polyglot Programming، انتخاب بهترین گزینه برای ادامه حیات موضوعی است که روی آن کار می‌کنیم. تصویر زیر Polyglot Persistence را به صورت گویاتر توضیح داده است:
Polyglot Persistence
Polyglot Persistence
بزودی مطالب بیشتری در زمینه Big Data منتشر خواهم کرد.


ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

قضیه CAP در سیستم‌های توزیع شده

پیشگفتار

مدتی است که در حال مطالعه در زمینه رایانش ابری (Cloud Computing)،  سیستم‌های کامپیوتری توزیع شده (Distributed Computer System) و بیگ دیتا (‌BigData) هستم. از طرفی برای پروژه‌های کاری شروع به استفاده از آپاچی کاساندرا (Apache Cassandra) کردم. مانند قبل به منظور به اشتراک گذاشتن تجربه، قصد نگارش مطالبی در این زمینه‌ها داشتم. متاسفانه محتوای فارسی در این زمینه‌ها بسیار اندک است. مقالاتی که قصد نوشتن آن‌ها را داشتم، به پیش‌نیازها زیادی داشت. از طرفی برخی مفاهیم به صورت مستقل معنی و مفهوم دارند. با توجه به این موضوعات، قبل از انتشار مقالات بیگ‌دیتا و آپاچی کاساندرا، مفاهیم و پیش‌نیازهای مرتبط را ارائه می‌کنم. قضیه CAP یکی از آن پیش‌نیازهاست.

مقدمه

امروزه تولید اطلاعات با سرعت سرسام آوری در حال رشد است. افزایش دسترسی مردم به اینترنت و نیز رشد روز افزون  شبکه‌های اجتماعی نمونه‌ای از این تولید اطلاعات است. همه روزه تعداد زیادی متن، عکس، ویدئو و… بر روی اینترنت قرار می‌گیرند. از طرفی، برخلاف گذشته، شرکت‌های بسیاری برای برنامه‌ریزی نقشه راه (Roadmap) و تعیین استراتژی، محتوای بسیاری از مشتریان را برای مدت طولانی ذخیره می‌کنند. سیستم‌های کامپیوتری توزیع شده از جمله مهم‌ترین راهکارها برای مدیریت این اطلاعات هستند. با افزدون هر رایانه به عنوان گره (node)  به این شبکه‌ها می‌توان بازدهی و توانایی آن‌ها را افزایش داد. رشد این شبکه‌ها به صورت افقی (Horizontal Scalability) یا همان Scale out است. در طی رشد این شبکه‌ها، پیچیدگی آن‌ها نیز افزایش می‌یابد. قضیه CAP برای توضیح مشکلات و محدودیت های این پیچیدگی ارائه شده است.

قضیه CAP

قضیه CAP
قضیه CAP

عبارت CAP ترکیب سرنام مفاهیم زیر است:

  • ثبات (Consistency): تمامی گره‌ها (nodes) اطلاعات یکسانی را در لحظه دارند.
  • دسترسی (Availability): هر درخواستی (request) حتما یک پاسخ دریافت خواهد کرد.
  • پارتیشن تولرنس (Partition tolerance): اگر بخشی از شبکه دچار مشکل شد، بقیه سیستم به کار خود ادامه خواهد داد. اشکال در بخشی از شبکه نباید منجر به توقف کار کل سیستم شود.
قضیه CAP بیانگر این موضوع است که در سیستم‌های توزیع شده شما فقط امکان فراهم کردن دو گزینه از سه گزینه Consistency, Availability و Partition tolerance را خواهید داشت و گزینه باقیمانده قربانی فراهم کردن سایر گزینه‌ها خواهد شد.
نکته: با توجه به مشکلات شبکه‌ای که در هر سیستم‌ای امکان بروز آن وجود دارد، توصیه متخصصین انتخاب قطعی Partition tolerant  به عنوان یکی از فاکتورهای گزینش شده است. انتخاب گزینه بعدی از بین Consistency و Availability کاملا به ماهیت نرم‌افزار و اولویت‌ها کارفرمای شبکه بستگی دارد. در ادامه توضیحات وضعیت گزینشی  AP و CP را مشاهده می‌فرمایید:

گزینش AP

انتخاب Availability و  Partition tolerance به معنی آن است که هر درخواستی، پاسخی دریافت خواهد کرد. این پاسخ تا جای ممکنه شامل جدیدترین اطلاعات خواهد بود ولی امکان قدیمی بودن آن نیز وجود دارد. از طرفی نوشتن اطلاعات جدید بر روی گره‌ها ممکن است در لحظه امکان پذیر نباشد (Partition tolerance). با این وجود سیستم به کار خود ادامه خواهد داد و در نهایت به ثبات اطلاعات خواهد رسید (Eventually Consistent). گزینش AP نشان‌دهنده این موضوع است که برای تجارت شما در دسترس بودن سیستم و سرعت بیشتر آن، اولویت بالاتری نسبت به ثبات و دوام اطلاعات در لحظه دارد.

گزینش CP

انتخاب Consistency و Partition tolerance به معنی آن است که هر درخواستی برای دریافت اطلاعات، دقیقا و حتما باید آخرین نسخه موجود را به عنوان پاسخ ارسال نماید. از طرفی، این آخرین نسخه موجود از هر اطلاعاتی بر روی سیستم کاملا مشخص و واضح است. یعنی اگر دو درخواست یکسان از دو مکان مختلف به سیستم ارسال شود، سیستم جواب یکسان و مشخصی را به هر دو خواهد داد. نکته دیگر اینکه با افزایش Consistency، شما مدت رکود (Latency Time) را نیز افزایش می‌دهید. هر میزان که Consistency مورد نیاز خود را افزایش دهید، سیستم دچار رکورد شده و سرعت پاسخ‌دهی کاهش می‌یابد.
نکته: بار دیگر تاکید میکنم که انتخاب AP یا CP کاملا به ماهیت نرم افزار و اولویت های تجاری کارفرما بستگی دارد.

جایگاه پایگاه‌های داده در گزینش CAP

پایگاه های داده مختلف گزینش های متفاوتی از CAP انجام می‌دهند. پایگاه‌های داده RDBMS به خاطر نوع طراحی و ماهیتی که دارند (ACID)، لزوما گزینش CA را انجام می‌دهند. بعضی از پایگاه های داده مانند Apache Cassandra انتخاب بین Availability و Consistency را بر عهده مدیر سیستم قرار داده است ولی به صورت بیش فرض خود گزینش AP را انجام می‌دهد. تصویر زیر تعدادی از پایگاه‌های داده و نحوه گزینش آن‌ها را به طور گویا بیان کرده است:
پایگاه‌های داده و قضیه CAP
پایگاه‌های داده و قضیه CAP

پی نوشت

  • متاسفانه معادل های فارسی تعریف شده برای واژه‌ها انگلیسی به قدر کافی گویا نیستند. از طرفی برخی عبارت چندین معادل فارسی دارند. مانند BigData که معادل های داده‌های عظیم، داده‌های انبوه، داده‌های حجیم، داده بزرگ، وزرگ داده و کلان داده را دارد. به همین دلیل در متن بیشتر از خود عبارت انگلیسی استفاده شده است.
  • در آینده در مورد پایگاه‌های داده NoSQL، آپاچی کاساندرا، BigData و سیستم‌های توزیع شده مطالب بیشتری خواهم نوشت.
  • لطفا دانش خود را با سایر به اشتراک بگزارید. متاسفانه مطالب تخصصی و فنی به زبان فارسی بسیار اندک است. همین موضوع باعث شده است که بسیاری از متخصصین و حتی افراد مبتدی به دنبال مطالب انگلیسی برای مطالعه باشند.


ادامه مطلب

منبع اصلی نوشتار زیر در این لینک قرار دارد

تغییر نام دیتابیس در MongoDB

اگه تا بحال راجع به بانک های اطلاعاتی NoSQL شنیده باشید، حتما اسم MongoDB رو هم شنیدید. یک بانک اطلاعاتی Document Based که اطلاعات رو بصورت داکیومنت هایی به فرمت JSON ذخیره میکنه.

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

خوب یکی از مواردی که تو کار با MongoDB ممکنه بهش بر بخوریم تغییر نام یک دیتابیس هستش. از اونجایی که خود MongoDB (حداقل تا الان) دستوری رو برای این منظور نداره و باید برای اینکار بصورت دیگه ای عمل کنیم. که در ادامه به چند روش انجام این کار اشاره میکنم:

تغییر نام بوسیله کپی کردن بانک اطلاعاتی:

یکی از روش هایی که برای تغییرنام میتونیم استفاده کنیم کپی بانک و پاک کردن نسخه قدیمی اون از روی سرور هستش، برای اینکار بصورت زیر عمل میکنیم:

> db.copyDatabase('old_database', 'new_database')
> use old_database
> db.dropDatabase()

تغییر نام بوسیله BackupRestore:

MongoDB برای Backup گیری از بانک ها و همچنین برگردوندن Backup ها دو تا دستور mongodump و mongorestore رو ارائه داده که میشه از اونها برای backup گیری از دیتابیس و برگردوندن backup با اسم جدید از اونها استفاده کرد. برای این منظور بصورت زیر عمل میکنیم:

mongodump --db old_database
mongorestore --db new_database /path/to/old_db_backup

پس از برگردوندن backup به سرور وصل میشیم و نسخه قدیمی رو با دستور dropDatabase پاک میکنیم:

mongo

> use old_database
> db.dropDatabase()


ادامه مطلب