مدیریت داده های معامله ای با استفاده از سیستم های رایانه ای به پردازش معاملات آنلاین (OLTP) گفته می شود. سیستم های OLTP تعامل تجاری را به عنوان اتفاق روزانه سازمان ثبت می کنند و از پرس و جو از این داده ها برای ایجاد استنتاج پشتیبانی می کنند.
داده های معامله
داده های معامله ای اطلاعاتی است که تعامل مربوط به فعالیت های یک سازمان را ردیابی می کند. این تعامل به طور معمول معاملات تجاری است ، مانند پرداخت های دریافت شده از مشتریان ، پرداخت های انجام شده به تأمین کنندگان ، محصولاتی که از طریق موجودی ، سفارشات گرفته شده یا خدمات ارائه شده حرکت می کنند. رویدادهای معامله ای ، که خود معاملات را نشان می دهند ، به طور معمول حاوی ابعاد زمانی ، مقادیر عددی و ارجاع به داده های دیگر هستند.
معاملات به طور معمول باید اتمی و سازگار باشند. اتمی به این معنی است که یک معامله کامل همیشه به عنوان یک واحد کار موفق یا شکست می خورد و هرگز در یک حالت نیمه کامل باقی نمی ماند. در صورت عدم انجام معامله ، سیستم پایگاه داده باید هرگونه اقدامی را که قبلاً به عنوان بخشی از آن معامله انجام شده بود ، پس بگیرد. در یک RDBMS سنتی ، در صورت عدم انجام معامله به طور خودکار اتفاق می افتد. قوام به این معنی است که معاملات همیشه داده ها را در یک حالت معتبر ترک می کنند.(اینها توصیفات بسیار غیررسمی از اتمی و قوام هستند. تعاریف رسمی تر از این خصوصیات مانند اسید وجود دارد.)
بانکهای اطلاعاتی معاملاتی می توانند از سازگاری قوی برای معاملات با استفاده از استراتژی های مختلف قفل ، مانند قفل بدبینانه ، پشتیبانی کنند تا اطمینان حاصل شود که تمام داده ها به شدت در چارچوب شرکت ، برای همه کاربران و فرآیندها سازگار هستند.
متداول ترین معماری استقرار که از داده های معامله ای استفاده می کند ، ردیف فروشگاه داده در یک معماری 3 لایه است. یک معماری 3 لایه به طور معمول شامل یک ردیف ارائه ، ردیف منطق تجارت و ردیف فروشگاه داده است. معماری استقرار مرتبط ، معماری N-stier است که ممکن است دارای چندین منطق تجارت در سطح متوسط باشد.
صفات معمولی داده های معامله ای
داده های معاملاتی تمایل به ویژگی های زیر دارند:
| الزام | شرح |
|---|---|
| عادی سازی | بسیار عادی شده |
| طرح | طرحواره در نوشتن ، به شدت اجرا شده است |
| ثبات | قوام قوی ، اسید تضمین می کند |
| تمامیت | صداقت |
| از معاملات استفاده می کند | آره |
| استراتژی قفل | بدبین یا خوش بین |
| به روزر | آره |
| قابل ارائه | آره |
| بار کار | می نویسد سنگین ، خواندن متوسط |
| نمایه سازی | شاخص های اولیه و ثانویه |
| اندازه داده | کوچک و متوسط |
| مدل | رابطه |
| شکل داده ها | جدلی |
| انعطاف پذیری پرس و جو | بسیار انعطاف پذیر |
| اندازه | کوچک (Mbs) به بزرگ (چند TBS) |
چه موقع از این راه حل استفاده کنید
OLTP را در صورت نیاز به پردازش کارآمد و ذخیره معاملات تجاری انتخاب کرده و بلافاصله آنها را به روش مداوم در دسترس برنامه های مشتری قرار دهید. از این معماری استفاده کنید که هرگونه تأخیر ملموس در پردازش تأثیر منفی بر عملکرد روزانه تجارت داشته باشد.
سیستم های OLTP برای پردازش و ذخیره معاملات و همچنین داده های معامله ای پرس و جو طراحی شده اند. هدف از پردازش و ذخیره کارآمد معاملات فردی توسط یک سیستم OLTP تا حدودی با عادی سازی داده ها انجام می شود - یعنی تجزیه داده ها به تکه های کوچکتر که کمتری دارند ، شکسته می شود. این کارآیی را پشتیبانی می کند زیرا سیستم OLTP را قادر می سازد تعداد زیادی از معاملات را به طور مستقل پردازش کند و از پردازش اضافی مورد نیاز برای حفظ یکپارچگی داده ها در حضور داده های زائد جلوگیری می کند.
چالش ها
اجرای و استفاده از سیستم OLTP می تواند چند چالش ایجاد کند:
- سیستم های OLTP همیشه برای رسیدگی به مصالح بیش از مقادیر زیادی از داده ها مناسب نیستند ، اگرچه استثنائاتی وجود دارد ، مانند یک راه حل مبتنی بر سرور SQL برنامه ریزی شده. تجزیه و تحلیل در برابر داده ها ، که به محاسبات کل بیش از میلیون ها معاملات جداگانه متکی هستند ، برای یک سیستم OLTP بسیار فشرده هستند. آنها می توانند در اجرای آن آهسته باشند و با مسدود کردن سایر معاملات در پایگاه داده می توانند باعث کاهش آهسته شوند.
- هنگام انجام تجزیه و تحلیل و گزارش در مورد داده هایی که بسیار نرمال هستند ، نمایش داده ها پیچیده است ، زیرا بیشتر نمایش داده ها باید با استفاده از پیوندها ، داده ها را از بین ببرند. همچنین ، نامگذاری کنوانسیون برای اشیاء پایگاه داده در سیستم های OLTP تمایل به شکوفه و موجز دارد. افزایش عادی سازی همراه با کنوانسیون های نامگذاری TERSE ، سیستم های OLTP را بدون کمک DBA یا توسعه دهنده داده ، برای کاربران تجاری دشوار می کند.
- ذخیره سابقه معاملات به طور نامحدود و ذخیره بیش از حد داده ها در هر جدول ، بسته به تعداد معاملات ذخیره شده ، می تواند منجر به عملکرد پرس و جو کند شود. راه حل متداول حفظ یک پنجره مربوط به زمان (مانند سال مالی فعلی) در سیستم OLTP و بارگیری داده های تاریخی به سایر سیستم ها ، مانند مارت داده یا انبار داده است.
OLTP در لاجورد
برنامه هایی مانند وب سایت های میزبان در برنامه های وب سرویس برنامه ، API های REST که در سرویس برنامه اجرا می شوند ، یا برنامه های کاربردی تلفن همراه یا دسک تاپ با سیستم OLTP ، به طور معمول از طریق واسطه API REST ارتباط برقرار می کنند.
در عمل ، بیشتر بارهای کاری صرفاً OLTP نیستند. تمایل به یک جزء تحلیلی نیز وجود دارد. علاوه بر این ، تقاضای فزاینده ای برای گزارشگری در زمان واقعی وجود دارد ، مانند اجرای گزارش ها علیه سیستم عملیاتی. این همچنین به HTAP (پردازش معاملات ترکیبی و تحلیلی) گفته می شود. برای اطلاعات بیشتر ، به پردازش تحلیلی آنلاین (OLAP) مراجعه کنید.
در لاجورد ، تمام فروشگاه های داده زیر الزامات اصلی OLTP و مدیریت داده های معامله را برآورده می کنند:
معیارهای انتخاب کلیدی
برای محدود کردن گزینه ها ، با پاسخ دادن به این سؤالات شروع کنید:
آیا به جای مدیریت سرورهای شخصی خود ، یک سرویس مدیریت شده می خواهید؟
آیا راه حل شما وابستگی های خاصی برای سازگاری Microsoft SQL Server ، MySQL یا PostgreSQL دارد؟برنامه شما ممکن است فروشگاه های داده ای را که می توانید انتخاب کنید بر اساس درایورهایی که برای برقراری ارتباط با فروشگاه داده پشتیبانی می کند ، یا فرضیاتی که در مورد اینکه از پایگاه داده استفاده می شود ، محدود کند.
آیا الزامات توان نوشتن شما به ویژه زیاد است؟اگر بله ، گزینه ای را انتخاب کنید که جداول حافظه را ارائه دهد.
آیا راه حل شما چند منظوره است؟در این صورت ، گزینه هایی را در نظر بگیرید که از استخرهای ظرفیت پشتیبانی می کنند ، جایی که چندین نمونه بانک اطلاعاتی به جای منابع ثابت در هر پایگاه داده ، از منابع الاستیک منابع خارج می شوند. این می تواند به شما در توزیع بهتر ظرفیت در تمام نمونه های پایگاه داده کمک کند و می تواند راه حل شما را مقرون به صرفه تر کند.
آیا داده های شما با تأخیر کم در چندین منطقه قابل خواندن است؟اگر بله ، گزینه ای را انتخاب کنید که از ماکت های ثانویه قابل خواندن پشتیبانی کند.
آیا پایگاه داده شما باید در مناطق جغرافیایی بسیار در دسترس باشد؟اگر بله ، گزینه ای را انتخاب کنید که از تکرار جغرافیایی پشتیبانی کند. همچنین گزینه هایی را در نظر بگیرید که از عدم موفقیت خودکار از ماکت اولیه به یک ماکت ثانویه پشتیبانی می کند.
آیا پایگاه داده شما نیازهای امنیتی خاصی دارد؟اگر بله ، گزینه هایی را که قابلیت هایی مانند امنیت سطح ردیف ، پوشش داده ها و رمزگذاری داده های شفاف را ارائه می دهد ، بررسی کنید.
ماتریس قابلیت
جداول زیر تفاوتهای کلیدی در قابلیت ها را خلاصه می کند.
قابلیت های عمومی
| توانایی | پایگاه داده Azure SQL | سرور SQL در یک ماشین مجازی لاجورد | پایگاه داده لاجورد برای mysql | پایگاه داده لاجورد برای postgreSQL |
|---|---|---|---|---|
| سرویس مدیریت شده است | آره | No | آره | آره |
| روی سیستم عامل اجرا می شود | N/A | ویندوز ، لینوکس ، داکر | N/A | N/A |
| قابلیت برنامه 1 | T-sql ، . net ، r | T-sql ، . net ، R ، Python | SQL | SQL ، PL/PGSQL |
[1] از جمله پشتیبانی درایور مشتری ، که به بسیاری از زبانهای برنامه نویسی اجازه می دهد تا به فروشگاه داده OLTP متصل شوند و از آن استفاده کنند.
قابلیت های مقیاس پذیری
| توانایی | پایگاه داده Azure SQL | سرور SQL در یک ماشین مجازی لاجورد | پایگاه داده لاجورد برای mysql | پایگاه داده لاجورد برای postgreSQL |
|---|---|---|---|---|
| حداکثر اندازه نمونه پایگاه داده | 4 سل | 256 سل | 16 سل | 16 سل |
| استخرهای ظرفیت را پشتیبانی می کند | آره | آره | No | No |
| از مقیاس خوشه ها پشتیبانی می کند | No | آره | No | No |
| مقیاس پذیری پویا (مقیاس بالا) | آره | No | آره | آره |
قابلیت های بار کاری تحلیلی
| توانایی | پایگاه داده Azure SQL | سرور SQL در یک ماشین مجازی لاجورد | پایگاه داده لاجورد برای mysql | پایگاه داده لاجورد برای postgreSQL |
|---|---|---|---|---|
| میزهای زمانی | آره | آره | No | No |
| میزهای حافظه (بهینه سازی شده حافظه) | آره | آره | No | No |
| پشتیبانی ستون | آره | آره | No | No |
| پردازش پرس و جو تطبیقی | آره | آره | No | No |
قابلیت های در دسترس بودن
| توانایی | پایگاه داده Azure SQL | سرور SQL در یک ماشین مجازی لاجورد | پایگاه داده لاجورد برای mysql | پایگاه داده لاجورد برای postgreSQL |
|---|---|---|---|---|
| ثانویه های قابل خواندن | آره | آره | آره | آره |
| تکثیر جغرافیایی | آره | آره | آره | آره |
| عدم موفقیت خودکار به ثانویه | آره | No | No | No |
| بازگرداندن نقطه به موقع | آره | آره | آره | آره |
قابلیت های امنیتی
| توانایی | پایگاه داده Azure SQL | سرور SQL در یک ماشین مجازی لاجورد | پایگاه داده لاجورد برای mysql | پایگاه داده لاجورد برای postgreSQL |
|---|---|---|---|---|
| امنیت سطح ردیف | آره | آره | آره | آره |
| پوشش داده ها | آره | آره | No | No |
| رمزگذاری داده های شفاف | آره | آره | آره | آره |
| دسترسی به آدرس های IP خاص را محدود کنید | آره | آره | آره | آره |
| دسترسی فقط به دسترسی VNET را محدود کنید | آره | آره | آره | آره |
| احراز هویت دایرکتوری فعال Azure | آره | No | آره | آره |
| احراز هویت Active Directory | No | آره | No | No |
| احراز هویت چند عاملی | آره | No | آره | آره |
| پشتیبانی همیشه رمزگذاری شده | آره | آره | No | No |
| IP | No | آره | No | No |
مشارکت کنندگان
این مقاله توسط مایکروسافت نگهداری می شود. در ابتدا توسط همکاران زیر نوشته شده است.
