بعد از اتمام دوره بیگ‌دیتای همکاران سیستم، یکی از دانشجویان این دوره به من پیام داد که اگر بخواهم یک کار عملی توی حوزه مهندسی داده انجام بدم که مفاهیم اصلی مورد نیاز را به صورت عملی کار کنم، چه پروژه ای پیشنهاد می‌دهید.
پیشنهاد من ایجاد یک خط پردازش داده بود که داده‌های یک وب سایت تجاری به کمک 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

اخیرا که درگیر انتقال داده‌ها از پستگرس به YugaByteDB (یک نسخه مقیاس‌پذیر و منطبق بر پستگرس) بودیم، ابزار ساده اما بسیار مفیدی را پیدا کردم با نام pgsync که برای جابجایی جداول بین این دو دیتابیس کمک زیادی به ما کرد.
هر چند جای بهبود زیادی دارد -مثلا روابط و وابستگی بین جداول را تشخیص نمی‌دهد و اینکار را باید خودمان به صورت دستی در فایل تنظیمات آن وارد کنیم- اما کار با آن ساده و نتیجه کار کاملا رضایت بخش است .
هم می تواند اسکیما را بررسی کرده و جداول مقصد را بسازد و هم امکان انتقال داده ها در دسته های ده هزارتایی را دارد و هم می‌توان جداولی که باید ابتدا منتقل شوند را گروه‌بندی کرده و در فایل تنظیمات آن یعنی .pgsync.yml وارد کرد و به صورت گروه به گروه،‌ عملیات انتقال را انجام داد.
https://github.com/ankane/pgsync
#postgres #postgresql #yugabytedb #db_migration

‍ چرا دریافت نتایج کوئری گاهی اینقدر طول می‌کشد؟ ✨

با پیشرفت روزافزون فناوری دیتابیس‌ها، ضروری است که روش‌ها و پروتکل‌های انتقال داده نیز به‌روزرسانی شوند تا بتوان از تمامی ظرفیت و توان پردازشی این سیستم‌ها به‌طور مؤثر بهره‌برداری کرد.

فرض کنید به عنوان یک تحلیلگر داده، با استفاده از درایور ODBC به ClickHouse متصل شده‌اید و دستوری برای بازیابی ۱۰ هزار رکورد خاص اجرا کرده‌اید. دستور را ارسال می‌کنید و منتظر نتایج می‌مانید، اما متوجه می‌شوید که زمان دریافت نتایج به طرز معناداری بیشتر از زمانی است که همان دستور را مستقیماً در خط فرمان ClickHouse اجرا کرده‌اید. 😕 این تفاوت زمانی از کجا می‌آید و چرا برای کاربرانی مثل شما که با داده‌های بزرگ کار می‌کنید، مهم است؟

دلیل اصلی این کندی، به نحوه عملکرد درایورهای سنتی مانند ODBC برمی‌گردد. ClickHouse یک دیتابیس تحلیلی است که از ذخیره‌سازی ستونی استفاده می‌کند—ساختاری که برای پردازش سریع داده‌های حجیم بهینه شده است. اما درایورهای ODBC برای دیتابیس‌های ردیفی طراحی شده‌اند و مجبورند داده‌های ستونی را به فرمت ردیفی تبدیل کنند. این تبدیل، هم زمان‌بر است و هم منابع زیادی مصرف می‌کند، که نتیجه‌اش کاهش عملکرد و تأخیر در دریافت داده‌هاست. ⏳ برای تحلیلگران داده، مهندسین داده و دانشمندان داده که به سرعت و کارایی وابسته هستند، این یک چالش جدی است.

🚀 فرمت Arrow: استانداردی برای پردازش سریع داده‌های تحلیلی
سال‌هاست که Apache Arrow به عنوان یک فرمت درون حافظه برای کار با داده‌های ستونی، به یک استاندارد رایج برای پردازش سریع و بهینه داده‌های تحلیلی تبدیل شده است. Arrow با طراحی خاص خود، سربار ناشی از تبدیل داده‌ها بین فرمت‌های مختلف را حذف می‌کند و امکان پردازش موازی را فراهم می‌آورد. این یعنی شما می‌توانید داده‌های بزرگ را با سرعت بیشتری تحلیل کنید. 📊 این فرمت با ابزارهای محبوبی مثل Pandas، Apache Spark و Dask سازگار است و به همین دلیل، برای جامعه داده به یک انتخاب ایده‌آل تبدیل شده است.

حالا تصور کنید اگر بتوانید همین سرعت و کارایی را مستقیماً در ارتباط با دیتابیس‌ داشته باشید. ADBC دقیقا با همین هدف و توسط پروژه محبوب Arrow توسعه داده شد.

🌟 کتابخانه ADBC: راهکاری مدرن برای ارتباط سریع با دیتابیس‌ها
اینجاست که ADBC (Arrow Database Connectivity) وارد می‌شود! ADBC یک رابط برنامه‌نویسی کاربردی (API) مدرن است که به شما اجازه می‌دهد داده‌ها را به صورت مستقیم و در فرمت ستونی از دیتابیس‌هایی مثل ClickHouse یا حتی پستگرس دریافت کنید. با ADBC، دیگر نیازی به تبدیل‌های وقت‌گیر به فرمت ردیفی نیست—داده‌ها با همان ساختار ستونی که برای تحلیل بهینه است، به اپلیکیشن شما منتقل می‌شوند. 🚄

🎯 مزایای ADBC برای تحلیلگران و مهندسین داده
- سرعت بیشتر: حذف تبدیل‌های ردیفی، زمان دریافت داده‌ها را به شدت کاهش می‌دهد.
- پشتیبانی از استریمینگ: داده‌ها به صورت پیوسته و بدون وقفه منتقل می‌شوند.
- انعطاف‌پذیری: با دیتابیس‌های مختلف، از ClickHouse تا PostgreSQL، کار می‌کند.
- اکوسیستم کامل: یک API یکپارچه با ابزارهایی مثل Flight SQL که کار توسعه و کاربرد آنرا ساده‌تر می‌کنند.

برای پروژه‌های تحلیلی که زمان و دقت در آن‌ها حرف اول را می‌زند، تفاوت سرعت ناشی از به کار گیری ADBC برای اتصال به دیتابیس‌ها می‌تواند بهره‌وری شما را متحول کند. 📈
نکته مهم دیگری که باید اشاره شود این است که حتی برای دیتابیس‌های کلاسیک، اگر قصد دریافت حجم زیاد دیتا برای پردازش با ابزارهایی مانند پانداز یا polars را دارید، باز هم ADBC بهینه‌تر است. مثال موجود در شکل این پست هم در همین راستاست.

#DataEngineering #Database #ADBC #ApacheArrow #BigData #PerformanceOptimization #DuckDB #PostgreSQL


منبع : https://arrow.apache.org/blog/2025/02/28/data-wants-to-be-free/

‍ چرا UUID7 و ULID گزینه‌های بهتری برای کلیدهای اصلی در پایگاه داده هستند؟
در طراحی پایگاه‌های داده، انتخاب نوع شناسه (ID) یکی از تصمیم‌های کلیدی است که می‌تواند تأثیر زیادی بر عملکرد، مقیاس‌پذیری و امنیت سیستم داشته باشد.
در سناریوهایی مثل سیستم‌های توزیع‌شده، APIهای پرترافیک یا صفحات محصول در وب‌سایت‌ها که نیاز به درج سریع داده و جلوگیری از افشای الگوی رکوردها وجود دارد، استفاده از کلیدهای auto-increment معمولاً گزینه مناسبی نیست. چون:
⛔️باعث قفل شدن جدول در شرایط همزمانی بالا می‌شود،
⛔️امکان حدس زدن تعداد یا ترتیب رکوردها را فراهم می‌کند.

💡 راه‌حل سنتی چیست؟
استفاده از UUID (نسخه ۴) به‌عنوان کلید اصلی مزایای خوبی دارد: یکتایی جهانی بدون نیاز به هماهنگی بین سرورها، مناسب برای محیط‌های توزیع‌شده، و جلوگیری از افشای الگوهای داده. اما یک مشکل جدی دارد.
🔍 چرا UUID تصادفی (مثلاً UUIDv4) در دیتابیس‌ها عملکرد خوبی ندارد؟
اکثر پایگاه‌های داده رابطه‌ای مانند PostgreSQL، MySQL و SQL Server برای ایندکس‌گذاری — مخصوصاً روی کلید اصلی — از ساختاری به‌نام B-Tree (Balanced Tree) استفاده می‌کنند.
این ساختار کمک می‌کند:
✳️جستجوی کلیدها با پیچیدگی O(log n) انجام شود (سریع و مقیاس‌پذیر)،
✳️داده‌ها به‌صورت مرتب نگه داشته شوند،
✳️ و درج، حذف یا به‌روزرسانی به‌شکل کارآمد مدیریت شود.
اما مشکل از جایی شروع می‌شود که کلیدهایی با ترتیب تصادفی (مثل UUIDv4) در جدول وارد می‌شوند.

📉 چه اتفاقی می‌افتد؟
وقتی داده‌های زیادی با کلید تصادفی وارد جدول می‌شوند:
⛔️ دیتابیس نمی‌تواند آن‌ها را در انتهای ساختار درختی اضافه کند (مثل auto-increment IDs)،
⛔️ باید آن‌ها را بین صفحات مختلف B-Tree پراکنده کند،
⛔️ این پراکندگی باعث عملیات مکرر Page Split (شکستن صفحات)، جابه‌جایی نودها و بازچینش ساختار درختی می‌شود.

🧨 نتیجه؟
🧱کند شدن محسوس عملیات درج (INSERT)،
🧱 مصرف بالای I/O و حافظه،
🧱 کاهش عملکرد کلی سیستم در سناریوهای پرترافیک.

✅ راه‌حل‌های مدرن: UUID7 و ULID
برای رفع این مشکلات، دو استاندارد جدید معرفی شده‌اند:
🔹 استاندارد ULID (Lexicographically sortable): ترکیبی از timestamp و داده تصادفی
🔹 استاندارد UUIDv7: نسخه‌ای از UUID با ترتیب زمانی، سازگار با استاندارد UUID

مزیت اصلی این دو چیست؟
🔸 با حفظ یکتایی و امنیت، کلیدها به‌صورت ترتیبی در ایندکس درج می‌شوند.
🔸 این یعنی:
✅کاهش شدید Page Split و پراکندگی
✅بهبود درج‌های پرترافیک
✅جست‌وجوی سریع‌تر بر اساس بازه‌های زمانی

📊 چه زمانی از هرکدام استفاده کنیم؟
اگر خوانایی و طول کوتاه‌تر مهم است → ULID
اگر سازگاری با UUID استاندارد اهمیت دارد → UUIDv7

📐 قالب ULID
قالب ULID یک رشته ۲۶ نویسه‌ای است که با Crockford’s Base32 کدگذاری می‌شود (حروف I, L, O, U حذف شده‌اند تا اشتباه نشوند).
→ طول: ۲۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ مثال: 01AN4Z07BY79KA1307SR9X4MV3

📐 قالب UUIDv7
→ نمایش به‌صورت استاندارد UUID در مبنای ۱۶ (hex) با خط تیره
→ طول شامل خط تیره: ۳۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ قالب: 8-4-4-4-12
→ مثال: 017f45e0-7e1a-7a3f-8bbc-4dbf7e6d9c3a
→ طول بدون خط تیره: ۳۲ نویسه hex

بنابراین UUID7 طول بیشتری نسبت به ULID دارد اما چون با استاندارد UUID سازگاراست، برای سیستم‌های موجود گزینه بهتری است.

#Database #Backend #DistributedSystems #UUID #ULID #PostgreSQL #SystemDesign #Performance #مهندسی_داده

‍ معرفی DuckLake: ساده‌سازی Lakehouse با قدرت SQL

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

🧠 این همان فلسفه‌ی #Lakehouse است:

ترکیب بهترین ویژگی‌های Data Lake (انعطاف و مقیاس‌پذیری) و Data #Warehouse (ساختارمندی و قابلیت تحلیل)

اما واقعیت این است که #Lakehouse ها در عمل با پیچیدگی‌هایی همراه هستند:
برای هر جدول، باید اطلاعاتی مانند schema، نسخه‌ها، تغییرات، پارتیشن‌بندی و ... در فراداده‌ها نگه داشته شود. این یعنی نیاز به سیستم‌های اضافی کاتالوگ‌ها، متادیتا‌ها و گاهی سرویس‌‌های اضافی برای مدیریت نسخه‌ها

اما : چرا وقتی به هر حال به یک دیتابیس نیاز داریم (برای کاتالوگ)، از ابتدا همه چیز را در SQL مدیریت نکنیم؟

📢 امروز #DuckDB با معرفی #DuckLake، پاسخی جسورانه و منطقی به این سوال داده است.

✅ اما سوال اصلی : DuckLake چیست؟

استاندارد DuckLake یک فرمت Open Table جدید برای معماری Lakehouse است که:

داده‌ها را در قالب‌های باز مانند Parquet در Blob Storage ذخیره می‌کند؛

اما تمام فراداده‌ها (metadata)، snapshotها، schemaها و آمار را در یک پایگاه داده SQL ساده (مثل PostgreSQL یا خود DuckDB) مدیریت می‌کند.

🔍 چرا DuckLake یک تغییر بنیادین است؟

1. سادگی واقعی

برخلاف Iceberg و Delta که برای یک append ساده، باید چندین فایل JSON و Avro ایجاد یا به‌روز کرد، در DuckLake همه چیز فقط چند query ساده SQL است.
نیازی به لایه‌ی اضافه‌ی catalog server یا فایل‌های اضافی نیست. فقط یک دیتابیس و فایل‌های Parquet.

2. مدیریت تراکنش‌پذیر (ACID) واقعی

تغییرات در جدول‌ها، snapshotها و آمار ستون‌ها در یک تراکنش واحد SQL انجام می‌شود. این یعنی:
📌atomic commitها؛
📌پشتیبانی از تغییرات پیچیده و multi-table؛
📌 بدون ترس از ناسازگاری فایل‌ها در blob storage.

3. سازگاری، مقیاس‌پذیری و سرعت
می‌توانید DuckLake را با DuckDB روی لپ‌تاپ اجرا کنید یا با PostgreSQL روی کلاود.
برخلاف ساختارهای فایل‌محور، پردازش‌ها سریع‌تر، قابل کش‌شدن و قابل مشاهده‌اند.
محدود به هیچ vendor خاصی نیستید؛ جابه‌جایی آسان است.

🏗 یک نگاه به معماری DuckLake:

📁 داده‌ها → Parquet روی S3 یا هر blob store

📚 فراداده → SQL Tables روی DuckDB/PostgreSQL/...

🔁 عملیات → فقط SQL transactions ساده با DuckDB

🧠 چرا مهم است؟

در حالی که بسیاری از معماری‌های داده در مسیر «Lakehouse» پیچیدگی‌های جدیدی اضافه می‌کنند، DuckLake مسیر را به عقب برمی‌گرداند و از یک حقیقت ساده دفاع می‌کند:

وقتی که به هر حال از یک دیتابیس استفاده می‌کنیم، چرا بقیه‌ی بخش‌ها را هم در همان قالب SQL مدیریت نکنیم؟

📌 نتیجه‌گیری

استاندارد DuckLake نه فقط یک فرمت جدید، بلکه بازاندیشی دوباره‌ای است در طراحی Lakehouse — مبتنی بر اصل «سادگی، مقیاس‌پذیری، سرعت». اگر به دنبال آینده‌ای پایدارتر، قابل نگهداری‌تر و بدون vendor lock-in برای lakehouse هستید، DuckLake را جدی بگیرید.

📎 مطالعه‌ی کامل مقاله: https://duckdb.org/2025/05/27/ducklake.html

#DuckDB #DuckLake #DataEngineering #Lakehouse #OpenFormats #SQL #Parquet #PostgreSQL

‍ معرفی Supabase: فراتر از یک پایگاه داده؛ جعبه‌ابزاری کامل برای توسعه اپلیکیشن‌ها

در یکی دو سال اخیر، نام Supabase بارها به گوشم خورده بود.

در ابتدا تصور می‌کردم با یک سرویس آنلاین برای میزبانی #PostgreSQL طرف هستیم؛ یک دیتابیس ساده و کاربردی برای مدیریت داده.

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

🧰 سوپابیس در واقع یک چارچوب متن‌باز و یکپارچه برای توسعه سریع اپلیکیشن‌هاست؛ ابزاری که تمامی نیازهای بک‌اند، از دیتابیس گرفته تا API و احراز هویت و ذخیره فایل را به‌صورت آماده در اختیار توسعه‌دهندگان قرار می‌دهد.

📦 همین جامع‌بودن و سادگی استفاده، مخصوصاً برای تیم‌های کوچک یا استارتاپ‌هایی که در حال تبدیل ایده به محصول هستند، باعث شد تصمیم بگیرم تجربه‌ام را از کشف این ابزار و همچنین داستان شکل‌گیری آن، با شما به اشتراک بگذارم—به‌ویژه حالا که #Supabase با جذب ۲۰۰ میلیون دلار سرمایه در آوریل ۲۰۲۵، به ارزش‌گذاری ۲ میلیارد دلاری رسیده است.



💡 نقطه شروع: وقتی یک ایده جذاب دارید...

✨ فرض کنید یک ایده خلاقانه برای اپلیکیشن در ذهن دارید.

با کمک ابزارهای طراحی یا همکاری با یک توسعه‌دهنده فرانت‌اند، رابط کاربری را به‌سرعت می‌سازید.

اما به‌محض اینکه به بخش بک‌اند می‌رسید، چالش‌های واقعی آغاز می‌شوند:

🚫 طراحی دیتابیس، نوشتن APIها، پیاده‌سازی احراز هویت، مدیریت فایل‌ها و...

⚙️ در این شرایط، #Supabase مانند یک راه‌حل آماده و قابل‌اعتماد و سریع وارد میدان می‌شود.

اصلا شعار این پلتفرم هم همین است : «در یک آخر هفته بساز؛ برای میلیون‌ها کاربر آماده شو.»



🧬 سوپابیس چگونه متولد شد؟

سوپابیس در سال ۲۰۲۰ توسط Paul Copplestone و Ant Wilson تأسیس شد؛

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

🔥 در آن زمان Firebase محصول مطرحی بود، اما به دلیل ساختار بسته‌اش، گزینه جذابی برای جامعه متن‌باز محسوب نمی‌شد.

🔓 ایده Supabase: نسخه‌ای متن‌باز از Firebase، با تکیه بر قدرت PostgreSQL 💪



🛠 چه امکاناتی Supabase را متمایز می‌کند؟

Supabase یک جعبه‌ابزار کامل برای توسعه‌ی بک‌اند است، شامل:

✅ پستگرس قدرتمند (با JSONB، جست‌وجوی متنی و اکستنشن‌ها)

✅ داشتن APIهای خودکار (REST و GraphQL)

✅ سیستم احراز هویت یکپارچه (ورود با Google، GitHub و...)

✅ فضای ذخیره‌سازی فایل امن و مقیاس‌پذیر

✅ پشتیبانی از داده‌های بلادرنگ (Realtime)

✅ رابط گرافیکی برای مدیریت داده‌ها

✅ توابع لبه Edge Functions و replication در مقیاس جهانی

✅ کاملاً متن‌باز و قابل‌نصب روی هر سروری



🌍 چرا Supabase تا این حد محبوب شده است؟

📊 بیش از ۲ میلیون توسعه‌دهنده در حال استفاده

📦 بیش از ۳.۵ میلیون دیتابیس فعال

🏢 استفاده توسط شرکت‌هایی مثل Mozilla، GitHub، OpenAI



✨ دلایل محبوبیت:

⚡️ راه‌اندازی سریع

🌱 جامعه بزرگ متن‌باز (۸۰K+ ستاره در GitHub)

🧠 سازگاری با نیازهای AI و داده‌های برداری

💸 حمایت سرمایه‌گذاران معتبر (Y Combinator, Accel و...)



🤖 سوپابیس و آینده هوش مصنوعی

سوپابیس در حال آماده‌سازی زیرساختی مناسب برای نسل بعدی اپلیکیشن‌های AI است:

🧠 توابع لبه - Edge Functions

🕒 زمان‌بندی با Cron

🧭 جست‌وجوی برداری


🧩 سخن آخر : قدرت متن‌باز در برابر غول‌ها

💥 رسیدن به ارزش ۲ میلیارد دلاری فقط در چند سال نشان می‌دهد که قدرت جامعه و ابزارهای بازمتن در حال شکل‌دادن به آینده توسعه بک‌اند هستند.

مخزن کد پروژه : https://lnkd.in/gpdbXFWv

‍ پستگرس در عصر هوش مصنوعی: از انتخاب استارتاپ‌ها تا تمرکز غول‌های فناوری

در نیمه اول ۲۰۲۵، #PostgreSQL بار دیگر نشان داد که فقط یک پایگاه‌داده نیست؛ بلکه قلب تپنده‌ی تحول در زیرساخت‌های داده و هوش مصنوعی است. خبرهای مهم، سرمایه‌گذاری‌های سنگین، و توسعه سریع اکوسیستمش، گویای یک واقعیت جدید هستند:

🧠 #پستگرس حالا یکی از بازیگران اصلی در عصر AI است.

🔹 📣 خبر داغ: #Snowflake + Crunchy Data = Snowflake Postgres

در کنفرانس Snowflake Summit 2025 اعلام شد:

💼 غول دنیای انباره‌های داده ابری یعنی Snowflake شرکت Crunchy Data رو با ارزش ۲۵۰ میلیون دلار خرید.

🎯 هدف: توسعه یک نسخه سازمانی و تقویت‌شده از #PostgreSQL با تمرکز روی نیازهای AI و بارهای کاری حساس.

این خرید نشان‌دهنده تغییری بزرگ در استراتژی #Snowflake است؛ شرکتی که تا امروز بیشتر با انبار داده اختصاصی‌اش شناخته می‌شد.

🔹 سرمایه‌گذاری‌های بزرگ دیگر:

💰 شرکت #Databricks، یکی از بازیگران اصلی حوزه #Lakehouse، استارتاپ #Neon رو با حدود ۱ میلیارد دلار خرید.

🌱 ابزار محبوب #Supabase، محبوب‌ترین پلتفرم متن‌باز #PostgreSQL، در سری D مبلغ ۲۰۰ میلیون دلار جذب کرد (ارزش‌گذاری: ۲ میلیارد دلار).

📌 این‌ها نشون می‌دهند که #PostgreSQL از یک دیتابیس محبوب برای پروژه‌های کوچک، به زیرساخت اصلی پلتفرم‌های داده نسل بعدی تبدیل شده.


🔹 چرا PostgreSQL این‌قدر مهم شده؟

✅ انعطاف‌پذیر و چندمنظوره: از SQL استاندارد تا JSON و جستجوی متنی

✅ قابل توسعه: اکستنشن‌هایی مثل pgvector برای داده‌های برداری (AI/LLM)

✅ مقیاس‌پذیر: ابزارهایی مثل Citus و TimescaleDBبرای بارهای سنگین

✅ امن و متن‌باز: بدون vendor lock-in، با اکوسیستم غنی


📈 در دو سال اخیر:

🔹چندین افزونه برای جستجوی برداری

🔹ابزارهای اتصال PostgreSQL به LLMها

🔹و حتی ساخت لِیک‌هوس با PostgreSQL

منتشر شده‌اند. این یعنی PostgreSQL آماده‌ی دنیای AI-first است.

اما یک نکته مهم دیگر وجود دارد :

🔹 از MVP تا Enterprise: مسیری طبیعی برای استارتاپ‌ها

بیشتر استارتاپ‌ها با PostgreSQL شروع می‌کنن چون:

👶 سریع، ساده، بدون هزینه لایسنس

🧪 ابزارهای کامل توسعه و تست

📚 مستندات و جامعه فعال

اما با رشد محصول و پیچیده‌تر شدن نیازها، معمولاً به نسخه‌های Managed و Enterprise مهاجرت می‌کنن:


☁️ Azure Database for PostgreSQL

🧱 Crunchy Bridge

🏢 EDB Postgres Advanced

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

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

🎯 جمع‌بندی:

پستگرس حالا دیگر فقط "پایگاه‌داده موردعلاقه دولوپرها" نیست. بلکه تبدیل شده به زبان مشترک زیرساخت‌های داده در عصر AI — از گاراژ استارتاپ‌ها تا دیتاسنتر غول‌ها.

#PostgreSQL #AI #DataInfra #DataEngineering #pgvector #StartupTools #EnterpriseTech #Snowflake #Databricks #Supabase #OpenSource #PostgresAI #DatabaseTrends #Lakehouse #MLOps

‍ داستان تولد یک Graph Engine متفاوت: آشنایی با PuppyGraph🐾

تصور کنید داده‌های شما در دیتابیس‌های کلاسیک رابطه‌ای مثل #PostgreSQL یا در دیتالِیک‌هایی مثل #Snowflake یا #Iceberg ذخیره شده‌اند.

حجم داده‌ها بالاست، اتصال‌ها پیچیده‌اند، و شما به‌عنوان مهندس داده می‌خواهید تحلیل‌های ارتباطی اجرا کنید:

مثل کشف مسیرهای غیرمستقیم بین کاربران، تشخیص حلقه‌های تراکنشی، یا تحلیل وابستگی در جریان داده.

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

عملیات #ETL سنگین و زمان‌بر ⏳

نیاز به زیرساخت گراف مستقل ⚙️

مشکلات همگام‌سازی داده بین دو سیستم 🔄


💡 اینجا PuppyGraph وارد می‌شود

پاپی‌گراف یک Graph Query Engine مدرن و سریع است که با یک رویکرد ساده و انقلابی کار می‌کند:

«به‌جای انتقال داده به یک گراف‌دیتابیس، چرا گراف را همان‌جا که داده هست اجرا نکنیم؟»


🔍 چه چیزی PuppyGraph را متفاوت می‌کند؟

✅ بدون ETL: مستقیماً روی منابع داده‌ای مانند PostgreSQL، MySQL، Snowflake، Delta Lake یا Iceberg کار می‌کند.

✅ بدون کپی داده: داده در محل خود باقی می‌ماند، PuppyGraph فقط آن را گرافی تفسیر می‌کند.

✅ اجرای سریع کوئری‌های چندهاپی: حتی 10-hop traversal در کمتر از چند ثانیه، روی میلیاردها لبه.

✅ سازگار با زبان‌های گراف استاندارد: از Gremlin و Cypher برای کوئری استفاده کنید، درست مثل Neo4j.

✅ معماری مقیاس‌پذیر و توزیع‌شده: طراحی‌شده برای محیط‌های تحلیلی مدرن، با تفکیک compute و storage.


🎯 چه کاربردهایی دارد؟

موتور تحلیل گراف PuppyGraph به‌ویژه برای تحلیل‌هایی که ماهیت گرافی دارند عالی است، از جمله:

✅ کشف تقلب در تراکنش‌ها یا شبکه‌های مالی

✅ تحلیل رفتار کاربران و مسیرهای ارتباطی آن‌ها

✅ درک ساختارهای وابستگی در خطوط داده یا سیستم‌ها

✅ تحلیل شبکه‌های سازمانی، صنعتی یا IoT

✅ ساخت گراف مفهومی از داده‌های پراکنده بدون زیرساخت جدید


🧪 تجربه کار با PuppyGraph

راه‌اندازی آن ساده است: با Docker یا روی Databricks و AWS در کمتر از ۱۰ دقیقه آماده کار می‌شود.

تنها کاری که باید بکنید تعریف اسکیمای گرافی با چند خط JSON است—و بعد می‌توانید همان داده‌ای را که همیشه با SQL کوئری می‌کردید، این‌بار از منظر گراف ببینید و تحلیل کنید.


🐶 چرا اسمش PuppyGraph است؟

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

📣 اگر تجربه‌ای در گراف‌تحلیل داشته‌اید یا دنبال راهی برای اجرای گراف روی داده‌های رابطه‌ای بدون مهاجرت هستید، PuppyGraph قطعاً یکی از گزینه‌هایی است که باید آن را جدی بگیرید.


💼 و اما : وضعیت لایسنس و نسخه‌ها

نسخه رایگان و متن‌باز PuppyGraph با نام Developer Edition در دسترس است، اما این نسخه تنها از یک نود پشتیبانی می‌کند و برای محیط‌های کوچک و تستی مناسب است.

اگر بخواهید در محیط‌های تولیدی حرفه‌ای از آن استفاده کنید—با امکاناتی مثل مقیاس‌پذیری افقی، مانیتورینگ، چند کاربر و قابلیت‌های امنیتی پیشرفته—باید از نسخه Enterprise استفاده کنید که دارای مجوز تجاری و هزینه‌بر است اما هزینه آن از نگهداری یک دیتابیس گرافی جداگانه و پایپ‌لاین‌های ETL لازم برای ورود مداوم داده در آن، بسیار کمتر است.


#GraphAnalytics #DataEngineering #GraphDatabase #PuppyGraph

‍ بررسی تغییرات پایگاه‌های داده در نظرسنجی Stack Overflow 2025📊

نظرسنجی سالانه Stack Overflow برای سال 2025 منتشر شده و یافته‌های قابل‌توجهی را در خصوص روند استفاده از پایگاه‌های داده در میان توسعه‌دهندگان حرفه‌ای ارائه می‌دهد.

آدرس نظر سنجی :

Technology | 2025 Stack Overflow Developer Survey

در این پست نگاهی خواهیم داشت به وضعیت پستگرس‌کیوال (PostgreSQL)، رشدهای چشمگیر و همچنین کاهش‌ها و غیبت‌های معنادار. 🚀

🏆 پستگرس PostgreSQL: ادامه‌ سلطه با رشد پایدار

پستگرس با ثبت رشد ۱۰٪ نسبت به سال گذشته و رسیدن به نرخ استفاده ۵۵.۶٪، جایگاه نخست خود را در میان پایگاه‌های داده محبوب حفظ کرده است. از سال ۲۰۲۳، این پایگاه داده به‌عنوان "مطلوب‌ترین" (۴۶.۵٪) و "تحسین‌شده‌ترین" (۶۵.۵٪) گزینه نزد توسعه‌دهندگان شناخته می‌شود. 😍


🔍 دلایل اصلی محبوبیت PostgreSQL:

✅انعطاف‌پذیری بالا: پشتیبانی از داده‌های رابطه‌ای و غیررابطه‌ای مانند JSON.

✅جامعه متن‌باز قدرتمند: توسعه مداوم و اسناد جامع.

✅عملکرد مناسب برای سناریوهای پیچیده: پاسخ‌گویی به بارهای کاری سنگین و ساختارهای داده پیشرفته.

📈 پایگاه‌های داده با رشد چشمگیر

🎯 ردیس: با رشد ۱۰٪ به ۲۸٪ رسید و با عبور از MongoDB به رتبه پنجم صعود کرد. ⚡️ همچنین Valkey نیز با ۲.۵٪ ورود قابل‌توجهی به صحنه داشت.

🎯 الستیک سرچ: با افزایش ۵٪، به نرخ استفاده ۱۶.۷٪ رسید؛ رشدی معنادار برای این موتور جستجوی داده.

🎯 دیتابیس DuckDB: با دو برابر شدن سهم خود به ۳.۲٪، توجه‌ها را به سمت خود جلب کرده است.

🎯 خدمات ابری Supabase: از ۴.۱٪ به ۶٪ رسید و برای نخستین‌بار وارد جمع ۱۲ پایگاه داده برتر شد. 🎉

این رشد نشان‌دهنده‌ی پذیرش سریع این گزینه‌ی نوظهور به‌عنوان یک راهکار جایگزین و سبک برای پروژه‌های مدرن است.


📉 پایگاه‌های داده با کاهش استفاده

⚠️ مای اسکیوال MySQL: با کاهش جزئی به ۴۰.۵٪، روندی آهسته اما قابل مشاهده را تجربه کرده است.

⚠️مانگودی بی MongoDB: با رسیدن به ۲۴٪، افتی کمتر از پیش‌بینی‌ها داشته، اما جایگاه خود را در رقابت از دست داده است.


❌ غایب بزرگ

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


🌟 تمایل توسعه‌دهندگان به یادگیری PostgreSQL

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


💡 چرا این موضوع تمایل به استفاده از پستگرس اهمیت دارد؟

انتخاب پایگاه داده مناسب، مستقیماً بر عملکرد، مقیاس‌پذیری و آینده‌پژوهی پروژه‌ها تأثیر می‌گذارد. PostgreSQL با ترکیبی از عملکرد قدرتمند، انعطاف‌پذیری بالا و جامعه پشتیبان گسترده، همچنان انتخاب نخست بسیاری از تیم‌های توسعه است.

#StackOverflow2025 #PostgreSQL #Database #توسعه_نرم‌افزار #فناوری #دیتابیس #تحلیل_داده

‍ عامل‌های هوشمند در مهندسی داده؛ مسیر نوین اتوماسیون و بهینه‌سازی زیرساخت‌ها 🤖

به دنبال راهکاری برای بررسی خودکار متریک‌های Prometheus و ارزیابی دقیق آن‌ها به کمک عامل‌های هوشمند بودم که به سایت

https://mseep.ai

برخوردم — ( تصویر پست از نتیجه یک جستجو در این سایت برداشته شده است).

با کمال تعجب دیدم که تعداد قابل توجهی MCP Server برای ابزارهای مختلف حوزه مهندسی داده در دسترس است و چه پتانسیل بزرگی در این حوزه نهفته است.


🤖 سوال: MCP Server چیست و چرا مهم است؟

سرورهای #MCP امکان اتصال عامل‌های هوشمند به ابزارهای مختلف را فراهم می‌کنند تا بتوان داده‌های لحظه‌ای را در اختیار عامل‌های هوشمند قرار داد و امکان اجرای دستورات مختلف را روی این ابزارها به این عامل هوشمند داد. حالا ما می‌توانیم با این سرورهای واسط، کارهای تکراری و زمان‌بر در حوزه زیرساخت و مهندسی داده را به صورت خودکار و هوشمند انجام دهیم. این فناوری در مهندسی داده می تواند تغییرات بنیادین ایجاد کند.

نسخه آموزشی سریع این فناوری را از این آدرس دانلود کنید :

https://t.iss.one/bigdata_ir/424


🔍 قابلیت‌های کاربردی عامل‌های هوشمند

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

✅پایش و تحلیل مداوم متریک‌های #Prometheus

✅بررسی و تفسیر خودکار لاگ‌ها و خطاها

✅تحلیل کوئری‌های کند در #PostgreSQL و بهینه‌سازی ایندکس‌ها

✅نظارت بر داشبوردهای Grafana و واکنش سریع به شرایط بحرانی

....


⚙️ چطور شروع کنیم؟

📌نصب MCP Server مناسب از منابعی مانند mseep.ai

📌نوشتن پرامپت‌های کاربردی مثل:

🎯«هر یک ساعت کوئری‌های کند را بررسی کن»

🎯«در صورت بروز خطا پیامک یا اطلاع در تلگرام بفرست»

🎯«خودکار عملیات ری‌ایندکس را انجام بده»

📌تعریف زمان‌بندی اجرای اتوماتیک


🚀شروع ساده‌تر با ابزارهای کم‌کد مانند #N8N

ابزارهای کم‌کد و بدون کد مانند #N8N این فرایند را به شدت آسان می‌کنند و امکان استفاده از نودهای هوش مصنوعی را فراهم می‌آورند تا بدون نیاز به برنامه‌نویسی سنگین، اتوماسیون پیشرفته بسازید.


🌟 نگاهی به آینده مهندسی داده

هوش مصنوعی نه تنها در اتوماسیون روتین بلکه در حوزه‌های گسترده‌تری مانند طراحی مدل‌های داده، مستندسازی، رفع خطا و حتی طراحی و اجرای پایپ‌لاین‌های داده نقش مهمی ایفا خواهد کرد. ابزارهایی مثل #Kestra و Bento نمونه‌های موفقی هستند که با توصیف‌های متنی (#YAML) امکان ساخت و اجرای ورک‌فلوهای داده‌ای را به سادگی فراهم می‌کنند.

‍ آغاز به کار رسمی مدرسه مهندسی داده سپهرام

با افتخار اعلام می‌کنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.

🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨


در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:

🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL

🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده

⚡️ پردازش داده‌های عظیم با #ApacheSpark

🔄 پردازش جریان‌های داده در #Kafka

📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها

🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ


🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:

- هر درس شامل چند آزمون کوتاه و مفهومی است.

- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.


💬 در صورت بروز مشکل در مسیر آموزشی یا هنگام انجام آزمون‌ها، می‌توانید از طریق پیام‌رسان‌های تلگرام، واتساپ یا بله با حساب پشتیبانی مدرسه مهندسی داده سپهرام در ارتباط باشید:

📌 شناسه پشتیبانی: @sepahram_ir

🙌 به عنوان موسس و مدرس اصلی این مدرسه، امیدوارم سپهرام گامی مؤثر در جهت توانمندسازی جامعه فارسی‌زبان در مسیر حرفه‌ای مهندسی داده باشد.

🔗 جزئیات بیشتر و ثبت‌نام:

https://sepahram.ir/courses/intro-to-data-engineering

کانال رسمی سپهرام :

https://t.iss.one/sepahram_school

‍ ورکشاپ جدید مدرسه مهندسی داده سپهرام - آشنایی با ساختار فیزیکی پستگرس منتشر شد!

در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام، این‌بار به سراغ سازوکار ذخیره‌سازی فیزیکی داده‌ها در #PostgreSQL رفتیم.

در این جلسه با اجرای #PostgreSQL نسخه ۱۸ در محیط Docker، ساختار درونی ذخیره داده‌ها را از نزدیک بررسی کردیم.

خلاصه اینکه : ✨فایل‌های داده در پستگرس از واحدهایی به نام Page (یا Block) تشکیل می‌شوند؛ هر Page معمولاً ۸ کیلوبایت حجم دارد و کوچک‌ترین بخش قابل خواندن یا نوشتن در دیسک است.

✨ هر Page شامل اطلاعات مدیریتی، اشاره‌گرهای رکوردها، فضای خالی، و خود داده‌هاست. هنگام درج یا به‌روزرسانی رکورد، #PostgreSQL بر اساس فضای خالی موجود تصمیم می‌گیرد که داده را در همان Page یا Page جدید ذخیره کند. این رفتار در عمل، پایه‌ی مفهومی به نام Heap است - یعنی ذخیره‌سازی بدون ترتیب خاص.

✨در کارگاه دیدیم که با به‌روزرسانی رکوردها، نسخه‌های جدید در انتهای Page درج می‌شوند و نسخه‌های قبلی تا اجرای فرآیند VACUUM در فایل باقی می‌مانند. همچنین با تعیین fillfactor=70 برای جدول users2، مشاهده کردیم که چگونه فضای آزاد در Page باعث درج نسخه‌های جدید در همان Page می‌شود.


📘 آنچه در این کارگاه انجام دادیم:

🔰راه‌اندازی PostgreSQL 18 با Docker

🔰بررسی ساختار پوشه‌های base و global و مفهوم OID

🔰درج و به‌روزرسانی داده‌ها و تحلیل رفتار Pageها

🔰بررسی عملی Heap و نقش پارامتر fillfactor


📺 فیلم کامل ورکشاپ در یوتیوب مدرسه:

🔗 https://youtu.be/H3ET3i7XsXw

💾 فایل‌ها و اسکریپت‌ها در گیت‌هاب سپهرام:

👉 https://github.com/sepahram-school/workshops

دوره در حال برگزاری پستگرس : https://sepahram.ir/courses/postgresql

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟

‍ وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥

در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.

در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇

🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console

🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda

🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها

🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV

🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها

این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.

📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:

👉 🔗 https://youtu.be/nu_L4OSRUZc

🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.

برای مشاهده دوره‌ها به آدرس زیر مراجعه کنید:

🌐 https://sepahram.ir/courses/

📢 کانال رسمی سپهرام در تلگرام:

📬 https://t.iss.one/sepahram_school

🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده

‍ وقتی SQL هم حلقه For دارد! نگاهی به Lateral Join در PostgreSQL

اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع JOIN‌های معمول در SQL مثل INNER JOIN و LEFT JOIN آشنا هستید.

اما یکی از جوین‌هایی که کمتر درباره‌اش صحبت می‌شود و در عین حال بسیار مفید و کاربردی محسوب می‌شود، LATERAL JOIN است.

بیایید با یک مثال شروع کنیم 👇

فرض کنید یک جدول از محصولات دارید و می‌خواهید برای هر محصول، آمارهایی مثل:

🔰 مجموع کل فروش،

🔰حجم فروش،

🔰تعداد مشتریان منحصربه‌فرد،

🔰و میانگین فروش

در سه ماه گذشته را به‌دست آورید (به تفکیک ماه).

اگر بخواهید این کار را با زبان‌هایی مثل Python یا JavaScript انجام دهید، معمولاً یک حلقه (for) روی تمام محصولات اجرا می‌کنید و درون آن، برای هر محصول، محاسبات آماری مربوط به فروش را انجام می‌دهید.

در واقع، یک حلقه بیرونی برای محصولات و یک حلقه داخلی برای فروش‌های هر محصول دارید. در SQL هم می‌توان دقیقاً همین رفتار را شبیه‌سازی کرد: با استفاده از LATERAL JOIN.

اینجاست که Lateral مثل یک پل ارتباطی عمل می‌کند:

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

به همین دلیل معمولاً از CROSS JOIN LATERAL استفاده می‌کنیم، چون شرط اتصال درون زیرکوئری و با WHERE تعریف می‌شود و در اینجا Inner Join معنا نخواهد داشت.

💫 نتیجه این رهیافت

می‌توانید به‌سادگی کوئری‌هایی بنویسید که مثلاً:

🌟 «ده محصول پرفروش هر کتگوری» را پیدا کند،

🌟یا برای هر مشتری، آخرین تراکنش ثبت‌شده‌اش را نمایش دهد،

🌟یا حتی تحلیل‌های زمانی و Top-N را مستقیماً داخل SQL انجام دهد: بدون نیاز به کدهای پیچیده و توابع پنجره‌ای


🎥 برای آشنایی دقیق‌تر با این مفهوم، یک ویدئوی آموزشی حدود ۴۰ دقیقه‌ای آماده کرده‌ام که در آن، با مثال‌های واقعی و کاربردی نحوه‌ی استفاده از LATERAL JOIN را گام‌به‌گام توضیح داده‌ام.

🔗 لینک مشاهده ویدئو در یوتیوب:

👉 https://youtu.be/vVc2EewTSQU


💡 در این ویدئو یاد موارد زیر را به صورت عملی مرور می‌کنیم:

✅ایده‌ی اصلی و کاربرد LATERAL JOIN

✅تفاوت آن با جوین‌های معمول

✅نوشتن کوئری‌های Top-N per Group

✅تحلیل داده‌های واقعی (مشتریان، فروش، زمان)

✅و نکات مهم برای بهینه‌سازی عملکرد کوئری


📚 این ویدئو بخشی از دوره‌ی PostgreSQL Practical Course در مدرسه مهندسی داده سپهرام است.

👉 https://sepahram.ir/courses


#PostgreSQL #SQL #DataEngineering #Database #LateralJoin #Sepahram #BigData #PostgresTutorial #Analytics