معرفی

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

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

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

چالش بزرگ دیگر، مربوط به چالش اول است، این است که به دلیل هزینه و تلاش عملیاتی مورد نیاز، تصاویر به موقع به‌روزرسانی نمی‌شوند. تصاویر معمولاً ماه‌ها یا سال‌ها طول می‌کشد که به‌روزرسانی شود، که به این معنی است که نقشه‌ها به‌روز نبوده و به راحتی قدیمی می‌شوند.

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

با این حال، چالش‌هایی مرتبط با جمع‌آوری تصاویر جمعیتی وجود دارد مانند:

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

به منظور حل چالش‌های فوق، ما شروع به ساخت دوربین هوش مصنوعی KartaCam خود کردیم.

کارتاکم چیست؟

طراحی شده به‌طور ویژه برای ساخت نقشه، KartaCam یک دوربین سبک است که آسان برای استفاده است. همه چیزی که برای جمع‌آوری تصاویر دقیق و کارآمد نیاز دارید در دسترس است. KartaCam توسط هوش مصنوعی لبه تغذیه می‌شود و اصلیاً شامل یک ماژول دوربین، یک ماژول ماهواره‌ای دو باند GNSS و یک ماژول 4G Long-Term Evolution (LTE) داخلی است.

ماژول دوربین

ماژول دوربین یا طراحی نوری KartaCam بر روی چندین ویژگی کلیدی تمرکز می‌کند:

زاویه دید گسترده (FOV): زاویه دید گسترده به منظور ضبط بیشتر صحنه ها و جزئیات بدون نیاز به سفرهای اضافی استفاده می‌شود. یک دوربین KartaCam تنها با زاویه دید لنز گسترده بیشتر از 150 درجه، وقتی که چهار دوربین KartaCam به صورت همزمان با هم استفاده می‌شوند و هر کدام به سمت یک جهت مختلف هستند، زاویه دید را به 360 درجه افزایش می‌دهیم.کیفیت تصویر بالا: ترکیبی از لنز نوری با کیفیت بالا و حسگر تصویر پیکسل با رزولوشن بالا می‌تواند به بهبود کیفیت تصویر کمک کند. KartaCam از یک حسگر تصویر 12MP با کیفیت بالا استفاده می‌کند.سهولت استفاده: قابل حمل و آسان برای استفاده برای افرادی با آموزش کم یا هیچ آموزش عکاسی. در Grab، ما می‌توانیم به سادگی KartaCam را به ناوگان رانندگان-همکاران خود برای نقشه برداری از منطقه‌مان نصب کنیم زیرا آن‌ها به طور منظم در حین حمل مسافران یا انجام تحویلات این جاده ها را طی می‌کنند.

هوش مصنوعی لبه برای ضبط هوشمند در حاشیه

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

برای کمک به این تصمیمات، ما از مجموعه‌ای از مدل‌ها و الگوریتم‌های هوش مصنوعی لبه استفاده می‌کنیم که بلافاصله پس از هر ثبت تصویر اجرا می‌شوند مانند:

مدل تشخیص صحنه: برای نقشه سازی کارآمد، ما مطمئن می‌شویم که نتیجه‌های صحیح صفحه را بدست می‌آوریم، به این معنی که تنها تصاویر صحنه صحیح را بارگذاری و پردازش می‌کنیم. تصاویر غیرصالح مانند تصاویر داخلی، بارانی و ابری به طور مستقیم در دستگاه KartaCam حذف می‌شوند. الگوریتم‌های تشخیص مشترک در برخی موارد استفاده می‌شوند تا دقت نتایج را بهبود بخشیم. به عنوان مثال، برای تشخیص ضبط درون ساختمان، به ترکیبی از سرعت حرکت راننده، داده‌های واحد اندازه‌گیری ذاتي (IMU) و تشخیص تصویر هوش مصنوعی لبه نگاه می‌کنیم.مدل هوش مصنوعی بررسی (IQ): کیفیت تصاویر جمع‌آوری شده برای ساخت نقشه بسیار مهم است. تنها تصاویر صالحی که توسط الگوریتم طبقه‌بندی هوش مصنوعی IQ ما بهترین نتیجه را داشته باشند بارگذاری می‌شوند در حالی که تصاویری که مبهم هستند یا به عنوان کیفیت پایین مورد نظر است حذف می‌شوند. بلافاصله پس از تشخیص تصویر غیرمجاز (معمولاً در ثانیه بعدی)، یک تصویر جدید ضبط می‌شود و نرخ موفقیت جمع‌آوری بهبود می‌یابد.مدل تشخیص شیء: تنها تصاویر جاده‌ای که شامل محتوای مناسب برای ساخت نقشه مانند علائم ترافیکی، چراغ‌ها و متن نقاط جذاب هستند بارگذاری می‌شوند.تشخیص اطلاعات حفظ حریم خصوصی: هوش مصنوعی لبه همچنین در محافظت از حریم خصوصی هنگام جمع‌آوری تصاویر خیابانی برای ساخت نقشه کمک می‌کند. این به طور خودکار اطلاعات خصوصی مانند چهره‌های پیاده‌روی‌کنندگان و شماره پلاک ماشین‌ها را قبل از بارگذاری، باعث می‌شود حفاظت کافی از حریم خصوصی صورت گیرد.

موقعیت بهتر با یک ماژول دو باند GNSS

سيستم موقعيت ياب جهاني (GPS) عمدتاً از دو باند فرکانسي استفاده مي‌کند: L1 و L5. بيشتر ماژول‌هاي تلفن همراه يا موقعيت ياب سنتي تنها باند ارثي L1 GPS را پشتيباني مي‌کنند، در حالي که ماژول‌هاي GPS مدرن هر دو باند L1 و L5 را پشتيباني می‌کنند. KartaCam از باند L5 بهره می‌برد که ساختار سيگنال بهبود يافته، قابليت انتقال و ضيابت عرض باند وسيع تري را فراهم مي‌کند که مي‌تواند خطاي چند مسيري، تداخل و نويز را کاهش دهد. علاوه بر اين، KartaCam از يک آنتن سراميک با کيفيت بالا و دقيق تنظيم شده استفاده مي‌کند که همراه با ماژول GPS دو باند فرکانسي، دقت موقعيت يابي را بهبود مي‌دهد.

نگه‌داشتن اتصال KartaCam

KartaCam دارای یک ماژول 4G LTE داخلی است که تضمین می‌کند همیشه متصل باشد و قابلیت مدیریت از راه دور را داشته باشد. پورتال مدیریت KartaCam می‌تواند تنظیمات دوربین مانند رزولوشن و فواصل ضبط را نظارت کند، حتی در مدل‌های عملیاتی هوش مصنوعی لبه. این امکان را فراهم می‌کند تا تیم عملیات نقشه سازی گرب و رانندگان بتوانند دوربین‌های خود را پیکربندی کرده و تصاویر ضبط شده را به موقع بارگذاری کنند.

تقویت KartaCam

KartaCam 360: ضبط دید پانوراما

برای بهبود کارایی یکباره‌جمعی ضبط، چهار دوربین KartaCam را برای جمع‌آوری تصاویر 360 درجه به همراه می‌آوریم. چهار دوربین می‌توانند تطابق دقیقی در چند میلی‌ثانیه برقرار کنند و تصاویر جمع‌آوری شده در یک دید پانوراما با یکدیگر خوب شوند.

با KartaCam 360، می‌توانیم تعداد تصاویر جمع‌آوری شده را در یک

مقدمه

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

پس زمینه

امروزه، پلتفرم آزمایش‌گری (GrabX) Grab، آزمایش هزاران نمونه آزمایشی در هر هفته را هماهنگ می‌کند. همان‌طور که پلتفرم ادامه می‌یابد و مدیریت حجم رشد آزمایش‌های زیادتر، نیاز به ابزارهای آزمایش قابل اعتماد، قابل مقیاس و قابل اعتماد برای تصمیم‌گیری مبتنی بر داده روز به روز بیشتر می‌شود.

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

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

راه‌حل

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

به ویژه، این مجموعه ابزار یکپارچه به طور قابل توجهی فرآیندهای آزمایش از ابتدا تا انتها را بهبود می‌بخشد، از طریق:

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

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

در بخش بعدی، به عمق در اجزای کلیدی بسته می‌رویم.

جزئیات ویژگی

این بسته شامل سه مؤلفه کلیدی است:

یک مشاور قبل از آزمایشیک مجموعه ابزار جامع برای تجزیه و تحلیل پس از آزمایشابزارهای پیشرفته

این‌ها بر اساس نوع آزمایش هایی که معمولا در Grab انجام می دهیم طراحی شده اند. برای درک قابلیت‌ها خود، مناسب است ابتدا درباره طرح‌های آزمایشی اصلی پشتیبانی شده توسط GrabX صحبت کنیم.

یک یادداشت در مورد طرح‌های آزمایشی

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

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

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

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

مشاور قابل اعتماد

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

طراحی بین-زیرجمعی: ما به شدت توصیه می‌کنیم آزمایش‌گران از قابلیت "مشاور قابل اعتماد" در موتور تصمیم گیری برای برآورد اندازه نمونه مورد نیاز خود استفاده کنند. این برای در نظر گرفتن مشاهدات چندگانه در آزمایش مورد انتظار و تنظیم خطاهای خوشه‌ای (Moffatt، 2020؛ List، Sadoff، & Wagner، 2011) طراحی شده است. این قابلیت به کاربران امکان می دهد تا داده های خود را به عنوان یک چارک یا یک جدول PySpark وارد کنند. به طور جایگزین، یک تابع برای استخراج آماره‌های خلاصه از داده های خود در اختیار کاربران قرار می‌دهد، که سپس می تواند وارد مشاور قابل اعتماد شود. در واقع، بدست آوردن داده قبل از اینکه ضروری نباشد؛ کاربران دارای گزینه‌ای هستند که به طور مستقیم از معیارهای معمول مشتق شده از یک عمومی استخراج شده

مقدمه

در دنیای واقعی، پس از اینکه مسافر سفارش GrabFood را از اپ مجله زیبایی و درمانی آذر ورژن پلیس‌جاده، نماینده-فروشگاه غذا سفارش را آماده می‌کند. سپس یک راننده-نماینده غذا را جمع‌آوری می‌کند و به مسافر تحویل می‌دهد. آیا تا به حال تعجب کرده‌اید که در سیستم پشتیبان چه اتفاقاتی رخ می‌دهد؟ پلتفرم سفارش مجله زیبایی و درمانی آذر ورژن یک سیستم توزیع شده است که هر روز میلیون‌ها سفارش GrabFood یا GrabMart را پردازش می‌کند. این پست به اشتراک گذاشتن سفری است که چگونه ما راه حل پایگاه داده را طراحی کرده‌ایم که این پلتفرم سفارش را تغذیه می‌کند.

زمینه

هدف طراحی هنگام ساخت راه حل پایگاه داده چیست؟ ما با تجزیه الگوها و الگوهای ترافیک نیازها را جمع‌آوری کرده‌ایم.

الگوهای تجزیه الگوها

در ادامه چند نمونه مهم از الگوهای پرس و جوی پلتفرم سفارش وجود دارد:

پرس و جوهای نوشتن:a. ایجاد سفارش.b. به‌روزرسانی سفارش.پرس و جوهای خواندن:a. بر اساس شناسه سفارش سفارش را بگیرید.b. سفارشات جاری را بر اساس شناسه مسافر بگیرید.c. سفارشات تاریخی را بر اساس شرایط مختلف بگیرید.d. آمار سفارش را بگیرید (به عنوان مثال، تعداد سفارش‌ها را دریافت کنید)

می‌توانیم پرس و جوها را به دو دسته تقسیم کنیم: پرس و جوهای تراکنشی و پرس و جوهای تجزیه و تحلیلی. پرس و جوهای تراکنشی برای ایجاد و تکمیل سفارشات آنلاین حیاتی هستند، از جمله پرس و جوهای نوشتن و پرس و جوهای خواندن مانند 2a یا 2b. پرس و جوهای تجزیه و تحلیلی مانند 2c و 2d سفارشات تاریخی یا آمار سفارش را درخواست می‌کند. پرس و جوهای تجزیه و تحلیلی ضروری برای پردازش سفارش در زمان واقعه نیستند.

الگوهای ترافیک

پلتفرم سفارش Grab در هر ماه مقدار قابل توجهی داده تراکنش را پردازش می‌کند.

در ساعات پرشور، پرس و جوهای نوشتن بر ثانیه (QPS) سه برابر مدت‌زمان خواندن کلید اصلی است، در حالی که پرس و جوهای محدوده در ثانیه چهار برابر مدت‌زمان خواندن کلید اصلی است.

اهداف طراحی

از طریق الگوهای پرس و جو و ترافیک، به سه هدف طراحی زیر رسیدیم:

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

راه حل

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

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

برای اطمینان از اینکه داده در هر دو پایگاه داده یکسان است، اصل طراحی دوم راه حل خوراک داده را معرفی می‌کند. در شکل 1، پلتفرم سفارش داده را به پایگاه داده OLTP می‌نویسد تا سفارشات آنلاین را پردازش کند و به صورت ناهمگام داده را به خوراک داده منتقل می‌کند. خوراک داده مطمئن می‌شود که داده پایگاه داده OLAP در نهایت یکنواخت است.

جزئیات معماری

پایگاه داده OLTP

دو دسته از پرس‌و‌جوهای OLTP وجود دارد، پرس‌و‌جوهای کلید-مقدار (برای مثال، بارگذاری بر اساس شناسه سفارش) و پرس‌و‌جوهای دسته‌ای (برای مثال، گرفتن سفارشات جاری بر اساس شناسه مسافر). ما از DynamoDB به عنوان پایگاه داده برای پشتیبانی از این پرس‌و‌جوهای OLTP استفاده می‌کنیم.

چرا DynamoDB؟

قابل مقیاس و با دردسترس بودن بالا: جداول DynamoDB برای پارتیشن بندی هستند و هر پارتیشن به سه برابر کپی می‌شود.پشتیبانی از خواندن قوی در حالت یکپارچه با کلید اصلی.DynamoDB یک مکانیزم به نام ظرفیت تطبیقی دارد که برای کنترل ترافیک هات کی استفاده می‌شود. در داخل، DynamoDB ظرفیت بالاتر را به پارتیشن‌های ترافیک بالا تقسیم می‌کند و موارد مورد نیاز را برای یک پارتیشن اختصاص می‌دهد. به این ترتیب، هات‌کی می‌تواند از ظرفیت کامل یک پارتیشن بهره‌برد، که تا ۳۰۰۰ واحد ظرفیت خواندن و ۱۰۰۰ واحد ظرفیت نوشتن است.

در هر جدول DynamoDB، موارد زیادی با ویژگی‌هایی وجود دارد. در هر مورد، یک کلید بخشی‌کننده و یک کلید مرتب‌سازی وجود دارد. کلید بخشی برای پرس‌و‌جوهای کلید-مقدار استفاده می‌شود و کلید مرتب‌سازی برای پرس‌و‌جوهای محدوده استفاده می‌شود. در مورد ما، جدول شامل چندین مورد سفارش است. کلید بخشی شناسه سفارش است. ما می‌توانیم با استفاده از کلید بخشی به راحتی پرس‌و‌جوهای کلید-مقدار را پشتیبانی کنیم.

پرس و جوهای دسته‌ای مانند 'گرفتن سفارشات جاری بر اساس شناسه مسافر' توسط DynamoDB Global Secondary Index (GSI) پشتیبانی می‌شوند. یک GSI مانند یک جدول عادی DynamoDB است که همچنین شامل کلیدها و ویژگی‌ها است.

در مورد ما، یک جدول GSI وجود دارد که کلید بخشی آن pax_id_gsi است. ویژگی pax_id_gsi به جدول اصلی متصل شده است. این ویژگی در نهایت یکنواخت با جدول اصلی است که توسط DynamoDB نگهداری می‌شود. اگر پلتفرم سفارش سفارشات جاری برای آلیس را پرس‌و‌جو کند، دو مورد از جدول GSI بازگشت داده می‌شود.

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

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

از نظر هزینه، DynamoDB بر اساس اندازه ذخیره سازی و امکانات خواندن و نوشتن محاسبه می‌شود. قابلیت امکانات در واقع قابلیت مقیاسپذیر است. هزینه درخواستی است. بنابراین، به طور کلی ارزانتر از RDS است.

پایگاه داده OLAP

ما از MySQL RDS به عنوان پایگاه داده برای پشتیبانی از پرس‌و‌جوهای تاریخی و آماری OLAP استفاده می‌کنیم.

چرا آورورا نه؟ ما معمولاً RDS را انتخاب می‌کنیم زیرا یک راه‌حل پایدار پایگاه داده است. حتی اگر آورورا قابلیت دردسترس بالاتری را ارائه دهد، RDS کافی است برای پشتیبانی از موارد کمتر بحرانی ما. هزینه‌به‌تفاوت‌قیمت آورورا، بر اساس ذخیره سازی داده و تعداد