اطلاعیه

بستن
هنوز اطلاعیه ای در دست نیست.

MySQL Cluster و نکات حیاتی که باید به آن ها توجه کرد

بستن
X
 
  • فیلتر کردن
  • زمان
  • نمایش
Clear All
پست های جدید

    MySQL Cluster و نکات حیاتی که باید به آن ها توجه کرد

    مقدمه : هدف این گزارش این است که به ما این امکان را بدهد تا بتوانیم به درستی MySQL Cluster را ارزیابی بکنیم و این نتیجه را بگیریم که آیا این سیستم برای برنامه ما مناسب است یا خیر. این گزارش یک دید کلی در مورد MySQL Cluster و قابلیت های جدید اضافه شده به آخرین نسخه 7.4 معروف به GA یا Generally available به ما می دهد، قبل از آن به بررسی موارد زیر می پردازیم :
    • ملاحظاتی که قبل از ارزیابی باید در نظر بگیریم
    • بهترین راه های ارزیابی
    • آپشن های تنظیمات (configurations) و sanity checking
    • رفع مشکلات (Troubleshooting)


    با پیشنهاداتی که در این مقاله خواهیم داد می توانیم به سرعت و با کارایی بالا MySQL Cluster را با توجه به پروژه خود ارزیابی کنیم و در نهایت موجب می شود در زمان کمتر بهترین راه حل را برای پروژه خود انتخاب کنیم.


    MySQL Cluster چیست؟

    MySQL Cluster یک دیتابیس تراکنشی است که قابلیت های شاخص آن عبارتند از :
    1 - Write-Scalable : یعنی قابلیت گسترش در سرورهایی که وظیفه write را بر عهده دارند را دارد.
    2 - Real-time : یعنی با اعمال هر تغییر بلافاصله در کل سیستم اعمال می گردد.
    3 - In-memory : این قابلیت را دارد که قسمت های بزرگی از دیتابیس را به حافظه بیاورد و در آن ها اعمال تغییر کند یا از آنها بخواند
    4 - ACID-compliant : یعنی قابلیت های ACID دیتابیس را دارد، که عبارتند از :
    • Atomicity : اگر یک قسمت تراکنش با مشکلی روبرو گردد، کل تراکنش اعمال نمی گردد.
    • Consistency : هر تراکنش state دیتابیس را از یک حالت پایدار به یک حالت پایدار دیگر انتقال می دهد.
    • Isolation : اگر هزاران تراکنش همزمان اجرا گردند، با این که تک تک پشت سر هم اعمال گردند برای دیتابیس فرقی ندارد و خللی در کار آن ایجاد نمی کند.
    • Durability : اگر یک تراکنش اعمال گردد، دیگر در هیچ شرایطی نتیجه آن تراکنش در دیتابیس تخریب نمی گردد حتی در قطعی برق، crash کردن دیتابیس و ...

    5 - طراحی Multi-master بدون single point of failure
    6 - قابلیت توسعه به صورت افقی : با استفاده از تقسیم داده ها به صورت auto-sharding که موجب می گردد write و read هر دو در بین گره ها تقسیم گردند


    MySQL Cluster به صورت real-time طراحی شده است که می تواند یک زمان پاسخ قابل پیش بینی در حد چند میلی ثانیه را به ما بدهد همچنین قابلیت اجرای چند میلیون operation در ثانیه را دارد. از داده های in-memory و disk-based ،تقسیم بندی داده های توزیع شده (sharding)، توزیع بار (loadbalancing) و امکان افزایش گره به صورت آنلاین بدون downtime را دارد، این موجب می شود که توسعه پذیری دیتابیس به صورت خطی افزایش یابد.

    در MySQL cluster7.2 یک افزونه برای پشتیبانی از Memcashed اضافه شده است که موجب می شود که کلاینت ها بتوانند با پروتکل Memcashed مستقیم به جداول دسترسی داشته باشند.


    معماری MySQL Cluster

    MySQL Cluster از سه نوع گره تشکیل شده است که هدف کلی آن ها افزایش کارایی، افزایش توسعه پذیری به صورت خطی و دسترسی پذیری 99.999% می باشد.
    عکس زیر یکی معماری ساده از MySQL Cluster را نشان می دهد که دارای 12 گره اطلاعات که در شش گروه تقسیم شده اند می باشد.
    کلاستر کردن مای اسکیول




    Data Nodes (گره های داده ای) گره های اصلی در MySQL Cluster هستند که کارکردهای زیر را دارند :
    • ذخیره سازی و مدیریت داده های in-memory و disk-based
    • تقسیم بندی اتوماتیک و تعریف شده داده های جدول ها partitioning (sharding)
    • Synchronous replication داده ها بین گره های داده ای
    • استخراج داده و تراکنش ها
    • Fail over به صورت اتوماتیک
    • اصلاح و ترمیم خود به صورت اتوماتیک و همگام سازی مجدد بعد از تخریب دیتابیس


    تمامی گره های داده ای master هستند و می توانند عمل write انجام دهند و داده ها به صورت اتوماتیک بین آنها shard می شود، این موجب می گردد که بدون متوجه شدن اپلیکیشن این master ها را توسعه داد.

    با استفاده از این معماری و بدون استفاده از یک محیط ذخیره سازی مشترک (shared nothing storage) ،اگر یکی از این گره ها از بین بروند این داده ها در گره دیگری وجود دارند، بنابراین سیستم از کار نمی افتد. تمامی تراکنش هایی که در آن چند میلی ثانیه ای که گره fail شد دوباره اعمال می گردند.

    می توانیم انتخاب کنیم که داده ها به چه روشی ذخیره گردند : تمامی آن ها بر روی حافظه ذخیره گردند یا این که بخشی بر روی دیسک ذخیره گردند (Non-indexed data only). داده هایی که در حافظه ذخیره می گردند در دوره های کوتاه زمانی در داخل دیسک ذخیره می گرند تا در صورت بروز اتفاق ناگهانی مانند قطعی برق داده ها از بین نروند، استفاده از معماری in-memory تنها زمانی مناسب است که یک date set که در حافظه لود شده است را به تعداد زیاد تغییر دهیم و از آن query بگیریم در این حالت با توجه به این که داده ها در حافظه لود شده اند کارایی بسیار زیاد می شود. حالت دوم یعنی disk-based به این صورت است که داده ها در دیسک هستند و وقتی که به آن احتیاج است آن را به حافظه می آوریم، در صورتی که زیاد بر روی یک dataset خاص query زده نمی شود و حافظه کم است از این روش استفاده می کنیم که کارایی معمولی دارد.

    Application Node این گره ارتباط بین گره های داده ای و خود اپلیکیشن را فراهم می کند.
    Management node وظیفه دارد که تمامی فایل های تنظیمات را بین گره ها ارسال و هماهنگ گند، این گره اول از همه گره ها روشن می شود و اگر و گره جدیدی را به کلاستر اضافه کنیم یا تغییری در تنظیمات انجام دهیم این گره ها این تغییرات را مدیریت می کنند. این گره ها جدا شدن یا افزوده شدن گره های جدید به کلاستر را مدیریت می کنند تا کارکرد آن مختل نشود. این گره ها از به وجود آمدن ارورهای حیاتی در کلاستر جلوگیری می کند، مثلا وقتی که برق قطع می شود و کلاستر را به دو تکه تبدیل می کند (split-brain syndrome).

    در لینک زیر یاد می گیریم که چگونه به سرعت دیتابیس های خود را گسترش بدهیم (scale out کنیم).
    کد:
    http://www.mysql.com/why-mysql/white-papers/guide-to-scaling-web-databases-with-mysql-cluster/



    3 قابلیت کلیدی در MySQL Cluster 7.4

    این نسخه از MySQL Cluster بر اساس قابلیت های نسخه های قبلی ساخته شده و چند قابلیت دیگر به آن اضافه شده است که موجب می گردد که انتخاب مناسبی برای استفاده در اپلیکیشن های تحت وب، بازی و تلکام باشد :
    • بهبود در کارایی : در این نسخه بهبود بسیار خوبی در کارایی در دسترسی به جدول ها ،کلید های جدولها یافته است. این امکان وجود دارد که دسترسی SQL یا NoSQL پشتیبانی شود - 2.5 میلیون دسترسی SQL و 200 میلیون درخواست READ مربوط به NoSQL در ثانیه.
    • قابلیت پیاده سازی active-active کامل با قابلیت تشخیص برخود (conflict) و تصحیح آن برخورد
    • نگهداری و recovery به صورت آنلاین و با سرعت بسیار بالا
    • Monitoring توزیع شده


    برای آشنایی کامل با تمام این قابلیت ها لینک زیر را ببینید :
    کد:
    http://www.mysql.com/why-mysql/white-papers/mysql-cluster-new-features-whitepaper/

    قبل از ارزیابی 4 نکته را باید در نظر گرفت :

    آیا MySQL Cluster در حالت عادی یک اپلیکیشن را سریعتر از یک MySQL ای که من الان استفاده می کنم پاسخگو است؟

    اگر بر روی MySQL Cluster چند optimization انجام نشود در حالت عادی سرعت MySQL Cluster کمتر است. در لینک زیر روش هایی برای بهبود کارایی دیتابیس و MySQL Cluster ارایه می شود که باعث می شود که با حفظ دسترسی پذیری بالا و تاخیر کم، در سرعت و کارایی بهبود بدهیم، مخصوصا زمان هایی که دیتابیس های Write را گسترش می دهیم.
    کد:
    http://www.mysql.com/why-mysql/white-papers/guide-to-optimizing-performance-of-the-mysql-cluster/

    آیا اپلیکیشن شما از دستورات JOIN پیچیده بهره می برد؟
    در این صورت می توان از قابلیت جدید MySQL Cluster استفاده کرده که موجب می گردد سرعت دستورات SQL تا 70 برابر بیشتر شود. دو قابلیت افزوده شده زیر می توانند این کار را برای ما انجام دهند.
    • استفاده کردن از Index به این عمل کمک می کند. تا کنون برای هر استفاده از این قابلیت باید از دستورات USE INDEX یا FORCE INDEX استفاده می کردیم، حالا در ابتدا بر روی جدول ها یک بار از ANALYZE TABLE استفاده می کنیم و از این به بعد از این قابلیت استفاده می گردد.
    • قابلیت دوم AQL است (Adaptive Query Localization) که این قابلیت کمک می کند که دستورات JOIN پیچیده بر روی گره های دادهای توزیع شوند و در این صورت تا چندین برابر سرعت اجرای این دستورات افزایش میابد.


    در مورد این قابلیت و دستورات نمونه می توانید لینک زیر را ببینید :
    کد:
    http://www.mysqlhighavailability.com/mysql-cluster/70x-faster-joins-with-aql-in-mysql-cluster-7-2

    آیا اپلیکیشن شما از Full-text search استفاده می کند؟
    MySQL Cluster از این قابلیت پشتیبانی نمی کند و باید برای این کار یک دیتابیس InnoDB که به صورت Read onley است استفاده کنیم که با کلاستر ما Replication دارد و از یک text search engine مانند Sphinx یا lucene استفاده کنیم.

    MySQL Cluster نسبت به موتورهای ذخیره سازی دیگر چگونه ارزیابی می شوند؟
    در ادامه یک سری کامنت ها در مورد این موتور ذخیره سازی داده شده است که آن ها را می بینید:

    “An INSERT into a MySQL Cluster takes longer then if I just use a MEMORY table, why is this?”
    “We have a large MyISAM table and when we altered it to InnoDB it took several seconds to
    migrate. When we altered the table to NDB (MySQL Cluster), it took five times as long. We expect
    it to be faster.”
    “We perform similar requests against INNODB and MySQL Cluster and the InnoDB request is
    always faster, why?”



    کسانی که کامنت های بالا را داده اند تفاوت ساختاری که کلاسترینگ نسبت به باقی موتورهای ذخیره سازی دارند را در نظر نگرفته اند.
    MySQL Cluster یک سیستم توزیع شده است که از shared storage هم استفاده نمی کند، بنابراین این سیستم یک سیستم است که concurrency بالایی دارد و می تواند کارایی بسیار بالایی در شرایطی که اپلیکیشن از PK استفاده می کند بدهد ولی به شدت وابسته به شبکه است چرا که داده ها را بین سرورها توزیع می کند.

    در شکل زیر بررسی می کنیم که برای پاسخگویی به یک query چندین دسترسی به سرورهای مختلف (گره های داده ای) خواهیم داشت.. قابلیت AQL که قبل توضیح دادیم می توان به شدت این دسترسی ها را کاهش دهد ولی باز هم می بینید که ممکن است چنیدن دسترسی به پاسخگویی به یک query داشت.
    نحوه کلاستر کردن دیتابیس mysql/mariadb



    می بینید که برای پاسخ به این query باید یک دسترسی شبکه ای به Node Group 2 داشت چون دیتابیس توزیع شده است ولی توجه داشته باشید که اگر همه آن ها در یک سرور بودند query به شکل زیر اجرا می شد.
    آموزش cluster کردن دیتابیس mysql/mariadb



    MySQL Cluster زمانی که query های کمتر با حجم داده های بالاتر بگیریم کارایی بهتری دارد پس اگر می توان اپلیکیشن را در این راستا بهبود داد موجب می شود که کارایی بسیار بهتر شود، نکته بعدی این که MySQL Cluster 7.4 در زمینه اسکن کردن جداول بهبود زیادی پیدا کرده است.

    آیا دیتابیس توزیع شده در پیچیدگی اپلیکیشن نقشی دارد؟
    خیر

    در صورتی که یکی از گره ها از کار بیافتد چه تاثیری در عملکرد اپلیکیشن دارد؟
    اگر یک گره از کار بیافتد در چند میلی ثانیه به صورت اتوماتیک یک گره دیگر جایگزین می شود و هیچ تاثیر قابل درکی در اپلیکیشن ما نخواهد داشت. البته در صورتی که یکی از گره های مدیریتی management nodes از کار بیافتد وقتی که یک گره دیگر در سیستم وجود داشته باشد تمامی کانکشن های اپلیکیش باید یک بار قطع شود و دوباره به گره جدید زده شود، در صورتی که گره مدیریتی دیگری قرار نداده باشیم اپلیکیشن کار نمی کند تا یک گره مدیریتی افزوده شود.


    تئوری CAP چیست و برای ما چه اهمیتی دارد؟

    این تئوری به ما می گوید که امکان ندارد یک سیستم کلاسترینگ هر سه قابلیت زیر را همزمان برای ما گارانتی بکند :
    1. Consistency : این که تمامی گره ها در یک لحظه داده های یکسانی داشته باشند.
    2. Availability : این قابلیت که تمامی درخواست ها پاسخ بگیرند.
    3. Partition tolerance : سیستم به کار خود ادامه می دهد با این که یک تعداد کمی از پیام ها Loss می شوند.


    بر اساس این نظریه در یک لحظه یک سیستم کلاسترینگ دو مورد از موارد بالا را گارانتی می کند، در یک لحظه هر سه گارانتی نمی شود.

    در لینک زیر اطلاعات کاملی در مورد این مساله می توانید ببینید:
    کد:
    http://messagepassing.blogspot.co.uk/2012/03/cap-theorem-and-mysql-cluster.html

    در لینک زیر می توانید توسیه هایی ببینید مبنی بر این که معماری کلاسترینگ را چگونه بسازید تا کمترین Availability را افزایش دهید.
    کد:
    http://mysqlhighavailability.com/mysql-cluster-fault-tolerance-impact-of-deployment-decisions/

    سیاستی که MySQL Cluster پیش گرفته است اولویت consistency در هر شرایطی از دو مورد دیگر بیشتر است:
    کد:
    if (network Partition)
    {
    trade-off Availability vs Consistency;
    }
    else
    {
    trade-off Latency vs Consistency;
    }

    آیا به اندازه کافی رم دارید ؟

    MySQL Cluster می تواند از داده های disk-based و in-memory پشتیبانی کند. داده های index نشده می توانند در دیسک ذخیره شوند ولی داده های Index شده باید همیشه در مموری ذخیره شوند. هر چه دیتابیس بزرگ تر شود شما به سخت افزار و مموری بیشتری احتیاج دارید.

    فرمول های زیر را سایت Oracle برای فهمیدن مقدار رم مورد نیاز جهت پیاده سازی MySQL Cluster ارایه می دهد :
    کد PHP:
    [*=left] (in memoryData Size Replicas 1.25 Total Database Memory Requirements Example50 GB 1.25 125 GB
    [*=left] (Data Size Replicas 1.25)/Nodes RAM Per Node Example: (50 GB 1.25)/31.25 GB 
    یعنی اگر یک دیتابیس داریم که به 50 گیگابایت رم احتیاج دارد و یک کلاستر با 4 گره می خواهیم از آن بسازیم در کل 125 گیگابایت رم احتیاج است و هر گره 31.25 گیگابایت رم احتیاج دارد.

    نکته : با توجه به جمله بالا حداقل رم که می خواهیم به سیستم اختصاص دهیم برابر با مقدار داده index شده است که این خود می تواند بیشتر از رمی باشد که دیتابیس کنونی ما دارد.



    نکته 2 : استفاده کردن indexing یک عیب و یک مزیت برای ما دارد :
    مزیت : در صورتی از indexing استفاده کنیم یک درخت B-tree از آن ساخته می شود و در رم نگهداری می شود و بنابراین دسترسی به آن به O(log n) صورت می گیرد در حالی که در حالت عادی با O(n) این عمل انجام می شود.

    عیب : B-tree در رم ذخیره می شود و برای جدول هایی که از Indexing استفاده می کنیم به همان مقدار باید به آنها رم اختصاص دهیم.


    از جدول های in-memory استفاده کنیم یا از جدول های disk-based ؟

    ما می توانیم dataset ای داشته باشیم که از مقدار رم ما بیشتر باشد ولی باید تعریف کنیم که در دیسک ذخیره گردد. داده های non-indexed می توانند در دیسک ذخیره شوند ولی داده های indexed باید حتما در memory ذخیره گردند. هرچه دیتابیس بزرگتر شود و از index های بیشتری در جدول ها استفاده کنیم باید رم بیشتری هم به سیستم اضافه کنیم. در صورت استفاده از in-memory دیگر هزینه IO را نداریم. با توجه به موارد گفته شده می توان یکی از این موارد را برای دیتابیس خود انتخاب کرد.


    Partitioning داده و نتیجه آن در درخواست های ما

    از قبل گفتیم که وقتی که یک تکه داده را می خواهیم در دیتابیس اضافه کنیم، اگر موتور ذخیره سازی آن MySQL Cluster باشد در این صورت هر row در یک گره داده ای ذخیره می شود یعنی در حالت sharding داده ها در گره های مختلف پخش می شوند. وقتی که می خواهیم یک داده را از دیتابیس بخوانیم بهترین حالت این است که تمامی داده مورد نیاز ما در یک گره باشد و با یک درخواست آن را در اختیار ما قرار دهد این در مقایسه با حالتی است که با درخواستی که می دهیم تکه های مختلف داده از گره های مختلف آورده شود و بنا براین باید منتظر جواب از گره های دیگر باشیم و این خودش latency ایجاد می کند.

    به صورت پیشفرض primary key در دیتابیس hash می شود. ما می توانیم این رفتار را تغییر دهیم و به صورت مهندسی شده بگوییم فقط قسمتی از کلید Hash شود با این کار look up آن تنها در یک جدول به نتیجه می رسد به این روش partition pruning می گویند.

    نتیجه حاصل از آن در عملکرد بهتر سیستم به تعداد گره ها حجم نتیجه query بستگی دارد. بهترین کارایی زمانی حاصل می شود که تعداد گره ها زیاد و نتیجه حاصل از درخواست دیتابیس حجم کمتری داشته باشد. شکل زیر به ما می گوید که نتیجه حاصل از partition pruning نارنجی رنگ در مقایسه با حالت عادی چگونه است. هر چه این ستون ها کوچک تر باشند latency کمتر و در نتیجه کارایی بهتر را نشان می دهند. با توجه به این داده ها می توانیم در مورد دیتابیس خودمان تصمیم بگیریم که آیا از این قابلیت استفاده بکنیم یا نه.
    آموزش cluster کردن دیتابیس



    منبع 1
    منبع 2

    موفق باشید.
    آخرین ویرایش توسط Habili; در تاریخ/ساعت 02-10-2021, 12:53 PM.
    اینستاگرام انجمن لینوکس ایران : https://www.instagram.com/iranlinuxforum

درباره انجمن منطقه لینوکسی ها

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

شبکه های اجتماعی
در حال انجام ...
X