برنامه نویسی

مقدمه ای بر سناریوهای کاربردی PostgreSQL JSON و بهینه سازی Detoast مشترک

Summarize this content to 400 words in Persian Lang
سناریوهای کاربردی JSONBPostgreSQL دارای دو نوع داده مرتبط با JSON است: JSON و JSONB. این مقاله JSONB را معرفی می کند که به شما نیز توصیه می شود.

فرض کنید همه رکوردهای یک جدول دارای ویژگی‌های attr1..attr10 هستند، اما فقط برخی رکوردها دارای ویژگی‌های attr11..attr20 هستند و ممکن است در آینده ویژگی‌های attr21 و attr22 اضافه شوند. در این صورت ایجاد جدول با ستون JSON بسیار مناسب خواهد بود.

create table t1 (attr1 numeric, attr2 int, .. attr10 text, extra jsonb);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

داده های attr11..attr20 به عنوان جفت کلید-مقدار در ویژگی اضافی ذخیره می شود. اگر در آینده نیاز به افزودن attr21 و attr22 باشد، می‌توان آنها را مستقیماً در ویژگی اضافی بدون هیچ تغییری در ساختار جدول ذخیره کرد.

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

select extra->’attr11′ from t1 where extra->>’att20′ = ‘apple’;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

ما می توانیم برای کاهش انتقال شبکه، داده ها را بر روی سرور فیلتر و پروژه کنیم. علاوه بر این، ما همچنین می توانیم یک شاخص در extra->>'att20 ایجاد کنیم تا شرایط فیلتر را تسریع کنیم.

یکی دیگر از طراحی های افراطی این است که تمام ویژگی ها را در یک نوع JSONB ذخیره کنید و یک ساختار جدول به صورت زیر ایجاد کنید:

create table t2(data jsonb)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این راه حل نیز بهینه نیست، زیرا تمام رکوردها نیاز به ثبت مکرر ویژگی ها از attr1 تا attr10 دارند. به عنوان مثال، برای داده های یک ردیف، روش های ذخیره سازی t1 و t2 به شرح زیر است:

t1: 1|2|3|..|’20’|{‘attr21’: 2, ‘attr22’: 3}
t2: {‘attr1’: 1, ‘attr2’: 2, ‘attr3’: 3, … ‘attr21’: 2, ‘attr22′: 3}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

طراحی t2 منجر به ذخیره سازی و سربار انتقال شبکه خواهد شد. هر دوی این دو مشکل را می توان با فشرده سازی کاهش داد، اما فشرده سازی/فشرده سازی هزینه دارد.

PostgreSQL از استفاده همزمان از نوع داده JSONB و انواع داده های سنتی پشتیبانی می کند که این نیز یک ویژگی اصلی است و استفاده از این انعطاف پذیری می تواند مزایای قابل توجهی به همراه داشته باشد. بیایید با مثال قبلی ادامه دهیم: فرض کنید بعداً متوجه می‌شویم که attr11 در همه رکوردها وجود دارد، بنابراین می‌توانیم ساختار جدول را به این صورت تغییر دهیم:

create table t1 (attr1 numeric, attr2 int, .. attr10 text, attr11 text, extra jsonb);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

Detoast Datum به اشتراک گذاشته شده استبرای نوع داده JSON، حتی اگر داده ها کمی بزرگتر باشند، باید از قابلیت نان تست استفاده شود. داده های t1 را به عنوان مثال در نظر بگیرید. اصل کار کلی را می توان به صورت زیر ساده کرد:

t1:
1|2|3|..|{pointer-x}

pg_toast_{t1}
pointer-x| 1 | {attr11:.., attr12: …}
pointer-x| 2 | {attr16:.., attr20: …}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

فقط زمانی که نیاز به دسترسی به مقدار واقعی نشانگر-x داشته باشیم، مقدار {attr11: 11، …، attr20: 20} را «مونتاژ» می‌کنیم، و به این فرآیند detoast می‌گویند که نسبتاً منبع است. مصرف کننده

برای SQL زیر:

select extra->’attr11′ from t1 where extra->>’att20’ = ‘apple’;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

هر دو extra->>'att20' و extra->'attr11' نیاز به دسترسی کامل به اطلاعات اضافی در PostgreSQL بومی، detoast دو بار انجام می شود. عبارت زیر 4 بار سم زدایی می کند. هنگامی که مقدار اضافی کمی بزرگتر باشد، زمان زیادی صرف فرآیند پاکسازی می شود. داده detoast مشترک برای حل این مشکل طراحی شده است. برای همان داده ها، ما فقط یک بار سم زدایی می کنیم.

select extra->’attr11′, extra->’attr12′
from t1
where extra->>’att20′ = ‘apple’
and extra->>’attr19′ = ‘cloud’;

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مقدمه ای بر PolarDB برای PostgreSQLPolarDB برای PostgreSQL یک سرویس پایگاه داده رابطه ای بومی ابری است که توسط Alibaba Cloud توسعه یافته است. این 100٪ با PostgreSQL سازگار است و با نحو Oracle (پشتیبانی شده توسط نسخه ابر عمومی) بسیار سازگار است. از یک معماری ذخیره‌سازی مشترک استفاده می‌کند و محاسبات را از فضای ذخیره‌سازی جدا می‌کند. PolarDB برای PostgreSQL الاستیسیته فوق العاده بالا، تاخیر در سطح میلی ثانیه، قابلیت های HTAP و ویژگی های پایگاه داده در سطح سازمانی مانند قابلیت اطمینان بالا، در دسترس بودن بالا، و مقیاس بندی الاستیک را ارائه می دهد. علاوه بر این، با قابلیت محاسبات موازی در مقیاس بزرگ، می تواند بارهای کاری ترکیبی OLTP و OLAP را مدیریت کند.

کشف کنید که چه چیزی و چگونه می توانید از محصولات ما برای ساخت >> استفاده کنید

سناریوهای کاربردی JSONB
PostgreSQL دارای دو نوع داده مرتبط با JSON است: JSON و JSONB. این مقاله JSONB را معرفی می کند که به شما نیز توصیه می شود.

فرض کنید همه رکوردهای یک جدول دارای ویژگی‌های attr1..attr10 هستند، اما فقط برخی رکوردها دارای ویژگی‌های attr11..attr20 هستند و ممکن است در آینده ویژگی‌های attr21 و attr22 اضافه شوند. در این صورت ایجاد جدول با ستون JSON بسیار مناسب خواهد بود.

create table t1 (attr1 numeric,  attr2 int, ..  attr10 text, extra jsonb);
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

داده های attr11..attr20 به عنوان جفت کلید-مقدار در ویژگی اضافی ذخیره می شود. اگر در آینده نیاز به افزودن attr21 و attr22 باشد، می‌توان آنها را مستقیماً در ویژگی اضافی بدون هیچ تغییری در ساختار جدول ذخیره کرد.

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

select extra->'attr11' from t1 where extra->>'att20' = 'apple';
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

ما می توانیم برای کاهش انتقال شبکه، داده ها را بر روی سرور فیلتر و پروژه کنیم. علاوه بر این، ما همچنین می توانیم یک شاخص در extra->>'att20 ایجاد کنیم تا شرایط فیلتر را تسریع کنیم.

یکی دیگر از طراحی های افراطی این است که تمام ویژگی ها را در یک نوع JSONB ذخیره کنید و یک ساختار جدول به صورت زیر ایجاد کنید:

create table t2(data jsonb)
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این راه حل نیز بهینه نیست، زیرا تمام رکوردها نیاز به ثبت مکرر ویژگی ها از attr1 تا attr10 دارند. به عنوان مثال، برای داده های یک ردیف، روش های ذخیره سازی t1 و t2 به شرح زیر است:

t1:  1|2|3|..|'20'|{'attr21': 2, 'attr22': 3}
t2:  {'attr1': 1, 'attr2': 2, 'attr3': 3, ... 'attr21': 2, 'attr22': 3}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

طراحی t2 منجر به ذخیره سازی و سربار انتقال شبکه خواهد شد. هر دوی این دو مشکل را می توان با فشرده سازی کاهش داد، اما فشرده سازی/فشرده سازی هزینه دارد.

PostgreSQL از استفاده همزمان از نوع داده JSONB و انواع داده های سنتی پشتیبانی می کند که این نیز یک ویژگی اصلی است و استفاده از این انعطاف پذیری می تواند مزایای قابل توجهی به همراه داشته باشد. بیایید با مثال قبلی ادامه دهیم: فرض کنید بعداً متوجه می‌شویم که attr11 در همه رکوردها وجود دارد، بنابراین می‌توانیم ساختار جدول را به این صورت تغییر دهیم:

create table t1 (attr1 numeric,  attr2 int, ..  attr10 text, attr11 text,  extra jsonb);
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

Detoast Datum به اشتراک گذاشته شده است
برای نوع داده JSON، حتی اگر داده ها کمی بزرگتر باشند، باید از قابلیت نان تست استفاده شود. داده های t1 را به عنوان مثال در نظر بگیرید. اصل کار کلی را می توان به صورت زیر ساده کرد:

t1: 
  1|2|3|..|{pointer-x}

pg_toast_{t1}
  pointer-x| 1 | {attr11:.., attr12: ...}
  pointer-x| 2 | {attr16:.., attr20: ...}
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

فقط زمانی که نیاز به دسترسی به مقدار واقعی نشانگر-x داشته باشیم، مقدار {attr11: 11، …، attr20: 20} را «مونتاژ» می‌کنیم، و به این فرآیند detoast می‌گویند که نسبتاً منبع است. مصرف کننده

برای SQL زیر:

select extra->'attr11'  from t1 where  extra->>'att20'  = 'apple';
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

هر دو extra->>'att20' و extra->'attr11' نیاز به دسترسی کامل به اطلاعات اضافی در PostgreSQL بومی، detoast دو بار انجام می شود. عبارت زیر 4 بار سم زدایی می کند. هنگامی که مقدار اضافی کمی بزرگتر باشد، زمان زیادی صرف فرآیند پاکسازی می شود. داده detoast مشترک برای حل این مشکل طراحی شده است. برای همان داده ها، ما فقط یک بار سم زدایی می کنیم.

select extra->'attr11', extra->'attr12' 
from t1
where extra->>'att20'  = 'apple' 
  and extra->>'attr19' = 'cloud';
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مقدمه ای بر PolarDB برای PostgreSQL
PolarDB برای PostgreSQL یک سرویس پایگاه داده رابطه ای بومی ابری است که توسط Alibaba Cloud توسعه یافته است. این 100٪ با PostgreSQL سازگار است و با نحو Oracle (پشتیبانی شده توسط نسخه ابر عمومی) بسیار سازگار است. از یک معماری ذخیره‌سازی مشترک استفاده می‌کند و محاسبات را از فضای ذخیره‌سازی جدا می‌کند. PolarDB برای PostgreSQL الاستیسیته فوق العاده بالا، تاخیر در سطح میلی ثانیه، قابلیت های HTAP و ویژگی های پایگاه داده در سطح سازمانی مانند قابلیت اطمینان بالا، در دسترس بودن بالا، و مقیاس بندی الاستیک را ارائه می دهد. علاوه بر این، با قابلیت محاسبات موازی در مقیاس بزرگ، می تواند بارهای کاری ترکیبی OLTP و OLAP را مدیریت کند.

کشف کنید که چه چیزی و چگونه می توانید از محصولات ما برای ساخت >> استفاده کنید

توضیحات تصویر

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا