نوشته های محمد حسین حاجی وندی

OLTP vs OLAP

محمد حسین حاجی وندی — Mon, 22 Aug 2022 09:53:18 +0430

عنوان رو هوش مصنوعی به عکس تبدیل کرده!در این نوشتار می‌خواهم در مورد دسته‌ای از سامانه‌ها صحبت کنم که به سامانه‌های پردازش تحلیلی برخط یا OLAP معروف هستند و تفاوتشان را با دسته ی دیگری به نام سامانه های پردازش تراکنش برخط یا OLTP توضیح بدهم. این سامانه‌ها در واقع نوعی سامانه‌ی ذخیره و بازیابی داده هستند که در حوزه ی کلان‌داده مورد استفاده قرار می‌گیرند. به دلیل اینکه برای اجرای پرس‌و‌جو (Query) روی حجم زیادی از داده‌ها بهینه شده‌اند. در مقابل سامانه‌های مبتنی بر OLTP برای پردازش حجم زیادی از تراکنش مورد استفاده قرار می‌گیرند.به دلیل اینکه در سامانه های OLTP و OLAP تعامل با کاربر وجود دارد از کلمه ی برخط (Online) در نام‌گذاری این سامانه ها استفاده شده است.اما منظور از تراکنش چیست؟تراکنش یعنی دنباله‌ای از عملیات‌های درج،ویرایش و حذف رکورد که در پایگاه‌داده که با زمان تاخیر کم انجام می‌شود. نقطه‌ی مقابل پردازش تراکنش، پردازش دسته‌ای است که به صورت دوره‌ای (ساعتی/روزانه/هفتگی) انجام می‌شود و معمولا زمان تاخیر قابل توجهی دارد.بیشتر کاربرد سامانه‌های OLTP در موارد زیر است:دستگاه‌های خودپردازسیستم‌های رزواسیونسیستم‌های خرید اینترنتیو …بیشتر سامانه های OLTP را می‌توان با استفاده از پایگاه‌های داده‌ی رابطه‌ای پیاده‌سازی کرد. چیزی که در پیاده‌سازی سامانه های OLTP باید مورد توجه قرار بگیرد، این است که همان طور که قبلا اشاره شد پردازش حجم زیادی ازتراکنش ها را پشتیبانی کند، در عین حال که بتواند یکپارچه سازی داده ها را حفظ کند و همچنین چندین کاربر همزمان بتوانند از این سامانه استفاده کنند. برنامه‌های که از سامانه ی OLTP به عنوان پایگاه‌داده استفاده می کنند، معمولا از الگوهای مشخصی پیروی می‌کنند. از جمله اینکه رکورد ها توسط ورودی که از کاربر گرفته می شود، درج و به‌روزرسانی می شوند یا اینکه تعداد کمی رکورد در لحظه توسط کلیدهایی که یک کاربر به عنوان اندیس وارد کرده است بازیابی می‌شود. محدویت های این سامانه این است که نمی توان برای مقاصد تحلیلی از آن‌ها استفاده کرد. به همین دلیل سامانه های OLAP اختراع شدند. تفاوت اصلی سامانه های OLAP با OLTP این است که در سامانه های OLAP برای پاسخ دادن به یک پرس‌و‌جوی تحلیلی نیاز است که حجم عظیمی از رکوردهای ذخیره شده مورد بررسی قرار بگیرد. گاهی ممکن است که برخی از ستون‌ها خوانده شود. روی نتیایج محاسبات آماری خاصی لحاظ شود و نتیجه در قالب یک گزارش به کاربر ارائه شود.پرس‌و‌جو‌هایی که توسط سامانه ی OLAP پاسخ داده می‌شود معمولا با این هدف نوشته شده است که سازمان بتواند تصمیم بهتری بگیرد، یا گزارش جامع‌تری از داده‌های موجود آماده کند. در سامانه‌های OLAP با یک رکورد یا تراکنش طرف نیستیم بلکه با تعداد زیادی از رکورد‌ها طرفیم.از لحاظ تاریخی هم، کسب و کار ها ابتدا از سامانه های OLTP استفاده می کردند و پرس‌و‌جو های خود را به زبان SQL تبدیل میکردند و روی سامانه ها اجرا می کردند و جواب را دریافت می‌کردند. تا اینکه در اواخر دهه ۸۰ میلادی نیازمندی های تحلیلی پیشی گرفتند و سازمان ها شروع کردند به توسعه و به کارگیری سامانه‌های OLAP و پایگاه های داده ی مجزایی برای اینکار اختصاص دادند تا پرس‌و‌جو های تحلیلی را روی آن اجرا کنند که به این پایگاه داده ها، پایگاه داده ی تحلیلی گفته می شود.پایگاه‌داده‌ی تحلیلی چیست؟پایگاه‌داده‌ی تحلیلی یک پایگاه داده ی مجزاست که به تحلیل گران این امکان را می دهد که پرس‌و‌جوهای خود را اجرا کنند بدون اینکه سامانه های OLTP را تحت تأثیر قرار دهند. فلسفه ی وجودی پایگاه‌داده‌ی تحلیلی از آن جا می آید که سامانه های OLTP می بایست دسترس پذیری بالا و تاخیر کم داشته باشند همچنین برای نیاز های مختلف پایگاه داده های متفاوتی وجود دارد (مثلا بخش فروش بخش بازاریابی و بخش نظرات یک سایت فروش آنلاین را در نظر بگیرید) قبل از وجود پایگاه‌داده‌ی تحلیلی تحلیل گران می رفتند و پرس‌و‌جو های خود را به صورت ad-hoc روی سامانه های OLTP اجرا می‌کردند و تعداد زیادی رکورد را درگیر محاسبات و پردازش می‌کردند که باعث آسیب رسیدن به کارایی آن سامانه ها می‌شد بنابر این پایگاه‌داده‌ی تحلیلی به وجود آمد که مستقل از سامانه ی OLTP به نیاز های تحلیل‌گران پاسخ دهد بدون اینکه تاثیر منفی روی سامانه ی OLTP بگذارد.پایگاه‌داده‌ی تحلیلی شامل کپی فقط خواندنی همه ی داده هایی است که در سامانه ی OLTP وجود دارد. در واقع داده ها از سامانه ی OLTP اسخراج می شود و در پایگاه‌داده‌ی تحلیلی ذخیره می گردد. معمولا از طریق عملیات استخراج، تبدیل کردن و بارگذاری‌ یا به اختصار ETL این کار انجام می شود.ارتباط بین سامانه های OLTP و OLAP و پایگاه‌داده‌ی تحلیلیاز دیدگاه ناظر بیرونی پایگاه‌داده‌ی تحلیلی و سامانه های OLTP شبیه به هم هستند و همگی دارای پشتیبانی از SQL به عنوان زبان اجرای پرس‌و‌جوها هستند اما از نظر معماری داخلی تفاوت های مهمی دارند چون برای انواع مختلفی از الگو های اجرا و دسترسی به پرس‌و‌جو پیاده سازی شده اند. ممکن است برخی از توسعه‌دهندگان سامانه‌های پایگاه داده بخواهند ازیکی یا هر دو در یک سامانه ی یکپارچه استفاده بکنند. مثلا برخی از پایگاه‌های داده تجاری مثل Microsoft SQL Server و SAP HANA از هردو سامانه پشتیبانی می کنند. از جمله پایگاه‌داده‌های تحلیلی متن‌باز می‌توان به موارد زیر اشاره کرد:Apache HiveSpark SQLCloudera ImpalaFacebook PrestoApache TajoApache DrillApache Druidبیشتر این پایگاه‌داده‌های تحلیلی متن‌باز از Google’s Dremel ایده گرفته اند.جدول زیرخلاصه ای از تفاوت بین سامانه های OALP و OLTP است:تفاوت های سامانه های OLAP و OLTPمنابعhttps://towardsdatascience.com/oltp-vs-olap-9ac334baa370Kleppmann, Martin - Designing data-intensive applications_ the big ideas behind reliable, scalable, and maintainable systems-O'Reilly Media (2018)سعی کردم توی این نوشتار به طور خلاصه در مورد تفاوت بین OLAP وOLTP توضیحاتی بگم این اصطلاحات رو ممکنه وقتی درباره‌ی کلان‌داده یا مهندسی‌داده یا مطالب مرتبط با داده مقالاتی می خونید ببینید همچنین خوشحال میشم اگر نقد یا توضیحات تکمیلی در مورد این پست دارید در بخش نظرات برام بنویسید یا به آدرس ایمیلم mhhajivandy@gmail.com ارسال کنید.

انواع ساعت در سیستم های کامپیوتری

محمد حسین حاجی وندی — Fri, 22 Jul 2022 23:30:14 +0430

تا حالا به مفهوم زمان یا ساعت یا تایمر در سامانه های کامپیوتری فکر کردید؟. به عنوان مثال هر عملیاتی که در یک پایگاه داده انجام می شود در یک زمان معین اتفاق می افتد.دانستن این زمان که به timestamp معروف است، برای توسعه دهندگان مهم است یا مثلا به زمانی که طول می کشد کل عملیات انجام شود زمان سپری شده (elapsed time) می گویند. فرق این ها چیست؟ در این مطلب کوتاه سعی کردم تفاوت این مفاهیم را روشن کنم.سیستم های کامپیوتری حداقل یکی از این مدل های مختلف ساعت را دارند:مدل زمان از روز (time-of-day clock)مدل ساعتِ یکنواخت (monotonic clock)در ادامه هر یک از انواع ساعت را توضیح می دهم:مدل زمان از روز (time-of-day clock)مدل زمان از روز یا ساعت دیواری (wall-clock time) همان چیزی است که به طور شهودی از یک ساعت انتظار دارید. این ساعت زمان حاضر را بر اساس یک تقویم برمی گرداند. برای مثال در لینوکس تابع زیر زمان epoch را برمی گرداند: clock_gettime(CLOCK_REALTIME)معادل آن در جاوا به صورت زیر است: System.currentTimeMillis() هر دو این توابع ثانیه یا میلی ثانیه از زمان epoch برمی گرداند. که در واقع یک قرارداد است و به مبدا زمانی ثانیه 0 دقیقه 0 روز اول ژانویه 1970 میلادی بر اساس UTC اشاره می کند.برخی از سیستم ها از زمان هایی با مبدا های متفاوت پشتیبانی می کنند.مدل ساعتِ یکنواخت (monotonic clock)این ساعت فارغ از اینکه مبدا زمانی چیست همیشه به جلو حرکت می کند علت نامگذاری آن هم همین است. این مدل ساعت برای اندازه گیری مدت زمان سپری شده مناسب است چون تضیمن شده است که همیشه به جلو حرکت می کنند.این ساعت با این هدف طراحی شده است که در یک زمان مقدار آن بررسی شود و یک کاری انجام شود و دوباره مقدار ساعت چک شود. تفاوت دو مقدار ساعت زمان سپری شده را نشان میدهد. اگرچه مقدار ساعت به تنهایی ممکن است بی معنا باشد. مثلا زمان پاسخ دهی (response time) یک سرویس را می توان با استفاده از ساعت یکنواخت بدست آورد.در لینوکس clock_gettime(CLOCK_MONOTONIC)و در جاوا System.nanoTime() ساعت یکنواخت را برمی گردانند.جالبه بدانید یکی از چالش های کار کردن با سیستم های توزیع شده هماهنگ کردن (Synchronization) ساعت های آن ها با هم است. بنابه تعریف ساعت یکنواخت نیازی به هماهنگ سازی ندارد اما ساعت زمان از روز باید بر اساس پروتکل NTP بین سیستم های مختلف هماهنگ شود.با این حال متاستفانه راه حل قابل اعتماد و دقیقی برای اینکار وجود ندارد و حتی استفاده از پروتکل NTPهم عدم اختلاف بین ساعت های مختلف را تضمین نمی کند!

مقایسه ی Apache Thrift و Protocol Buffers و Apache Avro

محمد حسین حاجی وندی — Tue, 19 Jul 2022 22:20:08 +0430

این مقاله که در واقع ترجمه و ترکیب چنتا مقاله است که اخیرا خوندم سعی کردم تفاوت هرکدوم از پروتوکل های سریالایز کردن داده ها رو توضیح بدم و تمرکزم هم بیشتر روی سازگاری رو به جلو یا forward compatibility و سازگاری رو به عقب یا backward compatibility بوده است.تصویر کدگذاری شدهبرای ذخیره سازی یا انتقال داده ها در شبکه راه حل های مختلفی پیشنهاد می شود:استفاده از امکانات زبان برنامه نویسی برای سریالایز کردن داده مثل serialization در Java یا marshal زبان Ruby یا pickle برای Pythonاستفاده از فرمت های متنی مثل JSON یا XMLاستفاده از فرمت های باینری BSON یا BJSON و …استفاده از پروتوکل هایی مثل Apache Thrift و Protocol Buffers یا Apache Avroهرکدام از این روش ها معایب و مزایای خاص خود را دارد. در صورتی که از امکانات زبان برنامه نویسی بخواهید استفاده کنید در این صورت موقع خواندن داده ، مجبورید از همان زبان برنامه نویسی استفاده کنید.استفاده از JSON وXML با اینکه خیلی پر طرفدار است و تقریبا همه ی زبان های برنامه نویسی از آنها پشتیبانی میکنند، معایبی هم دارند. از جمله اینکه ابهامات زیادی حول سریالایز کردن اعداد در این فرمت ها وجود دارد. مثلا در XML یا CSV هیچ تفاوتی بین اعداد و رشته ها وجود ندارد یا در JSON نمی توانید تفکیکی بین اعداد صحیح و اعشار قائل شوید یا مثلا دقت خاصی را روی اعداد اعشاری اعمال کنید. (منظور این است که در فرآیند سریالایز و دی سریالایز کردن این اتفاق بیفتد چاره ی کار این است که در کد برنامه این موارد را در نظر بگیرید ولی این باعث پیچیدگی کد می شود!)همچنین اگر داده ای که می خواهید سریالایز کنید زیاد باشد استفاده از فرمت های متنی باعث کندی و سربار حافظه می شود.برای برطرف شدن این مشکل راه حل سوم پیشنهاد می شود. به جای اینکه داده ها را به صورت متنی ذخیره کنید آن ها را به صورت باینری ذخیره کنید. اما استفاده از فرمت های باینری هم نمی تواند شما را راضی کند چرا؟ چون هیچ اسکیما و مستندی ندارد که شما بتوانید بر اساس آن اشیا و کلاس ها را بسازید. مخصوصا اگر از زبان های برنامه نویسی نوع ایستا استفاده می کنید. همچنین درست است که فرم باینری JSON حجم کمتری از فرم متنی در حافظه می گیرد اما هنوز هم می توان با حذف نام فیلد ها که بسیار تکرار می شود حافظه ی کمتری اشغال کرد.پس به سراغ استفاده از پروتکل هایی مثل Apache Thrift و Protocol Buffers یا Apache Avro می رویم. این پروتکل ها برای توصیف داده ها از زبان توصیف اسکیما استفاده می کنند. همچنین داده ها را به صورت باینری در حافظه ذخیره می کنند.طوری که در مصرف حافظه بهینه باشد و امکانات چند سکویی را برای سریالایز کردن و دسریالایز کردن داده ها در اختیار کاربران قرار می دهند.اما سوال اصلی اینجاست که کدام پروتوکل بهترین انتخاب است؟در ادامه ی این مقاله نگاهی نزدیک تر به هر یک از این سه پروتکل می اندازیم و ویژگی هایشان را باهم مقایسه می کنیم.معرفی Apache ThriftApache Thrift ابتدا در فیسبوک ایجاد شد و هدف از ساخت آن نه فقط فراهم آوردن ویژگی هایی که گفته شد برای سریالایز کردن داده ها بلکه توسعه ی یک چارچوب کامل RPC بود.برای همین Apache Thrift مجموعه ای از پروتکل ها را در اختیار توسعه دهنده ها قرار می دهد. مثلا 2 نوع متفاوت کدگزاری JSON دارد و 3 نوع پروتوکل کدگزاری باینری دارد البته پروتکل DenseProtocol فقط برای زبان ++C پیاده سازی شده است. همه ی پروتکل های کدگذاری از یک زبان مشترک به نام Thrift IDL برای تعریف اسکیما استفاده می کنند مثلا اسکیمای Person به صورت زیر تعریف می شود:struct Person { 1: string userName, 2: optional i64 favouriteNumber, 3: list interests }Apache Thrift برای ذخیره کردن داده ها به هر یک از فیلد ها یک تگ اختصاص می دهد و هر تگ و داده ی مربوط به آن به صورت باینری در حاظفه ذخیره می شود که این امکان را به پارسر می دهد که در صورتی که فیلد ناشناخته بود از روی آن عبور کند.کدگذاری BinaryProtocol خیلی سرراست است اما نسبتا حافظه را به هدر میدهد. برای ذخیره کردن مثال Person در حافظه 59 بایت فضا اشغال می کند.BinaryProtocol مثال داده ی کدگذاری شد تحت پروتکل کدگذاری CompactProtocol تقریبا مشابه BinaryProtocol اما چون از اعداد صحیح با طول متغیر و bit packing استفاده می کند حجم کمتری از حافظه را اشغال می کند.CompactProtocol داده ی کدگذاری شد تحت پروتکل پروتوکل بافرز یا پروتوبافلوگوی گوگل پروتوبافپروتکل بافر فرمت داده ای متن باز و چند سکویی است که توسط گوگل توسعه پیدا کرده است. مانند Thrift زبان توصیف اسکیمای مختص خودش را دارد و برای مثال Person به صورت زیر است:message Person { required string user_name = 1; optional int64 favourite_number = 2; repeated string interests = 3; }وقتی که مثال بالا در حاظفه ذخیره شود فقط 33 بایت حافظه اشغال می کند:کدگذاری پروتوباف برخلاف Thrift پروتکل بافر از لیست پشتیبانی نمی کند. برای تعریف فیلد های تکرار پذیر در اسکیما از کلمه ی repeated استفاده می شود. بین فیلد های required و optional و repeated فرقی در پروتوباف وجود ندارد یعنی شما می توانید یک فیلد را از optional به required تغییر بدهید فقط ممکن است موقع پارس کردن داده به خطای موقع اجرا برخورد کنید. مثلا زمانی که ارسال کننده تصور کند فیلد مذکور optional است اما دریافت کننده ی داده فیلد را required ببیند.فیلد optional بدون مقدار یا فیلد repeated بدون هیچ مقداری در داده ی رمزگذاری شده آورده نمی شود. در این صورت ممکن است توسعه دهنده ی اسکیما بخواهد آن را حذف کند فقط نکته ای که در اینجا وجود دارد این است که بهتر است از شماره ی تگ آن استفاده نشود چون ممکن است داده ی ذخیره شده ای وجود داشته باشد که دارای تگی باشد که حذف شده است و استفاده از همان تگ برای یک فیلد دیگر امن نیست.اگر شما بخواهید فیلد جدیدی به اسکیما اضافه کنید از منظر سازگاری با کد های قدیمی چه اتفاقی می افتد؟خوشبختانه مهندسانی که این قرارداد ها را طراحی کردن دقیقا به سازگاری قدیم و جدید توجه کردند. مثلا در پروتوباف اگر فیلد جدید با تگ جدید به اسکیما اضافه شود. پارسر قدیمی آن فیلد را نادیده می گیرد. پارسر قدیمی نمی داند که آن فیلد چیست اما با توجه به اینکه بایت اول آن فیلد نمایانگر اندازه ی داده ی مرتبط با همان فیلد است تشخیص می دهد که از روی چند بایت بعدی باید پرش کند.با توجه به اینکه پروتوباف و Thrift از شماره ی تگ برای ذخیره کردن داده ها استفاده می کنند شما میتوانید نام فیلد را در اسکیما تغییر دهید.و اما Apache Avro توسعه ی Apache Avro از سال 2009 به عنوان یکی از زیر پروژه های Apache Hadoop شروع شد. Avro برای توصیف ساختارِ داده از اسکیما استفاده میکند و دارای دو زبان توصیف اسکیما است یکی برای راحتی ویرایش که Avro IDL نام دارد دیگری هم بر اساس JSON است.لوگوی پروژه ی Apache Avroمثال Person در زبان Avro IDL به صورت زیر است:record Person { string userName; union { null, long } favouriteNumber; array interests; }بازنمایی همین مثال به صورت JSON به شکل زیر می باشد:{ "type": "record", "name": "Person", "fields": [ {"name": "userName", "type": "string"}, {"name": "favouriteNumber", "type": ["null", "long"]}, {"name": "interests", "type": {"type": "array", "items": "string"}} ] }وقتی در حافظه ذخیره شود تنها در 32 بایت فضا اشغال می کند.مثال داده ی کدگذاری شد در Avroدر Avro هر فیلد شامل یک بایت اندازه وچند بایت داده است.هیچ چیزی وجود ندارد که مشخص کند یک فیلد string است هم زمان می تواند عدد صحیح یا یک ساختار دیگر باشد. برخلاف پروتوباف یا Thrift هیچ تگی درکار نیست. تنها راهی که بتوان داده را به درستی پارس کرد داشتن اسکیماست. برای خواندن داده دقیقا به همان نسخه ای از اسکیما نیاز است که نویسنده داده را کدگذاری کرده است.در Avro هر فیلدی یکی پس از دیگری می آید و با توجه به اینکه هیچی تگی درکار نیست پارسر نمیتواند تشخصی دهد که کدام فیلد اختیاری است که از روی آن پرش کند. تنها راهی که وجود دارد استفاده از چیزی شبیه به این موقع تعریف اسکیما است:union { null, long }در این صورت پارسر با رسیدن به null می فهمد که باید از آن فیلد پرش کرد.چه نکاتی را هنگام تغییر در اسکیما در Avro باید رعایت کرد؟وقتی می خواهید یک مقدار جدید به union اضافه کنید ابتدا نسخه ی همه ی reader ها را به روز رسانی کنید سپس با استفاده از writer داده جدید تولید کنیدشما می توانید ترتیب فیلد ها را در اسکیما عوض کنید. فیلد ها بر اساس ترتیبی که در اسکیما نوشته می شود کدگذاری شده و خوانده می شود.چون فیلد ها بر اساس نامشان با هم مطابقت پیدا می کنند تغییر نام فیلد ها باید با احتیاط انجام شود. اول باید نام فیلد ها در اسکیمای خواننده ها به روزرسانی شود درحالی که نام های قدیمی به عنوان نام مستعار باقی بمانند. سپس نام های جدید در اسکیمای نویسنده اعمال شود.درصورتی که فیلد جدید به اسکیما افزوده می شود از نوع union باشد که قبلا معرفی شد و مقدار پیشفرض هم داشته باشد زیرا درصوتی که بخواهد داده ی قدیمی هم بخواند فیلد جدید را با مقدار پیشفرض پر کند.با توجه به اینکه تغییرات زیادی در اسکیما ممکن است رخ بدهد بهتر است با داشتن یک مخزن اسکیما نسخه های مختلف اسکیما در دسترس سرویس ها قرار بگیرد.یکی از مزایای Avro نسبت به پروتوباف و Thrift این است که هنگام ذخیره ی رکورد در حافظه شماره ی تگ در کار نیست اما این چه اهمیتی دارد؟ چون اسکیمای Avro را میتوان به صورت پویا تولید کرد.مثلا فرض کنید که شما می خواهید داده های پایگاه داده را منتقل کنید و برای اینکه در حافظه صرفه جویی کنید نمی خواهید از فرمت های متنی مثل CSV, JOSNو… استفاده کنید و می خواهید از Avro استفاده کنید. به راحتی می توانید اسکیمای Avro را در قالب JOSN از اسکیمای پایگاه داده تولید کنید و داده های پایگاه داده را به فرمت باینری تبدیل کنید. حالا اگر اسکیمای پایگاه داده تغییر کند اسکیمای جدید Avro جایگزین می شود، بدون اینکه تغییری در فرآیند استخراج داده از پایگاه داده رخ دهد.درمقایسه با استفاده از پروتوباف یا Thrift برای همین منظور هر بار که پایگاه داده تغییر می کرد، لازم است شماره ی تگ جدید به صورت دستی تخصیص داده شود.جمع بندیپروتکل های کدگذاری داده ها با این هدف طراحی شدند که هم در میزان مصرف حاظفه صرفه جویی شود هم با دراختیار قرار دادن امکانات مختلف به توسعه دهندگان اطمینان بدهند که در آینده اگر تغییراتی در اسکیما رخ داد، می توانند داده های قدیمی خود را هم بدون مشکل بخوانند. اگر چه راحتی استفاده از این امکانات در ابزار های مختلف متفاوت است. همانطور که در این مقاله اشاره شد استفاده از Thrift و پروتوباف در مقابل Avro سرراست تر است اما برخی مواقع نیازمند پویایی بیشتری هستیم که Avro در اختیار توسعه دهندگان قرار می دهد.منابع مورد استفاده برای نوشتن این مقاله به شرح زیر است: https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.htmlhttp://radar.oreilly.com/2014/11/the-problem-of-managing-schemas.htmlhttps://www.confluent.io/en-gb/blog/avro-kafka-data/

10 اشتباه رایج در استفاده از Apache Cassandra

محمد حسین حاجی وندی — Wed, 06 Jul 2022 10:50:38 +0430

آپاچی کسندرا (Apache Cassandra) یک سیستم مدیریت پایگاه داده ی NoSQL متن باز است با ویژگی های مهمی از قبیل مقیاس پذیری بالا، سرعت نوشتن زیاد، سازگاری قابل تنظیم (configurable consistency) و خطاپذیر (fault tolerant) که میتواند روی هزاران ماشین معمولی اجرا شود و ده ها پتابایت دیتا را نگهداری کند.من حدود 3 سالی می شود که با پایگاه داده ی کسندرا سر و کار دارم و وقتی این مقاله را خواندم با خودم گفتم که خلاصه ی آن را با شما به اشتراک بگذارم.لوگو کسندرا به همراه دلایل محبوبیت!اشتباه #1: چون کسندرا برای بقیه کار می کند پس برای من هم کار می کند!این یک اشتباه رایج است که بخواهیم بدون شناخت یک ابزار ازش استفاده کنیم ممکن است که شرکت های معتبر و معروف از کسندرا به عنوان پایگاه داده استفاده کنند اما در عمل این اتفاق به ما مجوز نمی دهد که از آن به عنوان پایگاه داده برای هر چیزی استفاده کنیم. در مرحله اول باید بررسی کنیم که نیازمندی ما چیست مثلا اگر داده ها باید در بازه زمانی کوتاهی پس از درج پاک شوند استفاده از کسندرا مناسب نیست.اشتباه #2: پیاده سازی را از روی مدل داده (data model) شروع کنیماینکه پیاده سازی را از روی مدل داده شروع کنیم یک روش عمومی برای پیاده سازی پایگاه داده برای انواع سامانه ها است اما در مورد کسندرا اوضاع کمی متفاوت است و همیشه برای ساخت مدل داده برای کسندرا باید از پرس و جو (query) شروع کنید.اشتباه #3: بر اساس هر چیزی که توی کسندرا ذخیره کردیم میتونیم جست و جو کنیم.خیر. این هم یک اشتباه رایج است. درسته که می تونیم برای جدول کسندرا ستون های مختلف تعریف کنیم اما پرس و جو ها باید براساس کلید پارتیشن (partition key) و کلید کلاستر (cluster key) باشند و اگرستونی کلید پارتیشن نباشد و فقط کلید کلاستر نمیتواند به تنهایی به عنوان بخش شرطی پرس و جو استفاده شود و ستونی که کلید پارتیشن یا کلاستر نباشد نمی تواند در بخش شرطی پرس و جو بیاید.اشتباه #4: اضافه کردن ستون جدید که براساس ترکیبی از ستون های موجود ساخته شده باشد.عملیات ترکیب ستون ها برای ساختن ستون جدید در SQL وجود دارد و اجرا می شود اما با توجه به اینکه کسندرا اجازه ی عملیات های غیر بهینه را نمی دهد. اینگونه عملیات ها در کسندرا مجاز نیست.اشتباه #5: انتخاب سخت افزار اشتباهبا توجه به اینکه کسندرا برای عملیات نوشتن و خواندن سریع بهینه شده است استفاده از دیسک کند باعث کاهش کارایی می شود. همچنین با توجه به اینکه عملیات کامپکشن (Compaction) (تجمیع sstable ها و پاک کردن کلید های تکراری) نیازمند منابع پردازشی و حافظه است استفاده از CPU های ضعیف یا RAM کم باعث کندی کامپکشن می شود. از طرف دیگر تخصیص حجم زیاد RAM باعث افزایش زمان گاربج کالکشن (garbage collection) می شود. بنابراین پیشنهاد می شود که منابع پردازشی بین گره های بیشتر توزیع شده باشد تا اینکه تعداد گره ها کم باشد با CPU و RAM زیاد.اشتباه #6: عدم توجه به مانیتورینگ و نگهداری سامانهکسندرا به نداشتن نقطه ی شکست واحد (single point of failure) معروف است یعنی یعنی مثلا اگر فاکتور رونوشت (replication factor) برابر 3 باشد و تعداد گره ها 4 تا باشد با پایین آمدن یک گره مشکلی برای کلاستر کسندرا ایجاد نمی شود و کسندرا با فراهم کردن مکانیزم هایی پس از بالا آمدن گره مذکور داده های مربوط به آن گره را روی آن می نویسد. اما نمی توان بدون داشتن مانیتورینگ و پایش به عملکرد آن اطمینان کرد. مخصوصا هنگام پاک کردن داده باید حواسمان به زیاد شدن زامبی ها باشد(منظور از زامبی داده هایی است که انتظار داشتیم پاک شده باشند اما نشدند!) و حداقل هر 7 روز یکبار عملیات تعمیر (repair) را انجام دهیم! (بعدا در یک پست جداگانه این اتفاق را با شرح جزییات بررسی میکنیم!)اشتباه #7: استفاده از کسندرا به عنوان صفاگر نیازمندی شما این است که چندین task با کار معین ولی کوتاه داشته باشید و ردیف ها (row) در پایگاه داده درج شوند و سپس پاک شوند و کسندرا برای شما مناسب نیست چون داده های کسندرا در sstable ذخیره می شود و sstable فایل های تغییر ناپذیر است و پاک کردن از sstable در فرآیند compaction اتفاق می افتد. انجام شدن عملیات کامپکشن هم به CPU و RAM وابسته است و ممکن است زمان طولانی از سیستم بگیرد. پس از کامپکشن هم تضمینی وجود ندارد که ردیف های مورد نظر پاک شده باشد.اشتباه #8: کسندرا به عنوان موتور جستجوبا توجه به اینکه برای ساختن مدل داده باید پرس و جو از قبل مشخص باشد استفاده از کسندرا به عنوان موتور جست و جو که بتواند انواع مختلفی از جست و جو ها را پیاده کند سخت و غیر بهینه است.اشتباه #9: استفاده از load balancer خارجیمعماری کسندرا به گونه ای است که بار را بین گره های مختلف تقسیم می کند و استفاده از متوازن کننده ی بار (load balancer) خارجی ریسک وحود نقطه ی شکست واحد را به همراه دارد.اشتباه #10: استفاده از کسندرا به عنوان filestoreهر ردیفی که در یک جدول کسندرا ذخیره می شود دارای محدودیت حجمی 2 گیگابایتی است که باعث می شود برای ذخیره ی برخی از فایل ها مجبور شویم آن ها را به تکه های کوچکتر تقسیم کنیم و باعث کاهش کارایی خواندن و نوشتن می شود.جمع بندیبرای استفاده از کسندرا باید نیازمندی های پروژه به دقت بررسی شود. پرس و جو ها را استخراج کرد و بر اساس آن ها مدل داده را طراحی نمود. در استفاده از کسندرا باید از دیسک های پرحجم یا پاک کردن ردیف اجتناب کرد. پایش و نگهداری کلاستر کسندار فراموش نشود. درمجموع انتخاب کسندرا باید با درایت و توجه به تمام ابعاد پروژه و امکانات دردسترس انجام شود. درمواردی که نیازمندی شما نگهداری حجم عظیمی از داده و سپس جست و جو بر اساس پرس و جو های از پیش تعیین شده است کسندرا جزو بهترین انتخاب های شما خواهد بود.?امیدوارم که این مطلب به کارتون بیاد و خوشحال می شوم نظرات و پیشنهادات یا اصلاحات کم و کاستی های این مطلب رو بهم زیر همین پست یا به آدرس ایمیلم mhhajivandy@gmail.com اطلاع بدین.

حل مشکل compile نشدن کرنل ماژول های VMware Workstation [به روز رسانی اردیبهشت ۰۱]

محمد حسین حاجی وندی — Mon, 18 Apr 2022 00:45:35 +0430

اگر ازون دسته آدمایی هستین که به یک سری ابزار های خاص عادت کردین و تحت هر شرایطی می خواین با همون ها کار کنید احتمالا به مشکلی که تو عنوان این نوشته اومده بر خورده باشین. من خودم چندین بار تو توزیع های مختلف لینوکس به این مشکل برخوردم حتی بعد از به روز رسانی کرنل لینوکس هم هربار با این مشکل مواجه شدم. برای همین هم اینجا مستندش می کنم که دوستانی که دنبال راه حل سرراست میگردند کارشون راه بیافته و منم دعا کنن.?اول باید مطمئن بشین که ماژول های کرنل vmware workstation که شامل چندین ماژول از جمله vmmon ٬ vmnet و ... هست کامپایل نمیشه. برنامه ی vmware workstation برای اولین بار بازکنید تا پنجره ی نصب ماژول های کرنل رو بهتون نشون بده یا با زدن دستور زیر می تونید چک کنید:sudo vmware-modconfig --console --install-allخروجی دستور بالا یه چیزی مثل شکل زیر شامل خطا خواهد بود:خطا در نصب کرنل ماژول ها خب راه حل خیلی ساده است و یه بنده خدایی سورس این ماژول ها رو برامون اینجا گذاشته پس با استفاده از git اون رو clone می کنیم و روی سیستممون میسازیمش:git clone https://github.com/mkubecek/vmware-host-modules.git cd vmware-host-modules git checkout workstation-16.1.2 //بسته به نسخه ای ای که استفاده می کنیدmake sudo make installو در نهایت سرویس vmware رو راه اندازی مجدد میکنیم:sudo systemctl restart vmware.serviceو vmware workstation مثل آدم اجرا میشه!اگر Secure Boot توی سیستم شما فعال باشه بازم ممکنه vmware workstation اجرا نشه برای برطرف کردن این مشکل شما یا میتونید از طریق تنظیمات BIOS اون -منظورم Secure Boot هست- رو غیر فعال کنید یا اگر به هر دلیلی قصد ندارید غیرفعالش کنید به روش زیر باید ماژول های کرنل رو امضا کنید که در ادامه توضیح میدم.اول پیشنیاز های امضا کردن ماژول کرنل رو نصب کنید.sudo apt install opensslبرای امضا کردن ماژول کرنل نیاز به کلید RSA داریم که با زدن دستور زیر ساخته میشن(کلمه ی MOK رو با اسمی که میخواید برای کلیدتون بگذارید جایگزین کنید):sudo openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=VMware/"با استفاده از دستورات زیر ماژول ها رو امضا کنید:sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)با ابزار mokutil کلید عمومی رو وارد کنید(احتمالا تو این مرحله یه رمز عبور دلخواه هم باید تنظیم کنید):sudo mokutil --import MOK.derدر نهایت سیستم رو ریست کنید و هنگام بالا اومدن سیستم رمز عبوری که تو مرحله ی قبل وارد کردید رو برنید تا امضا تایید بشه و سیستم عامل بالا بیاد و این دفعه امیدوارم بتونید vmware workstation رو اجرا کنید.البته تهشم اگر اجرا نشد می تونید از gnome boxes و kvm یا Oracle virtualbox استفاده کنید:)