مدل داده، ROLLUP و فهرست پیشوند

  • 2021-05-11

این سند مدل داده، ROLLUP و مفاهیم شاخص پیشوند دوریس را در سطح منطقی توصیف می‌کند تا به کاربران کمک کند از Doris بهتر برای مقابله با سناریوهای مختلف تجاری استفاده کنند.

مفاهیم اساسی

در Doris، داده ها به طور منطقی در قالب جداول توصیف می شوند. یک جدول از سطرها و ستون ها تشکیل شده است. ردیف ردیفی از داده های کاربر است. ستون برای توصیف فیلدهای مختلف در یک ردیف از داده ها استفاده می شود.

ستون ها را می توان به دو دسته تقسیم کرد: کلید و ارزش. از منظر تجاری، کلید و ارزش می توانند به ترتیب با ستون های ابعاد و ستون های نشانگر مطابقت داشته باشند.

مدل داده دوریس به سه دسته اصلی تقسیم می شود:

بیایید آنها را جداگانه معرفی کنیم.

مدل کل

مدل تجمیع چیست و نحوه استفاده صحیح از آن را با مثال های عملی نشان می دهیم.

مثال 1: وارد کردن تجمیع داده ها

فرض کنید که کسب و کار دارای جدول داده های زیر است:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربریبزرگ شناسه کاربری
تاریختاریخ تاریخ پر کردن داده ها
شهرVARCHAR (20) شهر کاربر
سنکوچک سن کاربر
ارتباط جنسیTINYINT جنسیت کاربر
آخرین_تاریخ_بازدیدوقت قرارجایگزین کردنآخرین زمان دسترسی کاربر
هزینهBIGINTجمعکل مصرف کاربر
حداکثر زمان ماندنINTحداکثرحداکثر زمان اقامت کاربر
دقیقه زمان اقامتINTMINحداقل زمان اقامت کاربر

اگر به دستور جدول سازی تبدیل شود، موارد زیر انجام می شود (اطلاعات پارتیشن و توزیع در دستور جدول سازی حذف می شود)

همانطور که می بینید، این یک جدول واقعی اطلاعات کاربر و رفتار دسترسی است. در مدل کلی ستاره، اطلاعات کاربر و رفتار دسترسی به ترتیب در جدول ابعاد و جدول واقعیت ذخیره می شوند. در اینجا، برای توضیح راحت‌تر مدل داده‌های دوریس، دو بخش اطلاعات را در یک جدول ذخیره می‌کنیم.

ستون های جدول بر اساس تنظیم یا عدم تنظیم AggregationType به کلید (ستون ابعاد) و مقدار (ستون نشانگر) تقسیم می شوند. هیچ AggregationType، مانند user_id، تاریخ، سن و غیره، به عنوان کلید تنظیم نشده است، در حالی که نوع Aggregation به عنوان مقدار تنظیم شده است.

وقتی داده‌ها را وارد می‌کنیم، همان ردیف‌ها و تجمیع‌ها در یک ردیف برای ستون Key، در حالی که ستون Value مطابق مجموعه AggregationType جمع می‌شود. AggregationType در حال حاضر چهار روش زیر را برای تجمیع دارد:

  1. SUM: جمع، انباشت ارزش چند خطی.
  2. REPLACE: در عوض، مقادیر در دسته بعدی داده جایگزین مقادیر در ردیف‌هایی که قبلاً وارد شده‌اند می‌شوند.
  3. MAX: حداکثر را حفظ کنید.
  4. MIN: حداقل را حفظ کنید.

فرض کنید داده‌های وارداتی زیر (داده‌های خام) را داریم:

شناسه کاربریتاریخشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-2017پکن2002017-10-01 06:00201010
1000001-10-2017پکن2002017-10-01 07:001522
1000101-10-2017پکن3012017-10-01 17:05:4522222
1000202-10-2017شانگهای2012017-10-02 12:59:1220055
1000302-10-2017گوانگژو3202017-10-02 11:20:00301111
1000401-10-2017شنژن3502017-10-01 10:00:1510033
1000403/10/2017شنژن3502017-10-03 10:20:221166

بیایید فرض کنیم که این جدولی است که رفتار کاربر در دسترسی به صفحه کالا را ثبت می کند. بیایید ردیف اول داده ها را به عنوان مثال در نظر بگیریم و آن را به صورت زیر توضیح دهیم:

داده هاشرح
10000شناسه کاربر، هر کاربر به طور منحصر به فرد شناسه را شناسایی می کند
01-10-2017زمان ذخیره سازی داده ها، دقیق تا به امروز
پکنشهر کاربر
20سن کاربر
0جنسیت مرد (1 برای زن)
2017-10-01 06:00زمان بازدید کاربر از این صفحه، دقیق به ثانیه
20مصرف ایجاد شده توسط بازدید فعلی کاربر
10بازدید کاربر، زمان ماندن در صفحه
10بازدید فعلی کاربر، زمان صرف شده در صفحه (اضافه)

سپس وقتی این دسته از داده ها به درستی به Doris وارد شد، ذخیره سازی نهایی در Doris به صورت زیر است:

شناسه کاربریتاریخشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-2017پکن2002017-10-01 07:0035102
1000101-10-2017پکن3012017-10-01 17:05:4522222
1000202-10-2017شانگهای2012017-10-02 12:59:1220055
1000302-10-2017گوانگژو3202017-10-02 11:20:00301111
1000401-10-2017شنژن3502017-10-01 10:00:1510033
1000403/10/2017شنژن3502017-10-03 10:20:221166

همانطور که می بینید، تنها یک خط داده جمع آوری شده برای 10000 کاربر باقی مانده است. داده های سایر کاربران با داده های اصلی مطابقت دارد. در اینجا ابتدا داده های جمع آوری شده کاربر 10000 را توضیح می دهیم:

پنج ستون اول بدون تغییر باقی می‌مانند و با ستون 6 «آخرین_تاریخ_بازدید» شروع می‌شوند:

* 2017-10-01 07:00 : از آنجا که ستون last_visit_date توسط REPLACE جمع‌آوری می‌شود، ستون 07:00 2017-10-01 با «06:00-10-2017» جایگزین شده است.

توجه: برای داده ها در همان دسته وارداتی، ترتیب جایگزینی برای تجمیع REPLACE تضمین نمی شود. به عنوان مثال، در این مورد، ممکن است '2017-10-01 06:00' باشد. برای داده های دسته های مختلف وارداتی، می توان تضمین کرد که داده های دسته دوم جایگزین دسته قبلی خواهد شد.

35 : چون نوع تجمیع ستون 'cost' SUM است، 35 از 20 + 15 جمع می شود. از آنجا که نوع تجمع ستون min_dwell_time MIN است، 10 و 2 حداقل مقدار را می گیرند و 2 می گیرند.

پس از تجمیع، دوریس در نهایت تنها داده های انباشته شده را ذخیره می کند. به عبارت دیگر، داده های دقیق از بین خواهند رفت و کاربران دیگر نمی توانند اطلاعات دقیق را قبل از تجمیع پرس و جو کنند.

مثال 2: داده های دقیق را نگه دارید

به دنبال مثال 1، ساختار جدول را به صورت زیر تغییر می دهیم:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربریبزرگ شناسه کاربری
تاریختاریخ تاریخ پر کردن داده ها
مهر زمانوقت قرار زمان پر کردن داده ها، دقیق به ثانیه
شهرVARCHAR (20) شهر کاربر
سنکوچک سن کاربر
ارتباط جنسیTINYINT جنسیت کاربر
آخرین تاریخ بازدیدوقت قرارجایگزین کردنآخرین زمان دسترسی کاربر
هزینهBIGINTجمعکل مصرف کاربر
حداکثر زمان ماندنINTحداکثرحداکثر زمان اقامت کاربر
دقیقه زمان اقامتINTMINحداقل زمان اقامت کاربر

به این معنی که یک ستون از مهر زمانی اضافه شده است تا زمان پر کردن داده ها را با دقت به ثانیه ثبت کند.

داده های وارد شده به شرح زیر است:

شناسه کاربریتاریخمهر زمانیشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-20172017-10-01 08:00:05پکن2002017-10-01 06:00201010
1000001-10-20172017-10-01 09:00:05پکن2002017-10-01 07:001522
1000101-10-20172017-10-01 18:12:10پکن3012017-10-01 17:05:4522222
1000202-10-20172017-10-02 13:10:00شانگهای2012017-10-02 12:59:1220055
1000302-10-20172017-10-02 13:15:00گوانگژو3202017-10-02 11:20:00301111
1000401-10-20172017-10-01 12:12:48شنژن3502017-10-01 10:00:1510033
1000403/10/20172017-10-03 12:38:20شنژن3502017-10-03 10:20:221166

سپس وقتی این دسته از داده ها به درستی به Doris وارد شد، ذخیره سازی نهایی در Doris به صورت زیر است:

شناسه کاربریتاریخمهر زمانیشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-20172017-10-01 08:00:05پکن2002017-10-01 06:00201010
1000001-10-20172017-10-01 09:00:05پکن2002017-10-01 07:001522
1000101-10-20172017-10-01 18:12:10پکن3012017-10-01 17:05:4522222
1000202-10-20172017-10-02 13:10:00شانگهای2012017-10-02 12:59:1220055
1000302-10-20172017-10-02 13:15:00گوانگژو3202017-10-02 11:20:00301111
1000401-10-20172017-10-01 12:12:48شنژن3502017-10-01 10:00:1510033
1000403/10/20172017-10-03 12:38:20شنژن3502017-10-03 10:20:221166

می بینیم که داده های ذخیره شده، درست مانند داده های وارد شده، اصلاً جمع نمی شوند. دلیلش این است که در این دسته از داده ها، چون ستون مهر زمان اضافه شده است، کلیدهای همه ردیف ها دقیقاً یکسان نیستند. یعنی تا زمانی که کلیدهای هر ردیف در داده های وارد شده یکسان نباشند، دوریس می تواند اطلاعات کامل را حتی در مدل تجمیع ذخیره کند.

مثال 3: وارد کردن داده ها و تجمیع داده های موجود

مثال 1 را در نظر بگیرید. فرض کنید که داده های جدول به شرح زیر است:

شناسه کاربریتاریخشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-2017پکن2002017-10-01 07:0035102
1000101-10-2017پکن3012017-10-01 17:05:4522222
1000202-10-2017شانگهای2012017-10-02 12:59:1220055
1000302-10-2017گوانگژو3202017-10-02 11:20:00301111
1000401-10-2017شنژن3502017-10-01 10:00:1510033
1000403/10/2017شنژن3502017-10-03 10:20:221166

ما مجموعه جدیدی از داده ها را وارد کردیم:

شناسه کاربریتاریخشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000403/10/2017شنژن3502017-10-03 11:22:00441919
1000503/10/2017چانگشا2912017-10-03 18:11:02311

سپس وقتی این دسته از داده ها به درستی به Doris وارد شد، ذخیره سازی نهایی در Doris به صورت زیر است:

شناسه کاربریتاریخشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-2017پکن2002017-10-01 07:0035102
1000101-10-2017پکن3012017-10-01 17:05:4522222
1000202-10-2017شانگهای2012017-10-02 12:59:1220055
1000302-10-2017گوانگژو3202017-10-02 11:20:00301111
1000401-10-2017شنژن3502017-10-01 10:00:1510033
1000403/10/2017شنژن3502017-10-03 11:22:0055196
1000503/10/2017چانگشا2912017-10-03 18:11:02311

همانطور که مشاهده می کنید ، داده های موجود و داده های تازه وارد شده کاربر 10004 جمع شده اند. در همین زمان ، 10005 داده کاربر جدید اضافه شد.

تجمع داده ها در سه مرحله زیر در دوریس رخ می دهد:

  1. مرحله ETL واردات داده برای هر دسته. این مرحله داده ها را در هر دسته از داده های وارداتی جمع می کند.
  2. مرحله ای که زیربنایی در آن قرار دارد ، تراکم داده ها را انجام می دهد. در این مرحله ، داده های جمع آوری شده از دسته های مختلف وارد شده است.
  3. مرحله پرس و جو داده. در پرس و جو داده ، داده های درگیر در پرس و جو بر این اساس جمع می شوند.

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

مدل یکپارچه

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

نام ستونتایپ کنیدبدناماظهار نظر
شناسه کاربریBIGINTآرهشناسه کاربری
نام کاربریوارچار (50)آرهنام مستعار کاربر
شهرVARCHAR (20)Noشهر کاربر
سنکوچکNoسن کاربر
ارتباط جنسیTINYINTNoجنس کاربر
تلفنبزرگNoتلفن کاربری
نشانیوارچار (500)Noآدرس کاربر
زمان ثبت ناموقت قرارNoزمان ثبت نام کاربر

این یک جدول اطلاعات معمولی پایه کاربر است. برای این نوع داده ها هیچ الزام تجمیعی وجود ندارد ، فقط منحصر به فرد بودن کلید اصلی تضمین می شود.(کلید اصلی در اینجا user_id + نام کاربری است). سپس بیانیه ما به شرح زیر است:

این ساختار جدول دقیقاً مشابه ساختار جدول زیر است که توسط مدل تجمع شرح داده شده است:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربریBIGINT شناسه کاربری
نام کاربریوارچار (50) نام مستعار کاربر
شهرVARCHAR (20)جایگزین کردنشهر کاربر
سنکوچکجایگزین کردنسن کاربر
ارتباط جنسیTINYINTجایگزین کردنجنس کاربر
تلفنبزرگجایگزین کردنتلفن کاربری
نشانیوارچار (500)جایگزین کردنآدرس کاربر
زمان ثبت ناموقت قرارجایگزین کردنزمان ثبت نام کاربر

و اظهارات میز سازی:

یعنی ، مدل UNIQ را می توان با جایگزینی در مدل تجمع به طور کامل جایگزین کرد. اجرای داخلی آن و ذخیره داده ها دقیقاً یکسان است. در اینجا نمونه های دیگری ارائه نمی شود.

مدل تکراری

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

نام ستونتایپ کنیدکلیداظهار نظر
ساقهوقت قرارآرهزمان ورود به سیستم
تایپ کنیدINTآرهنوع ورود به سیستم
کد خطاINTآرهکد خطا
error_msgوارچار (1024)Noجزئیات خطا
op_idBIGINTNoشناسه اپراتور
Op_timeوقت قرارNoزمان عمل

عبارت جدول به شرح زیر است:

این مدل داده با مدل های کل و UNIQ متفاوت است. داده ها کاملاً مطابق با داده های موجود در پرونده وارد شده و بدون هیچ گونه تجمع ذخیره می شوند. حتی اگر دو ردیف داده یکسان باشد ، آنها حفظ می شوند. کلید کپی مشخص شده در بیانیه جدول ساختمان فقط برای مشخص کردن کدام ستون داده های زیرین مطابق با آنها استفاده می شود.(نام مناسب تر باید "ستون مرتب شده" باشد ، جایی که از نام "کلید تکراری" برای مشخص کردن مدل داده مورد استفاده استفاده می شود. برای توضیحات بیشتر در مورد "ستون مرتب شده" ، به فهرست پیشوند بخش مراجعه کنید. در انتخاب کلید تکراری ،توصیه می کنیم ستون های 2-4 اول به طور مناسب انتخاب شوند.

این مدل داده برای ذخیره داده های خام بدون الزامات جمع آوری و محدودیت های منحصر به فرد اصلی اصلی مناسب است. برای سناریوهای بیشتر استفاده ، به محدودیت های بخش مدل جمع آوری مراجعه کنید.

غلتک

Rollup در تجزیه و تحلیل چند بعدی به معنای "پیمایش به بالا" است ، به این معنی که داده ها در یک دانه بندی مشخص بیشتر جمع می شوند.

مفاهیم اساسی

در دوریس ، جدول ایجاد شده توسط کاربر را از طریق بیانیه جدول ساختمان یک جدول پایه ایجاد می کنیم. جدول پایه داده های اصلی ذخیره شده به روشی را که توسط بیانیه میز سازی کاربر مشخص شده است ، نگه می دارد.

در بالای جدول پایه ، می توانیم تعداد میزهای جمع آوری را ایجاد کنیم. این داده های Rollup بر اساس جدول پایه تولید می شوند و از نظر جسمی به طور مستقل ذخیره می شوند.

عملکرد اصلی جداول رول ، به دست آوردن داده های درشت تر بر اساس جداول پایه است.

بیایید جداول Rollup و نقش آنها را در مدل های مختلف داده با مثال نشان دهیم.

در مدل کل و مدل uniq

از آنجا که Uniq فقط یک مورد خاص از مدل کل است ، ما آن را در اینجا تشخیص نمی دهیم.

مثال 1: کل مصرف را برای هر کاربر دریافت کنید

به عنوان مثال 2 در بخش مدل کل ، ساختار جدول پایه به شرح زیر است:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربریبزرگ شناسه کاربری
تاریختاریخ تاریخ پر کردن داده ها
مهر زمانوقت قرار زمان پر کردن داده ها، دقیق به ثانیه
شهرVARCHAR (20) شهر کاربر
سنکوچک سن کاربر
ارتباط جنسیTINYINT جنسیت کاربر
آخرین_تاریخ_بازدیدوقت قرارجایگزین کردنآخرین زمان دسترسی کاربر
هزینهBIGINTجمعکل مصرف کاربر
حداکثر زمان ماندنINTحداکثرحداکثر زمان اقامت کاربر
دقیقه زمان اقامتINTMINحداقل زمان اقامت کاربر

داده های ذخیره شده به شرح زیر است:

شناسه کاربریتاریخمهر زمانیشهرسنارتباط جنسیآخرین _ بازدید _ تاریخهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
1000001-10-20172017-10-01 08:00:05پکن2002017-10-01 06:00201010
1000001-10-20172017-10-01 09:00:05پکن2002017-10-01 07:001522
1000101-10-20172017-10-01 18:12:10پکن3012017-10-01 17:05:4522222
1000202-10-20172017-10-02 13:10:00شانگهای2012017-10-02 12:59:1220055
1000302-10-20172017-10-02 13:15:00گوانگژو3202017-10-02 11:20:00301111
1000401-10-20172017-10-01 12:12:48شنژن3502017-10-01 10:00:1510033
1000403/10/20172017-10-03 12:38:20شنژن3502017-10-03 10:20:221166

بر این اساس ، ما یک رول ایجاد می کنیم:

نام ستون
شناسه کاربری
هزینه

Rollup فقط شامل دو ستون است: user_id و هزینه. پس از ایجاد ، داده های ذخیره شده در Rollup به شرح زیر است:

شناسه کاربریهزینه
1000035
100012
10002200
1000330
10004111

همانطور که مشاهده می کنید ، Rollup فقط نتایج جمع را در ستون هزینه برای هر User_Id حفظ می کند. بنابراین وقتی درخواست زیر را انجام می دهیم:

user_id ، جمع (هزینه) را از گروه جدول توسط user_id انتخاب کنید.

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

  1. مثال 2: دریافت کل مصرف، طولانی ترین و کوتاه ترین زمان اقامت صفحه کاربران در سنین مختلف در شهرهای مختلف

مثال 1 را دنبال کنید. بر اساس جدول Base، یک ROLLUP ایجاد می کنیم:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شهرVARCHAR (20) شهر کاربر
سنکوچک سن کاربر
هزینهBIGINTجمعکل مصرف کاربر
حداکثر زمان ماندنINTحداکثرحداکثر زمان اقامت کاربر
دقیقه زمان اقامتINTMINحداقل زمان اقامت کاربر

پس از ایجاد، داده های ذخیره شده در ROLLUP به شرح زیر است:

شهرسنهزینهحداکثر _ سکونت _ زماندقیقه _ سکونت _ زمان
پکن2003010
پکن301222
شانگهای2012005
گوانگژو3203011
شنژن3501116

وقتی پرس و جوهای زیر را انجام می دهیم:

  • شهر، سن، مجموع (هزینه)، حداکثر (حداکثر زمان اقامت)، حداقل (دقیقه زمان اقامت) را از گروه جدول بر اساس شهر، سن انتخاب کنید؛*
  • انتخاب شهر، مجموع(هزینه)، حداکثر(حداکثر_زمان_سکونت)، حداقل(دقیقه_زمان_سکونت) FROM جدول GROUP BY BY;
  • انتخاب شهر، سن، مجموع (هزینه)، حداقل (دقیقه_زمان_سکونت) FROM جدول GROUP BY BY، سن؛

دوریس به طور خودکار به جدول ROLLUP ضربه می زند.

ROLLUP در مدل تکراری

زیرا مدل Duplicate هیچ معنایی مجموعی ندارد. بنابراین ROLLLUP در این مدل معنای "scroll up" را از دست داده است. این فقط برای تنظیم ترتیب ستون برای ضربه زدن به شاخص پیشوند است. در بخش بعدی به طور مفصل به معرفی شاخص پیشوند و نحوه استفاده از ROLLUP برای تغییر شاخص پیشوند برای دستیابی به کارایی بهتر پرس و جو می پردازیم.

پیشوند فهرست و ROLLUP

نمایه پیشوند

برخلاف طراحی سنتی پایگاه داده، Doris از نمایه سازی در هیچ ستونی پشتیبانی نمی کند. پایگاه های داده OLAP مبتنی بر معماری MPP مانند Doris معمولاً حجم زیادی از داده ها را با بهبود همزمانی مدیریت می کنند. در اصل، داده های Doris در یک ساختار داده مشابه SSTable (جدول رشته های مرتب شده) ذخیره می شود. این ساختار یک ساختار داده مرتب شده است که می تواند طبق ستون مشخص شده مرتب شده و ذخیره شود. در این ساختار داده، جستجو با مرتب سازی ستون ها بسیار کارآمد است.

در سه مدل داده Aggregate، Uniq و Duplicate. ذخیره سازی داده های زیربنایی طبق ستون های مشخص شده در AGGREGATE KEY، UNIQ KEY و DUPLICATE KEY در دستورات جدول سازی مربوطه مرتب شده و ذخیره می شود.

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

ما از شاخص پیشوند 36 بایتی از یک ردیف داده به عنوان شاخص پیشوند این ردیف داده استفاده می کنیم. وقتی با یک نوع VARCHAR مواجه می‌شویم، شاخص پیشوند مستقیماً کوتاه می‌شود. مثال هایی می آوریم تا توضیح دهیم:

  1. نمایه پیشوند ساختار جدول زیر user_id (8Byte) + age (8Bytes) + message (پیشوند 20 Bytes) است.
  1. شاخص پیشوند ساختار جدول زیر user_name (20 بایت) است. حتی اگر به 36 بایت نرسد ، زیرا با Varchar روبرو می شود ، مستقیماً کوتاه می شود و دیگر ادامه نمی یابد.

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

* را از جدول جایی که user_id = 1829239 و سن = 20 ؛

کارآیی این پرس و جو بسیار بالاتر از ** پرس و جوهای زیر است:

* را از جدول انتخاب کنید که در آن سن = 20 ؛

بنابراین ، هنگام ساخت جداول ، انتخاب صحیح ترتیب ستون می تواند کارایی پرس و جو را تا حد زیادی بهبود بخشد.

Rollup شاخص پیشوند را تنظیم می کند

از آنجا که ترتیب ستون هنگام ساخت یک جدول مشخص شده است ، فقط یک فهرست پیشوند برای یک جدول وجود دارد. این ممکن است برای نمایش داده شدگان که از ستون های دیگری استفاده می کنند که نمی توانند به عنوان شرایط به شاخص های پیشوند ضربه بزنند ، ناکارآمد باشد. بنابراین ، ما می توانیم با ایجاد Rollup ، ترتیب ستون ها را به صورت دستی تنظیم کنیم. نمونه هایی آورده شده است.

ساختار جدول پایه به شرح زیر است:

نام ستونتایپ کنید
شناسه کاربریBIGINT
سنINT
پیاموارچار (100)
حداکثر _ سکونت _ زمانوقت قرار
دقیقه _ سکونت _ زمانوقت قرار

بر این اساس ، ما می توانیم یک جدول Rollup ایجاد کنیم:

نام ستونتایپ کنید
سنINT
شناسه کاربریBIGINT
پیاموارچار (100)
حداکثر _ سکونت _ زمانوقت قرار
دقیقه _ سکونت _ زمانوقت قرار

همانطور که مشاهده می کنید ، ستون های جداول Rollup و Base دقیقاً یکسان هستند ، فقط تغییر ترتیب user_id و سن. بنابراین وقتی درخواست زیر را انجام می دهیم:

* را از جدول انتخاب کنید که در آن سن = 20 و ماساژ مانند "٪ Error ٪" ؛

جدول Rollup ترجیح داده می شود زیرا شاخص پیشوند مطابقت بهتر است.

برخی از توضیحات مربوط به رول

  • نقش اساسی Rollup در بهبود کارآیی پرس و جو برخی از نمایش داده شد (چه با جمع کردن برای کاهش میزان داده ها یا با تغییر ترتیب ستون برای مطابقت با شاخص های پیشوند). بنابراین ، معنای رولپ فراتر از محدوده "رول کردن" است. به همین دلیل ما آن را در کد منبع معرفی کردیم.
  • Rollup به جدول پایه وصل شده است و می تواند به عنوان یک ساختار داده کمکی جدول پایه دیده شود. کاربران می توانند بر اساس جدول پایه ، رولپ را ایجاد یا حذف کنند ، اما به صراحت نمی توانند پرس و جو را برای جمع آوری پرس و جو مشخص کنند. این که آیا Rollup مورد اصابت قرار گرفته است یا خیر ، کاملاً توسط سیستم Doris تعیین می شود.
  • داده های Rollup در ذخیره سازی فیزیکی جداگانه ذخیره می شوند. بنابراین ، هرچه تعداد بیشتری از آنها ایجاد کنید ، فضای دیسک بیشتری را اشغال می کنید. همچنین در سرعت واردات تأثیر دارد (مرحله ETL واردات به طور خودکار تمام داده های رول را تولید می کند) ، اما باعث کاهش کارآیی پرس و جو (فقط بهتر) نمی شود.
  • به روزرسانی داده ها برای Rollup کاملاً با بازنمایی های پایه هماهنگ شده است. کاربران نیازی به اهمیت این مشکل ندارند.
  • ستون های موجود در Rollup دقیقاً به همان روش جداول پایه جمع می شوند. در هنگام ایجاد آن نیازی به مشخص کردن یا اصلاح Rollup نیست.
  • شرط لازم (ناکافی) برای پرس و جو برای ضربه زدن به Rollup این است که همه ستون ها ** (از جمله ستون های وضعیت پرس و جو در لیست انتخاب و مکان) که در پرس و جو درگیر در ستون Rollup وجود دارد. در غیر این صورت ، پرس و جو فقط می تواند به جدول پایه ضربه بزند.
  • انواع خاصی از نمایش داده شد (مانند Count (*)) نمی توانند تحت هر شرایطی به صورت رول ضربه بزنند. محدودیت های بخش بعدی مدل جمع آوری را ببینید.
  • برنامه اجرای پرس و جو را می توان با توضیح your_sql بدست آورد. فرمان ، و در برنامه اجرای ، خواه مورد ضرب و شتم قرار گرفته باشد یا خیر.
  • جداول پایه و کلیه Rollup ایجاد شده را می توان با استفاده از desc tbl_name همه نمایش داد. بیانیه.

در این سند ، می توانید پرس و جو را ببینید که چگونه می توانید Rollup را بزنید

محدودیت های مدل تجمع

در اینجا ما محدودیت های مدل کل (از جمله مدل UNIQ) را معرفی می کنیم.

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

جدول فرضیه به شرح زیر ساختار یافته است:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربریبزرگ شناسه کاربری
تاریختاریخ تاریخ پر کردن داده ها
هزینهBIGINTجمعکل مصرف کاربر

فرض کنید که دو دسته از داده ها وجود دارد که به شرح زیر به موتور ذخیره سازی وارد شده اند:

دسته 1

شناسه کاربریتاریخهزینه
100012017-11-2050
100022017-11-2139

دسته 2

شناسه کاربریتاریخهزینه
100012017-11-201
100012017-11-215
100032017-11-2222

همانطور که مشاهده می کنید ، داده های متعلق به کاربر 10001 در دو دسته واردات هنوز جمع نشده است. با این حال ، به منظور اطمینان از اینکه کاربران فقط می توانند از داده های جمع شده به شرح زیر پرس و جو کنند:

شناسه کاربریتاریخهزینه
100012017-11-2051
100012017-11-215
100022017-11-2139
100032017-11-2222

ما اپراتور جمع آوری را به موتور پرس و جو برای اطمینان از سازگاری داده ها اضافه می کنیم.

علاوه بر این ، در ستون کل (مقدار) ، هنگام اجرای نمایش داده های کلاس کل که با انواع کل مغایر هستند ، باید به معناشناسی توجه شود. به عنوان مثال ، در مثال بالا ، نمایش داده های زیر را اجرا می کنیم:

حداقل (هزینه) را از جدول انتخاب کنید.

نتیجه 5 است ، نه 1.

در عین حال ، این ضمانت قوام در برخی از نمایش داده ها باعث کاهش بازده پرس و جو می شود.

بیایید به عنوان نمونه ابتدایی ترین تعداد (*) پرس و جو را بگیریم:

شمارش (*) را از جدول انتخاب کنید.

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

بیایید داده ها را به عنوان نمونه بگیریم.

دسته 1

شناسه کاربریتاریخهزینه
100012017-11-2050
100022017-11-2139

دسته 2

شناسه کاربریتاریخهزینه
100012017-11-201
100012017-11-215
100032017-11-2222

از آنجا که نتیجه تجمع نهایی:

شناسه کاربریتاریخهزینه
100012017-11-2051
100012017-11-215
100022017-11-2139
100032017-11-2222

بنابراین تعداد (*) را از جدول انتخاب کنید. نتیجه صحیح باید 4 باشد. اما اگر فقط «user_id'column را اسکن کنیم و جمع آوری پرس و جو را اضافه کنیم ، نتیجه نهایی 3 (10001 ، 10002 ، 10003) است. در صورت جمع شدن بدون پرس و جو ، نتیجه 5 است (در مجموع پنج ردیف در دو دسته). مشاهده می شود که هر دو نتیجه اشتباه هستند.

برای به دست آوردن نتیجه صحیح ، باید داده های user_id و تاریخ را بخوانیم و به همراه جمع در هنگام پرس و جو ، برای بازگشت نتیجه صحیح 4. یعنی در پرس و جو Count () ، دوریس باید تمام ستون های کلیدی کل (در اینجا user_id و تاریخ) را اسکن کند و آنها را جمع کند تا نتایج درستی را بدست آورد. هنگامی که ستونهای جمع شده بزرگ هستند ، تعداد زیادی از داده ها نیاز به اسکن مقدار زیادی از داده ها دارند.

بنابراین ، هنگامی که نمایش داده های مکرر () در تجارت وجود دارد ، توصیه می کنیم کاربران را با اضافه کردن یک ستون با مقدار 1 و نوع جمع جمع ، تعداد () را شبیه سازی کنند. به عنوان ساختار جدول در مثال قبلی ، ما آن را به شرح زیر تغییر می دهیم:

نام ستونتایپ کنیدAggregationTypeاظهار نظر
شناسه کاربرBIGINT شناسه کاربری
تاریختاریخ تاریخ پر کردن داده ها
هزینهBIGINTجمعکل مصرف کاربر
شمردنBIGINTجمعبرای شمارش

یک ستون شمارش اضافه کرده و داده ها را با مقدار ستون برابر با 1 وارد کنید. نتیجه شمارش (*) از جدول ؛معادل انتخاب جمع (تعداد) از جدول است. راندمان پرس و جو از دومی بسیار بالاتر از سابق است. با این حال ، این روش همچنین محدودیت هایی دارد ، یعنی کاربران باید تضمین کنند که آنها به طور مکرر ردیف هایی را با همان ستون کلیدی کل وارد نمی کنند. در غیر این صورت ، جمع (تعداد) را از جدول انتخاب کنید. فقط می تواند تعداد ردیف هایی را که در ابتدا وارد شده اند بیان کنند ، نه معناشناسی شمارش (*) از جدول.

راه دیگر تغییر نوع تجمع ستون شمارش در بالا برای جایگزینی است و هنوز هم وزن 1 است. سپس جمع (تعداد) را از جدول انتخاب کنید. و شمارش (*) را از جدول انتخاب کنید. نتایج سازگار خواهد بود. و از این طریق ، هیچ محدودیتی در واردات ردیف های تکراری وجود ندارد.

مدل تکراری

مدل تکراری محدودیتی از مدل تجمع ندارد. از آنجا که این مدل شامل معناشناسی کل نیست ، هنگام انجام پرس و جو شمارش (*) ، می توانیم با انتخاب ستونی از نمایش داده ها به طور خودسرانه ، معنایی صحیح را بدست آوریم.

پیشنهادات انتخاب مدل داده

از آنجا که مدل داده هنگام ساخت جدول ایجاد شد و قابل تغییر نیست. بنابراین ، انتخاب یک مدل داده مناسب ** بسیار مهم است.

برچسب ها

ثبت دیدگاه

مجموع دیدگاهها : 0در انتظار بررسی : 0انتشار یافته : ۰
قوانین ارسال دیدگاه
  • دیدگاه های ارسال شده توسط شما، پس از تایید توسط تیم مدیریت در وب منتشر خواهد شد.
  • پیام هایی که حاوی تهمت یا افترا باشد منتشر نخواهد شد.
  • پیام هایی که به غیر از زبان فارسی یا غیر مرتبط باشد منتشر نخواهد شد.