بهترین شیوه ها

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

حریم خصوصی و دقت داده ها

پرس و جوها را روی داده های جعبه شنی توسعه دهید

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

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

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

نتایج تاریخی را به دقت در نظر بگیرید

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

به خاطر داشته باشید که میزان تغییر بین نتایج پرس و جو بر میزان احتمال حذف نتایج بعداً به دلیل بررسی حریم خصوصی تأثیر خواهد داشت. مجموعه نتایج دوم که شباهت زیادی به مجموعه نتایج اخیراً برگردانده شده دارد، احتمالا حذف خواهد شد.

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

داده های امروز را پرس و جو نکنید

بهترین روش : در جایی که تاریخ پایان امروز است، چندین درخواست را اجرا نکنید.

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

داده های مشابه را بیش از حد لازم جستجو نکنید

بهترین شیوه ها :

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

Ads Data Hub تعداد کل دفعاتی را که می توانید از همان داده ها پرس و جو کنید، محدود می کند. به این ترتیب، باید سعی کنید تعداد دفعاتی را که به یک داده معین دسترسی دارید محدود کنید.

از تجمیع بیشتر از حد لازم در یک جستار استفاده نکنید

بهترین شیوه ها:

• تعداد تجمعات در یک پرس و جو را به حداقل برسانید
• در صورت امکان، پرس و جوها را بازنویسی کنید تا تجمیع ها را ترکیب کنید

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

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

پرس و جوهایی که رویدادها را بسته به مجموعه فیلدهای مشابه شمارش می کنند باید با استفاده از دستور GROUP BY بازنویسی شوند.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

نتیجه را می توان به همان روش در BigQuery جمع کرد.

کوئری هایی که ستون هایی از یک آرایه ایجاد می کنند و سپس آنها را جمع می کنند باید برای ادغام این مراحل بازنویسی شوند.

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

پرس و جو قبلی را می توان به صورت زیر بازنویسی کرد:

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

پرس و جوهایی که از ترکیب های مختلف فیلدها در ادغام های مختلف استفاده می کنند، می توانند در چندین پرس و جو متمرکزتر بازنویسی شوند.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

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

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

و

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

می‌توانید این نتایج را به جستارهای جداگانه تقسیم کنید، جداول را در یک جستار ایجاد کنید و به آنها بپیوندید، یا اگر طرحواره‌ها سازگار هستند، آنها را با یک UNION ترکیب کنید.

بهینه سازی و درک پیوست ها

بهترین روش : برای پیوستن به کلیک‌ها یا تبدیل‌ها به نمایش‌ها، به جای INNER JOIN ، از LEFT JOIN استفاده کنید.

همه نمایش‌ها با کلیک‌ها یا تبدیل‌ها مرتبط نیستند. بنابراین، اگر کلیک‌ها یا تبدیل‌های INNER JOIN روی نمایش‌ها را انجام دهید، نمایش‌هایی که با کلیک‌ها یا تبدیل‌ها مرتبط نیستند از نتایج شما فیلتر می‌شوند.

به برخی از نتایج نهایی در BigQuery بپیوندید

بهترین روش : از جستجوهای Ads Data Hub که به نتایج انبوه می‌پیوندند اجتناب کنید. در عوض، 2 کوئری جداگانه بنویسید و نتایج را در BigQuery بپیوندید.

ردیف هایی که الزامات تجمع را برآورده نمی کنند از نتایج شما فیلتر می شوند. بنابراین، اگر درخواست شما به ردیفی که به اندازه کافی انباشته شده است با یک ردیف به اندازه کافی تجمیع شده بپیوندد، ردیف حاصل فیلتر خواهد شد. به‌علاوه، پرس‌و‌جوهایی با تجمیع‌های متعدد در Ads Data Hub عملکرد کمتری دارند.

می‌توانید به نتایج (در BigQuery) از پرس‌و‌جوهای انبوه چندگانه (از Ads Data Hub) بپیوندید . نتایج محاسبه شده با استفاده از پرس و جوهای رایج، طرحواره های نهایی را به اشتراک خواهند گذاشت.

جستار زیر نتایج منفرد Ads Data Hub ( campaign_data_123 و campaign_data_456 ) را می گیرد و به آنها در BigQuery می پیوندد:

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

توجه: شما می توانید از جداول با حروف عام برای پرس و جو از اتحاد چندین جدول با نام مشابه در یک مجموعه داده استفاده کنید.

از خلاصه‌های ردیف فیلتر شده استفاده کنید

بهترین تمرین : خلاصه های ردیف فیلتر شده را به جستارهای خود اضافه کنید.

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

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

حساب برای شناسه های کاربر صفر شده

بهترین روش : شناسه های کاربر صفر شده را در نتایج خود در نظر بگیرید.

شناسه کاربر نهایی ممکن است به دلایلی روی 0 تنظیم شود، از جمله: انصراف از شخصی‌سازی تبلیغات ، دلایل نظارتی ، و غیره. به این ترتیب، داده‌هایی که از چندین کاربر نشات می‌گیرند در یک user_id 0 کلید می‌خورند.

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

با افزودن WHERE user_id != "0" به جستارهای خود می توانید این داده ها را از نتایج خود حذف کنید.

توجه: رویدادهایی با شناسه کاربری صفر شده به عنوان یک کاربر در حداقل 50 کاربر در هر ردیف محاسبه می‌شوند، مهم نیست چند کاربر واقعی این رویدادها را ایجاد کرده‌اند.

---

کارایی

از تجمع مجدد خودداری کنید

بهترین روش : از تجمع چندین لایه در بین کاربران خودداری کنید.

پرس و جوهایی که نتایجی را که قبلاً تجمیع شده‌اند، ترکیب می‌کنند، مثلاً در مورد یک پرس و جو با چندین GROUP BY ، یا تجمع تودرتو، برای پردازش به منابع بیشتری نیاز دارند.

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

از الگوهای زیر باید اجتناب شود:

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

پرس و جوهایی که از چند لایه تجمع استفاده می کنند باید برای استفاده از یک لایه تجمیع بازنویسی شوند.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

پرس و جوهایی که به راحتی قابل تجزیه هستند باید شکسته شوند. می توانید به نتایج در BigQuery بپیوندید.

بهینه سازی برای BigQuery

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

• داده های ورودی و منابع داده (I/O) : پرس و جو شما چند بایت می خواند؟
• ارتباط بین گره ها (در هم ریختن) : پرس و جو شما چند بایت به مرحله بعدی منتقل می کند؟
• محاسبات : پرس و جو شما به چه مقدار CPU کار می کند؟
• خروجی ها (مادی سازی) : پرس و جو شما چند بایت می نویسد؟
• Query anti-patterns : آیا درخواست های شما از بهترین شیوه های SQL پیروی می کنند؟

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

• استفاده از نتایج جستجوهای قبلی به جای محاسبه مجدد. به عنوان مثال، مجموع هفتگی شما می تواند مجموع 7 جستار جمع آوری یک روزه در BigQuery محاسبه شود.
• تجزیه پرس‌و‌جوها به پرسش‌های فرعی منطقی (مانند تقسیم اتصالات متعدد به چند پرس‌وجو)، یا محدود کردن مجموعه داده‌های در حال پردازش. می‌توانید نتایج حاصل از تک تک مشاغل را در یک مجموعه داده در BigQuery ترکیب کنید. اگرچه این ممکن است به فرسودگی منابع کمک کند، اما ممکن است جستجوی شما را کند کند.
• اگر در BigQuery با خطاهای بیش از حد منابع مواجه هستید، سعی کنید از جداول موقت استفاده کنید تا پرس و جو خود را به چند عبارت BigQuery تقسیم کنید.
• ارجاع به جداول کمتر در یک پرس و جو، زیرا این کار از مقدار زیادی حافظه استفاده می کند و می تواند باعث شکست درخواست شما شود.
• بازنویسی پرس و جوهای خود به گونه ای که به جداول کاربر کمتری بپیوندند.
• بازنویسی پرس و جوهای خود برای جلوگیری از پیوستن مجدد به جدول مشابه.

مشاور پرس و جو

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

محرک ها شامل الگوهای زیر هستند:

• پیوستن به سوالات فرعی انبوه
• پیوستن به داده های تجمیع نشده با کاربران بالقوه متفاوت
• جداول زمانی که به صورت بازگشتی تعریف شده اند

برای استفاده از مشاور پرس و جو:

• UI . توصیه ها در ویرایشگر پرس و جو، بالای متن پرس و جو ظاهر می شوند.
• API . از روش customers.analysisQueries.validate استفاده کنید.