چگونه بدون از دست دادن داده ها، ثبات و ایمان به NoSQL به چشمان کاساندرا نگاه کنیم

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

من در مورد تجربه خود در پیاده سازی یک راه حل مبتنی بر DBMS کاساندرا به شما خواهم گفت: با چه چیزهایی روبرو می شدیم، چگونه از شرایط دشوار خارج شدیم، آیا می توانستیم از استفاده از NoSQL سود ببریم و کجا باید تلاش ها / بودجه بیشتری را سرمایه گذاری کنیم. .
وظیفه اولیه ساختن سیستمی است که تماس ها را در نوعی ذخیره سازی ضبط می کند.

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

کاملاً واضح است که چرا آنها کاساندرا را انتخاب کردند - او مانند یک مسلسل می نویسد، به راحتی مقیاس پذیر است و تحمل خطا دارد.

بنابراین، این چیزی است که تجربه به ما داد

بله، یک گره شکست خورده یک تراژدی نیست. این جوهره تحمل خطای کاساندرا است. ولی یک گره می تواند زنده باشد و در عین حال شروع به آسیب در عملکرد کند. همانطور که مشخص شد، این بلافاصله بر عملکرد کل خوشه تأثیر می گذارد.

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

IB به شدت از Cassandra رایگان خارج از جعبه متنفر بود: هیچ گزارشی از اقدامات کاربر وجود ندارد، هیچ تفاوتی در حقوق وجود ندارد. اطلاعات مربوط به تماس‌ها، داده‌های شخصی در نظر گرفته می‌شوند، به این معنی که تمام تلاش‌ها برای درخواست/تغییر آن به هر طریقی باید با امکان ممیزی بعدی ثبت شوند. همچنین، باید از نیاز به جداسازی حقوق در سطوح مختلف برای کاربران مختلف آگاه باشید. یک مهندس عملیات ساده و یک مدیر فوق العاده که می تواند آزادانه کل فضای کلید را حذف کند، نقش ها، مسئولیت ها و شایستگی های متفاوتی دارند. بدون چنین تمایزی در حقوق دسترسی، ارزش و یکپارچگی داده ها بلافاصله سریعتر از هر سطح سازگاری زیر سوال می رود.

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

در انتقال داده ها به مناطق آزمایشی با مشکل مواجه شدیم (5 گره در آزمون در مقابل 20 گره در پروم). در این حالت نمی توان از دامپ استفاده کرد.

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

زمان درج کردن. کاساندرا در ضبط زیباست، اما گاهی اوقات جریان ورودی می تواند به طور قابل توجهی او را متحیر کند. این زمانی اتفاق می افتد که برنامه شروع به چرخش در اطراف چندین رکورد می کند که به دلایلی نمی توان آنها را وارد کرد. و ما به یک DBA واقعی نیاز خواهیم داشت که گزارش‌های gc.log، سیستم و اشکال‌زدایی را برای پرس‌و‌جوهای کند، معیارهای فشرده‌سازی در انتظار نظارت داشته باشد.

چندین مرکز داده در یک خوشه از کجا بخوانیم و کجا بنویسیم؟
شاید به خواندن و نوشتن تقسیم شود؟ و اگر چنین است، آیا باید یک DC نزدیکتر به برنامه برای نوشتن یا خواندن وجود داشته باشد؟ و آیا اگر سطح سازگاری اشتباهی را انتخاب کنیم، به یک مغز شکاف واقعی نخواهیم رسید؟ سوالات زیادی وجود دارد، تنظیمات ناشناخته زیادی وجود دارد، احتمالاتی که شما واقعاً می خواهید آنها را سرهم کنید.

چطور تصمیم گرفتیم

برای جلوگیری از غرق شدن گره، SWAP غیرفعال شد. و حالا در صورت کمبود حافظه، گره باید پایین بیاید و مکث های بزرگ gc ایجاد نکند.

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

ما پشتیبانی را از DataStax خریداری کردیم. توسعه Cassandra جعبه دار قبلاً متوقف شده است (آخرین ارتکاب در فوریه 2018 بود). در عین حال، Datastax خدمات عالی و تعداد زیادی راه حل اصلاح شده و سازگار برای راه حل های IP موجود ارائه می دهد.

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

ما دو گزینه را در نظر گرفتیم در گزینه اول فراخوانی را نه تنها در C* بلکه در پایگاه داده Oracle بایگانی شده می نویسیم. فقط برخلاف C*، این پایگاه داده تماس ها را فقط برای ماه جاری ذخیره می کند (عمق ذخیره تماس کافی برای شارژ مجدد). در اینجا بلافاصله مشکل زیر را مشاهده کردیم: اگر به صورت همزمان بنویسیم، تمام مزایای C* مربوط به درج سریع را از دست خواهیم داد؛ اگر به صورت ناهمزمان بنویسیم، هیچ تضمینی وجود ندارد که همه تماس‌های لازم به طور کلی وارد Oracle شوند. یک مثبت وجود داشت، اما یک مورد بزرگ: برای عملیات، همان توسعه دهنده آشنای PL/SQL باقی می ماند، یعنی ما عملاً الگوی "نما" را پیاده سازی می کنیم. یک گزینه جایگزین. ما مکانیزمی را پیاده‌سازی می‌کنیم که تماس‌ها را از C* تخلیه می‌کند، برخی از داده‌ها را برای غنی‌سازی از جداول مربوطه در Oracle می‌کشد، به نمونه‌های به‌دست‌آمده می‌پیوندد و نتیجه را به ما می‌دهد، که سپس به نوعی از آن استفاده می‌کنیم (بازگرداندن، تکرار، تجزیه و تحلیل، تحسین کردن). معایب: این فرآیند کاملاً چند مرحله ای است و علاوه بر این، هیچ رابطی برای کارمندان عملیات وجود ندارد.

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

هنگام حل مشکل به روز رسانی داده های آزمایش صنعتی، ما دوباره چندین راه حل را در نظر گرفتیم. هم انتقال از طریق Sstloader و هم گزینه تقسیم خوشه در منطقه آزمایشی به دو قسمت، که هر کدام به طور متناوب به خوشه مشابهی با قسمت تبلیغاتی تعلق دارند، بنابراین از آن نیرو می گیرند. هنگام به روز رسانی تست، قرار بود آنها را تعویض کنیم: بخشی که در آزمایش کار می کرد پاک می شود و وارد تولید می شود و دیگری به طور جداگانه با داده ها شروع به کار می کند. با این حال، پس از تفکر مجدد، داده‌هایی را که ارزش انتقال را داشتند، منطقی‌تر ارزیابی کردیم و متوجه شدیم که خود تماس‌ها موجودیت ناسازگاری برای آزمایش هستند، در صورت لزوم به سرعت تولید می‌شوند و این مجموعه داده‌های تبلیغاتی است که ارزشی برای انتقال به آن ندارد. تست. چندین وسیله ذخیره سازی وجود دارد که ارزش جابجایی را دارند، اما اینها به معنای واقعی کلمه چند میز هستند و نه خیلی سنگین. بنابراین ما به عنوان یک راه حل، Spark دوباره به کمک آمد، با کمک آن نوشتیم و شروع به استفاده فعال از یک اسکریپت برای انتقال داده ها بین جداول، آزمون prom کردیم.

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

برای اطمینان از در دسترس بودن مستمر کاساندرا، شما به یک dba و نه تنها او نیاز دارید. همه کسانی که با اپلیکیشن کار می کنند باید بدانند که کجا و چگونه به وضعیت فعلی نگاه کنند و چگونه مشکلات را به موقع تشخیص دهند. برای انجام این کار، ما به طور فعال از DataStax OpsCenter (مدیریت و نظارت بر بارهای کاری)، معیارهای سیستم Cassandra Driver (تعداد وقفه های زمانی برای نوشتن به C*، تعداد وقفه های زمانی برای خواندن از C*، حداکثر تأخیر و غیره)، نظارت بر عملکرد استفاده می کنیم. از خود برنامه، کار با کاساندرا.

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

در نتیجه، در حال حاضر در سطح سازگاری برای نوشتن EACH_QUORUM متوقف شد، برای خواندن - LOCAL_QUORUM

برداشت ها و نتیجه گیری های مختصر

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

بلافاصله، سپس امتیازدهی داده‌ها برای برنامه‌هایی مانند «پرداخت در زمانی که راحت است» (ما اطلاعات را در C* بارگیری می‌کنیم، محاسبه با استفاده از اسکریپت‌های Spark)، حسابداری ادعاها با تجمیع منطقه، ذخیره نقش‌ها و محاسبه حقوق دسترسی کاربر بر اساس نقش ماتریس

همانطور که می بینید، رپرتوار گسترده و متنوع است. و اگر کمپ حامیان/مخالفان NoSQL را انتخاب کنیم، از آنجایی که مزایای خود را دریافت کردیم و دقیقاً همان جایی که انتظار داشتیم، به حامیان می‌پیوندیم.

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

با استفاده از معماری خود در پروژه های جدید، و در حال حاضر با داشتن تجربه ای، می خواهم فوراً تفاوت های ظریف توضیح داده شده در بالا را در نظر بگیرم و از برخی اشتباهات جلوگیری کنم، برخی از گوشه های تیز را صاف کنم که در ابتدا نمی توان از آنها اجتناب کرد.

برای مثال، به‌روزرسانی‌های کاساندرا را به موقع پیگیری کنیدزیرا تعداد زیادی از مشکلاتی که داشتیم قبلاً شناخته شده و رفع شده بودند.

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

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

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

بد نیست فوراً برای پیوست کردن TTL و تمیز کردن داده های قدیمی فراهم کنید.

هنگام بارگیری داده ها از کاساندرا منطق برنامه باید بر اساس اصل FETCH کار کند، به طوری که همه ردیف ها به یکباره در حافظه بارگذاری نمی شوند، بلکه به صورت دسته ای انتخاب می شوند.

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

اگر با اطلاعات مهم (مانند داده‌های صورت‌حساب، محاسبه بدهی مشترک) کار کنیم، باید به ابزارهایی نیز توجه کنیم که خطرات ناشی از ویژگی‌های DBMS را کاهش می‌دهند. به عنوان مثال، از ابزار nodesync (Datastax) استفاده کنید، با ایجاد یک استراتژی بهینه برای استفاده از آن به ترتیب به خاطر ثبات، بار بیش از حد بر روی کاساندرا ایجاد نکنید و فقط برای جداول خاصی در یک دوره معین از آن استفاده کنید.

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

منبع: www.habr.com