هوش تجاری (Business Intelligence)
به اشتراک بگذاریم برای یادگیری، یاد بگیریم برای به اشتراک گذاری
هوش تجاری (Business Intelligence)
به اشتراک بگذاریم برای یادگیری، یاد بگیریم برای به اشتراک گذاریدرباره من
دسته‌ها
جدیدترین یادداشت‌ها
همه- انتخاب یک راهکار مناسبِ هوش تجاری بر اساس نیاز کسب و کار- بخش سوم
- انتخاب یک راهکار مناسبِ هوش تجاری بر اساس نیاز کسب و کار- بخش دوم
- انتخاب یک راهکار مناسبِ هوش تجاری بر اساس نیاز کسب و کار- بخش اول
- Running Total
- چرا باید برنامه های موبایلی را تحلیل کنیم؟ و چرا برای تحلیل داده های موبایلی نیاز به یک ابزار آماده داریم؟
- CAP Theorem
- الگوی طراحی جداول ابعاد- slowly changing dimension
- حذف سطرهای تکراری یک جدول، بوسیله SSIS Sort Transformation
- آیا دوران پادشاهی اوراکل در حوزه‌ی مدیریت پایگاه‌های داده عملیاتی به پایان رسیده است؟
- عوامل حیاتی در موفقیت سیستم‌های هوش تجاری (Critical Success Factors)
- گستردگی استفاده از سیستم های هوش تجاری
- 7 قابلیت جدید در SQL Server 2016
- مراحل کلی در انجام عملیات داده کاوی
- برقراری ارتباط کلیک ویو با Cube
- کاربرد Unary Operator در OLAP
نویسندگان
- حامد پالیک 61
- علی سیدزاده 3
بایگانی
- مهر 1400 1
- شهریور 1400 1
- مرداد 1400 1
- بهمن 1396 1
- آذر 1396 1
- دی 1395 1
- آذر 1395 1
- شهریور 1395 1
- آذر 1394 1
- آبان 1394 1
- خرداد 1394 1
- اردیبهشت 1394 1
- آبان 1393 1
- مهر 1393 1
- مرداد 1393 1
- اردیبهشت 1393 1
- فروردین 1393 1
- بهمن 1392 1
- آذر 1392 3
- آبان 1392 2
- مهر 1392 2
- شهریور 1392 2
- مرداد 1392 5
- تیر 1392 4
- خرداد 1392 1
- اردیبهشت 1392 1
- اسفند 1391 1
- بهمن 1391 2
- دی 1391 2
- آذر 1391 10
- آبان 1391 11
جستجو
CAP Theorem
سیستم‌های توزیع شده و تئوری CAP
اطلاعات و منابع زیادی در خصوص مزایای استفاده از سیستم‌های توزیع شده وجود دارد اما کمتر به معایب آن پرداخته شده است.
به طور خلاصه، استفاده از دو یا چند سرور جهت استفاده همزمان از یک برنامه به طوری که کاربر نهایی متوجه تغییرات و نحوه ذخیره سازی اطلاعات نشود، سیستم توزیع شده گفته می‌شود. برنامه ها در سیستم‌های توزیع شده از منابع مختلف غیر اشتراکی استفاده می‌کنند و هر سیستم (سرور) منابع خود را کنترل می‌کند.
تئوری CAP :
در علوم کامپیوتر و به طور خاص در سیستم‌های توزیع شده، تئوری وجود دارد به نام تئوری CAP (که با نام تئوری Brewer هم شناخته می شود) که بر اساس آن برای یک سیستم توزیع شده برآوردن هر سه مورد زیر به طور همزمان غیر ممکن خواهد بود:
Consistency: تمامی گره‌ها در یک زمان خاص داده‌های مشابه دریافت کنند
Availability: دسترس پذیری درخواست‌ها برای همه گره‌ها
Partition tolerance: از دسترس خارج شدن سامانه در هنگام شکست شبکه
قضیه CAP بیانگر این موضوع است که در سیستم‌های توزیع شده شما فقط امکان فراهم کردن دو گزینه از سه گزینه Consistency و Availability و Partition tolerance را خواهید داشت و گزینه باقیمانده، فدای گزینه های دیگر خواهد شد.
هنگامی که Availability و Partition tolerance را انتخاب می‌کنیم، به معنی آن است که هر درخواستی، پاسخی دریافت خواهد کرد. این پاسخ تا جای ممکن شامل جدیدترین اطلاعات خواهد بود ولی این امکان وجود دارد که قدیمی باشد. از طرف دیگر درج اطلاعات ممکن است که در لحظه امکان نداشته باشد، ولی سیستم به کار خود ادامه می‌دهد و در نهایت به ثبات خواهد رسید. این انتخاب برای کارهایی که در دسترس بودن سیستم و سرعت آن، نسبت به ثبات و دوام اطلاعات، اولویت بالاتری دارد مناسب می‌باشد.
موقعی که Consistency و Partition tolerance را انتخاب می کنیم، به معنی آن است که هر درخواستی حتما باید آخرین نسخه از اطلاعات را به عنوان پاسخ دریافت نماید. همچنین اگر دو درخواست یکسان از دو مکان مختلف به سیستم ارسال شود، سیستم باید به هر دو درخواست کننده جواب یکسانی بدهد. در این حالت، با افزایش Consistency زمان تاخیر افزایش، و سرعت پاسخ دهی کاهش می یابد.
پایگاه داده‌های رابطه‌ای به دلیل ماهیت و پشتیبانی کردن از ACID (مجموعه خصوصیات دیتابیس‌های تراکنشی)، گزینش CA را انجام می‌دهند.
