بعد از اتمام دوره بیگ‌دیتای همکاران سیستم، یکی از دانشجویان این دوره به من پیام داد که اگر بخواهم یک کار عملی توی حوزه مهندسی داده انجام بدم که مفاهیم اصلی مورد نیاز را به صورت عملی کار کنم، چه پروژه ای پیشنهاد می‌دهید.
پیشنهاد من ایجاد یک خط پردازش داده بود که داده‌های یک وب سایت تجاری به کمک CDC و Debezium از پستگرس دریافت و وارد کافکا شود. در مرحله بعد هم این داده‌ها به صورت خودکار توسط کلیک‌هوس دریافت شده و در جداول تحلیلی متناظر در Clickhouse‌ ذخیره شده و نهایتا با ابزارهای گرافیکی نمایش داده شود.
برای تولید داده‌ها هم از ایرفلو در بازه‌های زمانی کوتاه برای شبیه سازی یک وب‌سایت خرید و فروش محصول، استفاده شود.
خروجی ای که آقا بهنام یزدان‌پناهی @behnamyzp عزیز آماده کرد خیلی فراتر از انتظارم بود.
کل پروژه که روند فوق در آن پیاده سازی شده و نتایج در گرافانا نمایش داده شده است به همراه توضیحات لازم برای اجرای آن در آدرس زیر قرار گرفته است :‌
https://github.com/behnamyazdan/ecommerce_realtime_data_pipeline/
برای دوستانی که علاقه‌مند به حوزه مهندسی داده و مباحث زیرساختی هستند، یک نقطه شروع بسیار عالی است و برای دوستانی که با پستگرس کار می‌کنند می‌توانند از ایده انتقال داده‌ها به کلیک هوس و اجرای کوئری‌های تحلیلی بر روی آن استفاده کنند.
هر چند بهتر است ساختار طراحی شده برای کلیک هوس تغییر کند به گونه‌ای که به جای تمامی جداول بخش خرید و فروش، چند جدول اصلی اما بزرگ (با حذف نرمال‌سازی که در دیتابیس‌های تحلیلی کاملا روال است)‌ داشته باشیم و با ابزارهایی مانند dbt، با اجرای کوئری‌هایی در بازه‌های زمانی کوتاه، این جداول تحلیلی از روی جداول پایه دریافت شده از کافکا، پرشده و جداول پایه، با تنظیم مقدار TTL‌ مناسب، به صورت خودکار حذف شوند.
ضمن تشکر مجدد از آقا بهنام عزیز ، این پست را با کسب اجازه از ایشان در اینجا منتشر میکنم. باشد که برای علاقه‌مندان، مفید باشد.
لینک توضیحات خود بهنام عزیز در لینکدین :
https://www.linkedin.com/posts/behnam-yazdanpanahi_ecommerceabrdataabrpipeline-cdc-kafka-activity-7172687833793445888-USBb
#مهندسی_داده #clickhouse #airflow #cdc #postgresql #Debezium #پستگرس #خطوط_پردازش_داده

‍ آیا ترتیب ستون‌ها در کارآیی دیتابیس، موثر است ؟
اگر شما هم فکر می‌کنید که ترتیب ستون‌ها تاثیری در اجرای کوئری ها ندارد، مقاله زیر که به بررسی این موضوع در پستگرس پرداخت است را از دست ندهید .
https://demirhuseyinn-94.medium.com/the-surprising-power-of-humble-column-ordering-in-postgresql-ce7c7d587a27
خلاصه مقاله این است که فیلد‌های با طول متغیر و فیلدهای Nullable بهتر است به انتهای لیست منتقل شوند و فیلدهای مشابه کنار هم قرار گیرند.
CREATE TABLE user_order_default (
is_shipped BOOLEAN NOT NULL DEFAULT false,
user_id BIGINT NOT NULL,
order_total NUMERIC NOT NULL,
order_dt TIMESTAMPTZ NOT NULL,
order_type SMALLINT NOT NULL,
ship_dt TIMESTAMPTZ,
item_ct INT NOT NULL,
ship_cost NUMERIC,
receive_dt TIMESTAMPTZ,
tracking_cd TEXT,
id BIGSERIAL PRIMARY KEY NOT NULL
);

CREATE TABLE user_order_tweaked (
id BIGSERIAL PRIMARY KEY NOT NULL,
user_id BIGINT NOT NULL,
order_dt TIMESTAMPTZ NOT NULL,
ship_dt TIMESTAMPTZ,
receive_dt TIMESTAMPTZ,
item_ct INT NOT NULL,
order_type SMALLINT NOT NULL,
is_shipped BOOLEAN NOT NULL DEFAULT false,
order_total NUMERIC NOT NULL,
ship_cost NUMERIC,
tracking_cd TEXT
);

‍‍‍SELECT pg_relation_size('user_order_default') AS size_bytes,
pg_size_pretty(pg_relation_size('user_order_default')) AS size_pretty;

SELECT pg_relation_size('user_order_tweaked') AS size_bytes,
pg_size_pretty(pg_relation_size('user_order_tweaked')) AS size_pretty;



size_bytes | size_pretty
------------+-------------
141246464 | 135 MB
(1 row)

size_bytes | size_pretty
------------+-------------
117030912 | 112 MB

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

#postgresql #column_ordering #postgresql_performance

‍ پستگرس که «در لطافت طبعش خلاف نیست»، به قول سعدی علیه الرحمه «در باغ لاله روید و در شوره زار خس». مفسرین بر این باورند که منظور شیخ این بوده است که این دیتابیس، گاهی اوقات بسیار عالی و خوب عمل می‌کند و برای بسیاری از کاربردهای امروزی که نیاز به کوئری‌های پیچیده روی حجم عظیم دیتای ورودی داریم، ما را با چالش‌های جدی مواجه می‌کند.
در وبینار زیر، به این پرسش اساسی پاسخ می‌دهیم که اگر با پستگرس در مواجهه با داده‌های زیاد به چالش برخوردیم،‌ چه کنیم و اصلا آیا پستگرس برای خیلی از نیازمندیهای امروز می‌تواند گزینه مناسبی باشد یا نه ؟ مروری بر راه‌حل‌های کلاسیک این مساله و راه‌حل‌هایی که در چند سال اخیر پیش روی ما قرار گرفته است می‌پردازیم.
دیتابیس‌هایی مبتنی بر پستگرس مانند ParadeDB، دیتابیس‌هایی با پروتکل پستگرس مانند CockroachDB و RisingWave‌ و افزونه‌هایی مانند Hydra را بررسی می کنیم.
اگر در حال استفاده از پستگرس هستید و نگرانی‌هایی راجع به آن در مواجهه با نیازمندیهای جدید دارید،‌ شاید این وبینار که به صورت عملی برگزار خواهد شد، برای شما مفید باشد.
https://anisa.co.ir/fa/news/2-uncategorised/298-workshop-23.html
#پستگرس #Postgres #PostgreSQL

اگر با پستگرس کار می‌کنید و

- قصد راه‌اندازی CDC را بر روی آن دارید، مثلا قصد دارید به ازای هر کاربر جدید یا هر سفارش جدید، یک رخداد جدید به صورت خودکار ایجاد شده و به کافکا ارسال گردد تا در یک پایپ‌لاین پردازش داده، اقدام مناسب برای آن رخداد (مثلا ایجاد یک کدتخفیف سفارشی و ارسال به مشتری)‌ انجام شود.

- یا می‌خواهید یک بکاپ از برخی جداول اصلی خود روی یک یا چند نود پستگرس دیگر ایجاد کنید

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

برای تمامی این موارد، می توانید از PeerDB‌ استفاده کنید. به صورت خیلی شیک و مجلسی و با یک Web UI‌ ساده، جداول مورد نظر را انتخاب می کنید، مقصد انتقال (پستگرس یا کلیک‌هوس یا کافکا و ... ) را مشخص کرده و بقیه کار را به PeerDB‌ بسپرید. این ابزار که بر محور پستگرس ایجاد شده است، می‌تواند دستیار خوب شما در انتقال داده‌ها از پستگرس به هر مقصد دیگری باشد (البته لیست مقاصد انتقال با جذب سرمایه اخیر این ابزار در حال گسترش است). مزایایی مثل سرعت چندبرابر نسبت به ابزارهای فعلی را می‌توانید در مستندات این ابزار مفید پیدا کنید.

PeerDB: Our infrastructure is designed for real-time streaming from Postgres. If your application is latency-sensitive you can configure refresh intervals as low as a few seconds

PeerDB : https://docs.peerdb.io/quickstart/quickstart


#پستگرس #Postgres #PeerDB #PostgreSQL