NOSQL قسمت سوم
در مطلب قبلی با نوع اول پایگاههایداده NoSQL یعنی Key/Value Store آشنا شدیم و در این مطلب به معرفی دسته دوم یعنی Document Database خواهیم پرداخت.
در این نوع پایگاه داده ، دادهها مانند نوع اول در قالب
کلید/مقدار ذخیره میشوند و بازگردانی مقادیر نیز دقیقا مشابه نوع اول یعنی Key/Value Store بر اساس کلید میباشد. اما
تفاوت این سیستم با نوع اول در دستهبندی دادههای مرتبط با یکدیگر در قالب یک Document میباشد. سعی کردم در این مطلب با ذکر مثال مطالب را شفافتر بیان کنم:
به عنوان مثال اگر بخواهیم جداول مربوط به پستهای یک سیستم CMS را بصورت رابطهای پیاده کنیم ، یکی از سادهترین حالات پایه برای پستهای این سیستم در حالت نرمال به صورت زیر میباشد.
جداول واضح بوده و نیازی به توضیح ندارد ، حال نحوهی ذخیرهسازی دادهها در سیستم Document Database برای چنین مثالی را بررسی میکنیم:
{ _id: ObjectID(‘4bf9e8e17cef4644108761bb’), Title: ‘NoSQL Part3’, url: ‘https://www.dntips.ir/yyy/xxxx’, author: ‘hamid samani’, tags: [‘databases’,’mongoDB’], comments:[ {user: ‘unknown user’, text:’unknown test’ }, {user:unknown user2’, text:’unknown text2 } ] }
همانگونه که مشاهد میکنید نحوهی ذخیرهسازی دادهها بسیار با سیستم رابطهای متفاوت میباشد ، با جمعبندی تفاوت نحوهی نگهداری دادهها در این سیستم و RDBMS و بررسی این سیستم نکات اصلی به شرح زیر میباشند:
۱-فرمت ذخیره سازی دادهها مشابه فرمت JSON میباشد.
۲-به مجموعه دادههای مرتبط به یکدیگر Document گفته میشود.
۳-در این سیستم JOIN ها وجود ندارند و دادههای مرتبط کنار یکدیگر قرار میگیرند ، و یا به تعریف دقیقتر دادهها در یک داکیومنت اصلی Embed میشوند.
به عنوان مثال در اینجا مقدار commentها برابر با آرایهای از Documentها میباشد.
۴-مقادیر میتوانند بصورت آرایه نیز در نظر گرفته شوند.
۵-در سیستمهای RDBMS در صورتی که بخواهیم از وجود JOINها صرفنظر کنیم. به عدم توانایی در نرمالسازی برخواهیم خورد که یکی از معایب عدم نرمالسازی وجود مقادیر Null در جداول میباشد؛ اما در این سیستم به دلیل Schema free بودن میتوان ساختارهای متفاوت برای Documentها در نظر گرفت.
به عنوان مثال برای یک پست میتوان مقدار n کامنت تعریف کرد و برای پست دیگر هیچ کامنتی تعریف نکرد.
۶-در این سیستم اصولا نیازی به تعریف ساختار از قبل موجود
نمیباشد و به محض اعلان دستور قرار دادن دادهها در پایگاهداده ساختار متناسب
ایجاد میشود.
با مقایسه دستورات CRUD در هر دو نوع پایگاه داده با نحوهی کوئری گرفتن از Document Database آشنا میشویم:
در SQL برای ایجاد جدول خواهیم داشت:
CREATE TABLE posts ( id INT NOT NULL AUTO_INCREMENT, author_id INT NOT NULL, url VARCHAR(50), PRIMARY KEY (id) )
دستور فوق در Document Database معادل است با:
db.posts.insert({id: “256” , author_id:”546”,url:"http://example.com/xxx"}) // با قرار دادن مقدار نوع ساختار مشخص میشود
در SQL جهت خواندن خواهیم داشت:
SELECT * from posts WHERE author_id > 100
db.posts.find({author_id:{$gt:”1000”}})
در SQL جهت بروزرسانی داریم:
UPDATE posts SET author_id= "123"
db.posts.update({ $set: { author_id: "123" }})
در SQL جهت حذف خواهیم داشت:
DELETE FROM posts WHERE author_id= "654"
که معادل است با:
db.posts.remove( { author_id: "654" } )
همانگونه که مشاهده میفرمایید نوشتن کوئری برای این پایگاه داده ساده بوده و زبان آن نیز بر پایه جاوا اسکریپت میباشد که برای اکثر برنامهنویسان قابل درک است.
تاکنون توسط شرکتهای مختلف پیادهسازیهای مختلفی از این سیستم انجام شده است که از مهمترین و پر استفادهترین آنها میتوان به موارد زیر اشاره کرد:
کتاب معرفی SQL Server 2016
Chapter one: Faster queries
Chapter two: Better security
Chapter three: Higher availability
Chapter four: Improved database engine
Chapter five: Broader data access
Chapter six: More analytics
Chapter seven: Better reporting
Chapter eight: Improved Azure SQL Database
Chapter nine: Expanding your options with Azure SQL Data Warehouse
• Crystal Report
• Stimul Report
• Telerik Reporting
• …
در ادامه این سری آموزشها قصد داریم Telerik Reporting و نحوه تهیه گزارش با آن را مورد بررسی قرار دهیم. این ابزار امکانات بسیاری در خصوص تهیه گزارش برنامههای دات نتی نظیر Windows Form ، Asp.net و ... در اختیار ما قرار میدهد.در ادامه و برای شروع ، ساخت یک گزارش ساده در این محیط را بررسی میکنیم.
نکته : گزارشاتی که توسط Telerik Reporting تهیه میشوند به وسیله کدهای C# جنریت میشوند.بنابراین همیشه توصیه میشود گزارشات خود را درون یک یا چند پروژه Class Library قرار دهیم و از این پس ، این گزارشات از درون پروژههای دیگر (ویندوزی ، وب و ...) در دسترس هستند.کافی ست پروژه Class Library را به عنوان Reference به پروژه مورد نظر خود اضافه کنیم.. برای شروع میتوان یک پروژه جدید از نوع Class Library ایجاد کرد.پس از آن روی نام پروژه راست کلیک کنید و گزینه Telerik Report را انتخاب نمایید.پس از تعیین نام گزارش کلید Ok را کلیک نمایید.
در این حالت فایل گزارش به پروژه افزوده میشود. در ادامه میتوانید توسط ویزاردی که نمایش داده میشود کارهای عمومی مربوط به پیاده سازی گزارش (انتخاب منبع داده(Data Source) ، ساخت Query جهت بارگذاری اطلاعات ، فیلدهایی که باید نمایش داده شوند ، گروه بندی دادهها و ...) را توسط این ویزارد انجام دهید. برای اینکار در پنجره ای که نمایش داده میشود بر روی کلید Next کلیک نمایید.
جهت ایجاد یک گزارش جدید در پنجره Report Choose Page گزینه New Report را انتخاب نموده و کلید Next را کلیک نمایید.
جهت انتخاب منبع داده گزارش در پنجره Choose Data Source گزینه Add New Data Source را انتخاب نمایید.در این حالت میتوانید گزینههای متفاوتی را به عنوان منبع داده گزارش خود انتخاب نمایید. گزینههای نمایش داده شده به شرح ذیل است:
• Sql Data Source : جهت اتصال مستقیم به بانک اطلاعات Microsoft Sql Server
• Object Data Source : جهت اتصال به کلاسهای لایه Business و بارگذاری داده از این کلاس ها
• Entity Data Source : جهت اتصال به Entity Framework
• Open Access Data Source : جهت اتصال به Open Access ORM ساخت شرکت Telerik
• Cube Data Source : جهت اتصال و نمایش دادههای تحلیل شده
در ادامه برای اینکه بتوان مستقیما به Sql Server وصل شد و Queryهای مربوط به گزارش را روی آن اجرا نمود؛ میتوان گزینه Sql Data Source را انتخاب نمود و بر روی کلید Ok کلیک کرد.سپس در پنجره Choose Your Data Connection گزینه New Connection را کلیک کنید و یک اتصال به بانک مورد نظر خود ایجاد کنید.پس ایجاد و تست Connection ساخته شده روی Next کلیک کنید.در پنجره Save the connection string میتوان نامی را جهت Connection string انتخاب کرد تا Connection string با همان نام در فایل Config پروژه ذخیره شود.در ادامه کلید Next را کلیک کرده و وارد مرحله بعد شوید. در پنجره Configure Data Source Command گزینه Query Builder را جهت ساخت Query مورد نظر برای بارگذاری دادهها انتخاب نمایید.
پس از ساخت Query مورد نظر کلید Ok را کلیک نمایید. در پنجره Configure Data Source Command کوئری ساخته شده به شما نمایش داده میشود.کلید Next را کلیک کنید.
سپس وارد مرحله Preview Data Source Result میشوید که در آن قادر خواهید بود پیش نمایشی از داده هایی که بعدا توسط Query ساخته شده بارگذاری خواهند شد را مشاهده نمایید. Next را کلیک نموده تا وارد مرحله بعد شوید.مرحله بعد Standard Report Type میباشد که در این مرحله شما میتوانید نوع گزارش خود را انتخاب نمایید و کلید Next را فشار دهید.در بخش Design Data Layout چند فیلد را از بخش سمت چپ (Available Fields) انتخاب نموده و کلید Details را کلیک نمایید.فیلدهای انتخاب شده به بخش Details گزارش اضافه خواهند شد.در ادامه Next را کلیک کنید تا وارد بخش Choose Report Layout شوید.شما میتوانید در این بخش یک حالت نمایشی را برای گزارش خود انتخاب نمایید و Next را کلیک نمایید.در بخش Choose Report Style یک قالب بندی جهت گزارش خود انتخاب نمایید.در ادامه Next و سپس Finish را کلیک نمایید.کدهای گزارش Generate شده میتوان در قسمت Designer گزارش را مشاهده نمود.
در این حالت کارهای زیر توسط Wizard به صورت اتوماتیک انجام خواهد شد:
• بایند شدن اتوماتیک فیلدهای گزارش به ستوانهای مرتبط
• اعمال قالب بندی انتخاب شده برای صفحه و سر ستونها
• افزودن تاریخ و شماره صفحه به پایین گزارش
در ادامه پروژه را Rebuild کرده و گزینه Preview را در Designer جهت نمایش ، پیش نمایش گزارش کلیک نمایید.
• Report Header: مواردی که در این بخش از گزارش قرار میگیرند در بالای صفحه اول گزارش نمایش داده میشوند.
• Page Header: مواردی که در این بخش از گزارش قرار میگیرند در بالای همه صفحات گزارش قرار گرفته و تکرار میشوند.
• Details: دادههای اصلی گزارش که شامل جزئیات و بخش اصلی گزارش میباشند و سطر به سطر نیز تکرار میشوند در این بخش قرار میگیرند.
• Page Footer: مواردی که در این بخش از گزارش قرار میگیرند در پایین همه صفحات نمایش داده میشوند.
• Report Footer:مواردی که در این بخش قرار میگیرند در پایین صفحه آخر گزارش نمایش داده میشوند.
ادامه دارد ...
OData چهار قسمت اصلی دارد:
- OData data model که یک راه عمومی برای مدیریت و توصیف دادهها را فراهم مینماید
- OData protocol که به کلاینت اجازه ایجاد درخواست و پاسخ از سرویس دهنده OData را میدهد.
- OData client libraries که امکان ساخت سادهتر نرم افزارها برای دسترسی به دادهها با قرارداد OData را میدهد.
- OData service سرویس دهنده و امکان دسترسی به دادهها را فراهم میسازد.
- ساده و انعطاف پذیر
- سورس باز بودن
- امکان استفاده در سیستمهای با دادههای رابطه ای و غیر رابطه ای
- امکان استفاده از دادهها با منابع ای که آدرس پذیر هستند یعنی دسترسی از طریق Url
- امکان دسترسی هر نوع گیرنده ای به داده ها
- امکان نمایش خروجی با فرمت Json یا Xml
- ...
مطلبی چندی قبل در مورد "ذخیره سازی فایلها در دیتابیس یا استفاده از فایل سیستم متداول؟" منتشر گردید، جهت برشمردن فواید ذخیره سازی فایلها در دیتابیس (+). اما معایب این نوع ذخیره سازی بررسی نشدند:
الف) اختصاص یافتن قسمتی از بافر SQL Server به این امر.
ب) با توجه به قرار گرفتن دادههای BLOB در دیتابیس ، transaction log قابل توجهی تولید خواهد شد. (+)
ج) بیش از 2GB را نمیتوان در فیلدهایی از نوع varbinary(max) ذخیره کرد.
د) به روز رسانی BLOB ها سبب ایجاد fragmentation میشود.
مایکروسافت برای رفع این مشکلات در SQL Server 2008 قابلیت جدیدی را ارائه داده است به نام FileStream که در طی مقالاتی به بررسی آن خواهیم پرداخت.
FILESTREAM موتور دیتابیس اس کیوال سرور را با سیستم فایل NTFS یکپارچه میکند؛ به این صورت که دادههای BLOB از نوع varbinary(max) را به صورت فایل بر روی سیستم ذخیره خواهد کرد. سپس با استفاده از دستورات T-SQL میتوان این فایلها را ثبت، حذف، به روز رسانی، جستجو و بک آپ گیری کرد. این قابلیت نیز از فیلدهای varbinary(max) استفاده میکند؛ اما اکنون ویژگی و برچسب FILESTREAM به این نوع فیلدها الصاق خواهد شد. FILESTREAM data باید در FILESTREAM filegroups ذخیره شوند. FILESTREAM filegroups در حقیقت همان پوشههای فایل سیستم میباشند. به آنها data containers نیز گفته میشوند که مرزی هستند بین ذخیره سازی دادهها در فایل سیستم و در دیتابیس.
مزایای سیستم FileStream چیست؟
الف) سیستم transaction مختص به خود را داشته، به همین جهت سبب رشد غیر منطقی حجم فایل transaction log دیتابیس اصلی نمیشوند.
ب) هنگام به روز رسانی فیلدهایی از این دست، صرفا ایجاد یا حذف یک فایل مد نظر است؛ بنابراین fragmentation ایجاد شده در این حالت بسیار کمتر از روش استفاده از فیلدهایی از نوع varbinary(max) میباشد.
ج) استفاده از NT system cache جهت کش کردن اطلاعات که سبب بالا بردن بازدهی بانک اطلاعاتی خواهد شد.
د) از buffer pool اس کیوال سرور در این حالت استفاده نشده (مطابق قسمت ج) و این حافظه جهت امور روزمرهی اس کیوال سرور کاملا مهیا خواهد بود.
ه) محدودیت 2GB فیلدهایی از نوع varbinary(max) با توجه به ذخیره سازی این نوع BLOBs در فایل سیستم، دیگر وجود نخواهد داشت.
چه زمانی بهتر است از FileStream استفاده شود؟
الف) فایلهایی که ذخیره میشوند به طور متوسط بیش از یک مگابایت حجم داشته باشند. (برای کمتر از این مقدار varbinary(max) BLOBs کارآیی بهتری را ارائه میدهند). هر چند این مرز یک مگابایت مطابق اطلاعات books online است اما تجربیات کاری نشان میدهند که این سقف را باید 256 کیلوبایت درنظر گرفت.
ب) قابلیت خواندن سریع اطلاعات فایلها مد نظر باشد (بررسی کارآیی مطابق تصویر زیر از MSDN). سیستم NTFS نسبت به SQL Server در خواندن فایلهای حجیم سریعتر عمل میکند.
ج) اگر از یک معماری middle tier در برنامههای خود در حال استفادهاید.
د) زمانیکه نیاز باشد تا اطلاعات relational و non-relational در یک تراکنش مورد استفاده قرار گیرند.
نکاتی را که باید هنگام ذخیره سازی اطلاعات در FileStream در نظر داشت
الف) هنگامی که یک جدول حاوی فیلدی از نوع FileStream میباشد، باید دارای فیلد ID منحصربفرد نیز باشد.
ب) data containers ایی که پیش از این در مورد آنها صحبت شد، نباید تو در تو باشند.
ج) FILESTREAM filegroups بر روی درایوهای فشرده شده نیز میتوانند قرار داشته باشند.
FileStream از دیدگاه امنیت
امنیت دادههای FileStream در اس کیوال سرور دقیقا همانند امنیت سایر اطلاعات ذخیره شده در دیتابیس است (دسترسی در حد جدول و یا فیلد). اگر کاربری دسترسی به فیلد FileStream در یک جدول داشته باشد، میتواند آن فایل را گشوده و استفاده کند. رمزنگاری بر روی این ستونها پشتیبانی نمیشود. تنها اکانتی که اس کیوال سرور تحت آن در حال اجرا است دسترسی به FILESTREAM container دارد. همچنین توصیه شده است که به هیچ اکانت دیگری این دسترسی داده نشود. زمانیکه یک دیتابیس آغاز و مشغول به کار میشود، اس کیوال سرور دسترسی به FILESTREAM data container را محدود خواهد کرد و دسترسی به این اطلاعات تنها از طریق دستورات T-SQL و یا OpenSqlFilestream API میسر خواهد بود. بدیهی است زمانیکه اس کیوال سرور متوقف شود، این اطلاعات بدون هیچگونه محدودیتی قابل دسترسی بوده و تنها محدودیتهای سیستمی به آنها اعمال خواهند شد (که این مورد باید مد نظر باشد).
نگهداری FileStream
FileStream به صورت فیلدهای varbinary(max) یکپارچه با دیتابیس ذخیره میشود؛ بنابراین نحوهی تهیه پشتیبان از آنها همانند روشهای متداول است بدون هیچگونه تغییری (و این اطلاعات در بک آپ دیتابیس لحاظ میشوند). اگر نیاز بود هنگام تهیه پشتیبان از این نوع دادهها بک آپ گرفته نشود، میتوان از partial backup با پارامترهای مربوطه استفاده کرد.
ادامه دارد ...
برای اینکار SQL Server از یک بافر 60 کیلوبایتی برای ذخیره سازی اطلاعات لاگهایی که قرار است به صورت غیرهمزمان با تراکنشها نوشته شوند، استفاده میکند. هر زمان که این 60KB پر شد، آنرا flush کرده و ثبت خواهد نمود. به این ترتیب به دو مزیت خواهیم رسید:
- پردازش تراکنشها بدون منتظر شدن جهت commit نهایی در دیسک سخت ادامه خواهند یافت. صبر کمتر به معنای امکان پردازش تراکنشهای بیشتری در یک سیستم پر ترافیک است.
- با توجه به بافری که از آن صحبت شد، اینبار اعمال Write به صورت یک سری batch اعمال میشوند که کارآیی و سرعت بیشتری نسبت به حالت تکی دارند.
اندکی تاریخچه
ایده یک چنین عملی 28 سال قبل توسط Hal Berenson ارائه شدهاست! اوراکل آنرا در سال 2006 تحت عنوان Asynchronous Commit پیاده سازی کرد و مایکروسافت در سال 2014 آنرا ارائه دادهاست.
فعال سازی ماندگاری غیرهمزمان در SQL Server
فعال سازی این قابلیت در سطح بانک اطلاعاتی، در سطح یک تراکنش مشخص و یا در سطح رویههای ذخیره شده کامپایل شده مخصوص OLTP درون حافظهای، میسر است.
برای فعال سازی ماندگاری با تاخیر در سطح یک دیتابیس، خواهیم داشت:
ALTER DATABASE dbname SET DELAYED_DURABILITY = DISABLED | ALLOWED | FORCED;
در اینجا اگر ALLOWED را انتخاب کنید، به این معنا است که لاگ کلیه تراکنشهای مرتبط با این بانک اطلاعاتی به صورت غیرهمزمان نوشته میشوند. حالت FORCED نیز دقیقا به همین معنا است با این تفاوت که اگر حالت ALLOWED انتخاب شود، تراکنشهای ماندگار (آنهایی که به صورت دستی DELAYED_DURABILITY را غیرفعال کردهاند)، سبب flush کلیه تراکنشهایی با ماندگاری به تاخیر افتاده خواهند شد و سپس اجرا میشوند. در حالت Forced تنظیم دسترسی DELAYED_DURABILITY = OFF در سطح تراکنشها تاثیری نخواهد داشت؛ اما در حالت ALLOWED این مساله به صورت دستی در سطح یک تراکنش قابل لغو است.
البته باید توجه داشت، صرفنظر از این تنظیمات، یک سری از تراکنشها همیشه ماندگار هستند و بدون تاخیر؛ مانند تراکنشهای سیستمی، تراکنشهای بین دو یا چند بانک اطلاعاتی و کلیه تراکنشهایی که با FileTable، Change Data Capture و Change Tracking سر و کار دارند.
در سطح تراکنشهای میتوان نوشت:
COMMIT TRANSACTION WITH (DELAYED_DURABILITY = ON);
BEGIN ATOMIC WITH (DELAYED_DURABILITY = ON, ...)
سؤال: آیا فعال سازی DELAYED_DURABILITY بر روی مباحث locking و isolation levels تاثیر دارند؟
پاسخ: خیر. کلیه تنظیمات قفل گذاریها همانند قبل و بر اساس isolation levels تعیین شده، رخ خواهند داد. تنها تفاوت در اینجا است که با فعال سازی DELAYED_DURABILITY، کار commit بدون صبر کردن برای پایان نوشته شدن اطلاعات در لاگ سیستم صورت میگیرد. به این ترتیب قفلهای انجام شده زودتر آزاد خواهند شد.
سؤال: میزان از دست دادن اطلاعات احتمالی در این روش چقدر است؟
در صورتیکه سرور کرش کند یا ریاستارت شود، حداکثر به اندازهی 60KB اطلاعات را از دست خواهید داد (اندازهی بافری که برای اینکار درنظر گرفته شدهاست). البته عنوان شدهاست که اگر ریاستارت یا خاموشی سرور، از پیش تعیین شده باشد، ابتدا کلیه لاگهای flush نشده، ذخیره شده و سپس ادامهی کار صورت خواهد گرفت؛ ولی زیاد به آن اطمینان نکنید. اما همواره با فراخوانی sys.sp_flush_log، میتوان به صورت دستی بافر لاگهای سیستم را flush کرد.
یک آزمایش
در ادامه قصد داریم یک جدول جدید را در بانک اطلاعاتی آزمایشی testdb2 ایجاد کنیم. سپس یکبار تنظیم DELAYED_DURABILITY = FORCED را انجام داده و 10 هزار رکورد را ثبت میکنیم و بار دیگر DELAYED_DURABILITY = DISABLED را تنظیم کرده و همین عملیات را تکرار خواهیم کرد:
CREATE TABLE tblData( ID INT IDENTITY(1, 1), Data1 VARCHAR(50), Data2 INT ); CREATE CLUSTERED INDEX PK_tblData ON tblData(ID); CREATE NONCLUSTERED INDEX IX_tblData_Data2 ON tblData(Data2); ------------------------- alter database testdb2 SET DELAYED_DURABILITY = FORCED; ------------------------- SET NOCOUNT ON Print 'DELAYED_DURABILITY = FORCED' DECLARE @counter AS INT = 0 DECLARE @start datetime = getdate() WHILE (@counter < 10000) BEGIN INSERT INTO tblData (Data1, Data2) VALUES('My Data', @counter) SET @counter += 1 END Print DATEDIFF(ms,@start,getdate()); GO ------------------------- alter database testdb2 SET DELAYED_DURABILITY = DISABLED; truncate table tblData; ------------------------- SET NOCOUNT ON Print 'DELAYED_DURABILITY = DISABLED' DECLARE @counter AS INT = 0 DECLARE @start datetime = getdate() WHILE (@counter < 10000) BEGIN INSERT INTO tblData (Data1, Data2) VALUES('My Data', @counter) SET @counter += 1 END Print DATEDIFF(ms,@start,getdate()); GO -----------------------
DELAYED_DURABILITY = FORCED 666 DELAYED_DURABILITY = DISABLED 2883
برای مطالعه بیشتر
Control Transaction Durability
SQL Server 2014 Delayed Durability/Lazy Commit
Delayed Durability in SQL Server 2014 – Part 1
Is In-Memory OLTP Always a silver bullet for achieving better transactional speed
Delayed Durability in SQL Server 2014
بررسی اجمالی Redis
Redis | RDBMS |
Redis همه چیز را در حافظه اصلی ذخیره میکند. | RDBMS همه چیز را در حافظه ثانویه ذخیره میکند. |
در Redis بخاطر ذخیره سازی دادهها در حافظه اصلی، خواندن و نوشتن عملیات به شدت سریع میباشد. | در RDBMS بخاطر ذخیره سازی دادهها در حافظه ثانویه، خواندن و نوشتن عملیات کند است. |
حافظه اصلی از نظر size کوچکتر و از لحاظ قیمت نسبت به حافظه ثانویه گرانتر میباشد. Redis نمیتواند دادههای بزرگ یا binary data را ذخیره کند. | حافظه ثانویه از نظر size بزرگتر و از لحاظ قیمت نسبت به حافظه اصلی ارزانتر میباشد. RDBMS به آسانی میتواند با انواع فایلها کار کند. |
- Redis : Exceptionally fast خیلی سریع است و میتواند حدود 110000 ، SET و 81000 ، GET را به ازای هر ثانیه انجام دهد.
- Redis : Supports rich data type بیشتر دیتا تایپها را که توسعه دهندگان قبلا آنها را شناختهاند، پشتیبانی میکند؛ از قبیل string ، list ، set ، sorted set یا hash .
- Operations are atomic : تمام عملیات Redis اتمیک میباشند که این اطمینان خاطر را میدهد اگر دو کلاینت به صورت همزمان به آن دسترسی داشته باشند، Redis server مقدار update شده را دریافت خواهد کرد.
- Redis : Multi-utility tool یک ابزار چند منظوره است که میتواند در برخی از سناریوها استفاده شود از قبیل: Redis ) messaging-queues , caching به صورت بومی از Publish/Subscribe پشتیبانی میکند ) , هر داده ای با طول عمر کوتاه در Application مانند web application sessions , ... .
(The God Class Problem (Behavioral Form
یکی از مخاطراتی که ممکن است موجب عدم بروز مزایای شیء گرایی در طرح شما شود، بحث God Class میباشد. شکل رفتاری آن (Behavioral Form) بیشتر در اثر یک خطای مشترک بین توسعه دهندگان پارادایم action-oriented و در جریان مهاجرت به سمت پارادایم شیء گرا، رخ میدهد.
این توسعه دهندگان بیشتر سعی در تسخیر و دستیابی به یک مکانیزم کنترل مرکزی شبیه به آنچه در پارادایم action-oriented داشتهاند، در طراحی شیء گرای خود دارند. حاصل این کار تشکیل کلاسی خواهد بود که همه کارها را انجام میدهد، درحالیکه جزئیات ناچیزی هم به عهده مجموعهای از کلاسها سپرده شده است.
قاعده شهودی 3.1
تا حد ممکن هوشمندی سیستم را به صورت افقی و به طور یکنواخت توزیع کنید. به این معنی که کلاسهای سطح بالای موجود در طراحی، باید کار را به طور یکسان مابین خود به اشتراک بگذارند. (Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly)منظور اینکه Businessای را که سیستم قرار است پیاده سازی کند، بین کلاسهای سطح بالا تقسیم کنید. در حالت vertical یا عمودی میتوان در نظر گرفت که کلاسی این Business را توسط یکسری متد در دل خود پیاده سازی کند و این متدها یکدیگر را فراخوانی خواهند کرد.
قاعده شهودی 3.2
در سیستم خود God Class ایجاد نکنید. به کلاس هایی که نام آنها شامل Driver، Manager و یا Subsystem میباشد، مشکوک باشید. (Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System, or Subsystem)
مانند: BlahBlahSystem یا BlahManager
قاعده شهودی 3.3مراقب کلاس هایی باشید که در واسط عمومی آنها تعداد زیادی Accessor Method تعریف شده است؛ وجود آنها نشان از این دارد که داده و رفتار، در یکجا نگه داشته نشده اند. (Beware of classes that have many accessor methods defined in their public interface. Having many implies that related data and behavior are not being kept in one place)ازدیاد عملیات get و set در واسط عمومی کلاسها که Accessor Method نامیده میشوند، نشان دهنده ایجاد شکل رفتاری God Class میباشند. منظور این است که یک کلاس، رفتارهایی برای کار کردن با دادههای خود در نظر نگرفته است و این دادهها را از طریق accessor methodها در اختیار کلاس دیگری قرار میدهد تا عملیات روی دادهها را انجام دهد. در اینجا هم مقصود God Class شدن کلاسی است که از این accessor methodها استفاده میکند و نشان از این دارد که تعداد رفتارهای آن زیاد خواهد شد.
مراقب کلاس هایی باشید که تعداد خیلی زیادی رفتار نامرتبط دارند؛ یعنی رفتارهایی که فقط برروی زیر مجموعه ای از دادههای کلاس کار میکنند. God Classها اغلب دارای اینگونه رفتارهای نامرتبط به هم هستند. (Beware of classes that have too much noncommunicating behavior, that is, methods that operate on a proper subset of the data members of a class. God classes often exhibit much noncommunicating behavior)منظور اینکه کلاس مورد نظر را میتوان شکست و تبدیل به دو کلاس مختلف کرد. به عنوان اولین مثال، دامنه مربوط به سیستم برنامه ریزی دورههای آموزشی را در نظر بگیرید. در این دامنه، ما با وهله هایی از «Student» ،«Course» و «CourseOffering» سروکار خواهیم داشت.
قصد داریم با فراخوانی متد ()add_student مربوط به CourseOffering، یک دانشجو را به لیست شرکت کنندگان یک دوره اضافه کنیم. همچنین در این زمان لازم است مطمئن شویم که دانشجوی مورد نظر تمام پیش نیازهای دوره انتخاب شده را گذرانده باشد. به نظر شما کدام کلاس میبایست عملیات چک کردن پیش نیازها را انجام دهد؟
کلاس دانشجو از دورههایی که گذرانده است آگاه است و کلاس دوره هم از پیش نیازهای خود. در بهترین حالت شاید یکی از طراحیهای زیر را ارائه دهید. به شکلی که یا کلاس دوره با استفاده از متد get_courses مربوط به کلاس دانشجو، داده مورد نیاز را بدست آورده و عملیات چک کردن را در دل خود بگنجاند یا برعکس.
در هر دو طراحی بالا، بخشی از اطلاعات مربوط به policy (سیاست) در کلاس هایی قرار دارد که موضوع تصمیمات سیاستها هستند. این کار از آن جهت که کلاسهای مورد نظر ما را به دامنه خاصی که این policy در آن دامنه معنا دارد وابسته میکند و امکان استفاده مجدد از آن کلاسها را از دست خواهید داد.
راه حلهای پیشنهادی برای مشکل مطرح شده به شکل زیر میباشند:
با توجه به طراحی شکل بالا، یا خود کلاس CourseOffering با استفاده از لیست دورههای گذرانده شده توسط دانشجو و لیست دورههای پیش نیاز دوره انتخابی، چک کردن را انجام دهد و یا کلاسی با عنوان PrereqChecker که یک Controller Class (کلاسی که فقط رفتار دارد و داده مورد نظر خود را توسط سایر کلاسها و از طریق accessor methodهای آنها تأمین میکند) میباشد، وظیفه چک کردن را برعهده بگیرد.
علاوه بر اینکهaccessor method ها، داده را برای کلاسهای کنترلر مهیا میکنند (مانند مثال بالا)، وظیفهی مهیا کردن داده برای UI (رابط کاربری) را نیاز بر عهده خواهند داشت. به این صورت که رابط کاربری، با استفاده از این متدها، مشخصات درونی مدل را نمایش دهد و یا این امکان را به کاربر میدهد که این مشخصات درونی مدل را ویرایش کرده و به سمت مدل ارسال نماید.
قاعده شهودی 3.5
در برنامههایی که شامل یک مدل شی گرایی میباشند که با رابط کاربری تعامل دارند، مدل نباید به رابط کاربری وابسته باشد. رابط کاربری میبایست وابسته به مدل باشد. (In applications that consist of an object-oriented model interacting with a user interface, the model should never be dependent on the interface. The interface should be dependent on the model)
برای عدم نقض این قاعده شهودی، لازم است در مدل یکسری accessor method در نظر گرفته شود تا رابط کاربری از آن استفاده کند؛ ولی باید مراقب بود که این accessor methodها صرفا توسط رابط کاربری استفاده شود و عدم توجه به این قضیه، احتمالا شما را به سمت نقض قاعده 3.3 متمایل خواهد کرد.
var sqlDatabasePassword = pulumiConfig.RequireSecret("sql-server-nikola-dev-password"); var sqlDatabaseUserId = pulumiConfig.RequireSecret("sql-server-nikola-dev-user-id"); var resourceGroup = new ResourceGroup("rg-dds-nikola-dev", new ResourceGroupArgs { Name = "rg-dds-nikola-dev", Location = "WestUS" }); var storageAccount = new Account("storagenikoladev", new AccountArgs { Name = "storagenikoladev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, AccountKind = "StorageV2", AccountReplicationType = "LRS", AccountTier = "Standard", }); var container = new Container("container-nikola-dev", new ContainerArgs { Name = "container-nikola-dev", ContainerAccessType = "blob", StorageAccountName = storageAccount.Name }); var blobStorage = new Blob("blob-nikola-dev", new BlobArgs { Name = "blob-nikola-dev", StorageAccountName = storageAccount.Name, StorageContainerName = container.Name, Type = "Block" }); var appInsights = new Insights("app-insights-nikola-dev", new InsightsArgs { Name = "app-insights-nikola-dev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, ApplicationType = "web" // also general for mobile apps }); var sqlServer = new SqlServer("sql-server-nikola-dev", new SqlServerArgs { Name = "sql-server-nikola-dev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, AdministratorLogin = sqlDatabaseUserId, AdministratorLoginPassword = sqlDatabasePassword, Version = "12.0" }); var sqlDatabase = new Database("sql-database-nikola-dev", new DatabaseArgs { Name = "sql-database-nikola-dev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, ServerName = sqlServer.Name, RequestedServiceObjectiveName = "Basic" }); var appServicePlan = new Plan("app-plan-nikola-dev", new PlanArgs { Name = "app-plan-nikola-dev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, Sku = new PlanSkuArgs { Tier = "Shared", Size = "D1" } }); var appService = new AppService("app-service-nikola-dev", new AppServiceArgs { Name = "app-service-nikola-dev", ResourceGroupName = resourceGroup.Name, Location = resourceGroup.Location, AppServicePlanId = appServicePlan.Id, SiteConfig = new AppServiceSiteConfigArgs { Use32BitWorkerProcess = true, // X64 not allowed in shared plan! AlwaysOn = false, // not allowed in shared plan! Http2Enabled = true }, AppSettings = { { "ApplicationInsights:InstrumentationKey", appInsights.InstrumentationKey }, { "APPINSIGHTS_INSTRUMENTATIONKEY", appInsights.InstrumentationKey } }, ConnectionStrings = new InputList<AppServiceConnectionStringArgs>() { new AppServiceConnectionStringArgs { Name = "AppDbConnectionString", Type = "SQLAzure", Value = Output.Tuple(sqlServer.Name, sqlDatabase.Name, sqlDatabaseUserId, sqlDatabasePassword).Apply(t => { (string _sqlServer, string _sqlDatabase, string _sqlDatabaseUserId, string _sqlDatabasePassword) = t; return $"Data Source=tcp:{_sqlServer}.database.windows.net;Initial Catalog={_sqlDatabase};User ID={_sqlDatabaseUserId};Password={_sqlDatabasePassword};Max Pool Size=1024;Persist Security Info=true;Application Name=Nikola"; }) }, new AppServiceConnectionStringArgs { Name = "AzureBlobStorageConnectionString", Type = "Custom", Value = Output.Tuple(storageAccount.PrimaryAccessKey, storageAccount.Name).Apply(t => { (string _primaryAccess, string _storageAccountName) = t; return $"DefaultEndpointsProtocol=https;AccountName={_storageAccountName};AccountKey={_primaryAccess};EndpointSuffix=core.windows.net"; }) } } }); appService.OutboundIpAddresses.Apply(ips => { foreach (string ip in ips.Split(',')) { new FirewallRule($"app-srv-{ip}", new FirewallRuleArgs { Name = $"app-srv-{ip}", EndIpAddress = ip, ResourceGroupName = resourceGroup.Name, ServerName = sqlServer.Name, StartIpAddress = ip }); } return (string?)null; });