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

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

مفاهیم اساسی

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

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

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

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

مدل کل

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

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

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

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

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

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

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

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

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

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

شناسه کاربری	تاریخ	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	پکن	20	0	2017-10-01 06:00	20	10	10
10000	01-10-2017	پکن	20	0	2017-10-01 07:00	15	2	2
10001	01-10-2017	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	شنژن	35	0	2017-10-03 10:20:22	11	6	6

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

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

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

شناسه کاربری	تاریخ	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	پکن	20	0	2017-10-01 07:00	35	10	2
10001	01-10-2017	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	شنژن	35	0	2017-10-03 10:20:22	11	6	6

همانطور که می بینید، تنها یک خط داده جمع آوری شده برای 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	حداکثر	حداکثر زمان اقامت کاربر
دقیقه زمان اقامت	INT	MIN	حداقل زمان اقامت کاربر

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

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

شناسه کاربری	تاریخ	مهر زمانی	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	2017-10-01 08:00:05	پکن	20	0	2017-10-01 06:00	20	10	10
10000	01-10-2017	2017-10-01 09:00:05	پکن	20	0	2017-10-01 07:00	15	2	2
10001	01-10-2017	2017-10-01 18:12:10	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	2017-10-02 13:10:00	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	2017-10-02 13:15:00	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	2017-10-01 12:12:48	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	2017-10-03 12:38:20	شنژن	35	0	2017-10-03 10:20:22	11	6	6

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

شناسه کاربری	تاریخ	مهر زمانی	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	2017-10-01 08:00:05	پکن	20	0	2017-10-01 06:00	20	10	10
10000	01-10-2017	2017-10-01 09:00:05	پکن	20	0	2017-10-01 07:00	15	2	2
10001	01-10-2017	2017-10-01 18:12:10	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	2017-10-02 13:10:00	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	2017-10-02 13:15:00	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	2017-10-01 12:12:48	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	2017-10-03 12:38:20	شنژن	35	0	2017-10-03 10:20:22	11	6	6

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

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

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

شناسه کاربری	تاریخ	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	پکن	20	0	2017-10-01 07:00	35	10	2
10001	01-10-2017	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	شنژن	35	0	2017-10-03 10:20:22	11	6	6

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

شناسه کاربری	تاریخ	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10004	03/10/2017	شنژن	35	0	2017-10-03 11:22:00	44	19	19
10005	03/10/2017	چانگشا	29	1	2017-10-03 18:11:02	3	1	1

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

شناسه کاربری	تاریخ	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	پکن	20	0	2017-10-01 07:00	35	10	2
10001	01-10-2017	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	شنژن	35	0	2017-10-03 11:22:00	55	19	6
10005	03/10/2017	چانگشا	29	1	2017-10-03 18:11:02	3	1	1

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

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

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

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

مدل یکپارچه

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

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

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

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

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

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

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

مدل تکراری

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

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

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

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

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

غلتک

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

مفاهیم اساسی

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

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

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

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

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

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

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

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

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

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

شناسه کاربری	تاریخ	مهر زمانی	شهر	سن	ارتباط جنسی	آخرین _ بازدید _ تاریخ	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
10000	01-10-2017	2017-10-01 08:00:05	پکن	20	0	2017-10-01 06:00	20	10	10
10000	01-10-2017	2017-10-01 09:00:05	پکن	20	0	2017-10-01 07:00	15	2	2
10001	01-10-2017	2017-10-01 18:12:10	پکن	30	1	2017-10-01 17:05:45	2	22	22
10002	02-10-2017	2017-10-02 13:10:00	شانگهای	20	1	2017-10-02 12:59:12	200	5	5
10003	02-10-2017	2017-10-02 13:15:00	گوانگژو	32	0	2017-10-02 11:20:00	30	11	11
10004	01-10-2017	2017-10-01 12:12:48	شنژن	35	0	2017-10-01 10:00:15	100	3	3
10004	03/10/2017	2017-10-03 12:38:20	شنژن	35	0	2017-10-03 10:20:22	11	6	6

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

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

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

شناسه کاربری	هزینه
10000	35
10001	2
10002	200
10003	30
10004	111

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

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

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

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

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

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

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

شهر	سن	هزینه	حداکثر _ سکونت _ زمان	دقیقه _ سکونت _ زمان
پکن	20	0	30	10
پکن	30	1	2	22
شانگهای	20	1	200	5
گوانگژو	32	0	30	11
شنژن	35	0	111	6

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

• شهر، سن، مجموع (هزینه)، حداکثر (حداکثر زمان اقامت)، حداقل (دقیقه زمان اقامت) را از گروه جدول بر اساس شهر، سن انتخاب کنید؛*
• انتخاب شهر، مجموع(هزینه)، حداکثر(حداکثر_زمان_سکونت)، حداقل(دقیقه_زمان_سکونت) 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

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	50
10002	2017-11-21	39

دسته 2

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	1
10001	2017-11-21	5
10003	2017-11-22	22

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

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	51
10001	2017-11-21	5
10002	2017-11-21	39
10003	2017-11-22	22

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

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

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

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

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

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

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

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

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

دسته 1

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	50
10002	2017-11-21	39

دسته 2

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	1
10001	2017-11-21	5
10003	2017-11-22	22

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

شناسه کاربری	تاریخ	هزینه
10001	2017-11-20	51
10001	2017-11-21	5
10002	2017-11-21	39
10003	2017-11-22	22

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

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

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

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

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

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

مدل تکراری

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

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

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