🔵 عنوان مقاله
Understanding and Setting Postgres JDBC Fetch Size
🟢 خلاصه مقاله:
این مقاله اهمیت تنظیم درست Fetch Size در JDBC برای Postgres را توضیح میدهد: مقدار پیشفرض 0 عملاً کل نتایج را یکباره در حافظه میریزد و برای حجمهای بزرگ خطرناک است. برای استریم واقعی باید auto-commit را خاموش کنید (setAutoCommit(false)) و روی Statement/PreparedStatement مقدار setFetchSize(n) بگذارید یا از defaultRowFetchSize در اتصال استفاده کنید؛ در حالت auto-commit فعال، درایور از cursor سمت سرور استفاده نمیکند و Fetch Size نادیده گرفته میشود. انتخاب مقدار به اندازه ردیفها، تأخیر شبکه و حافظه بستگی دارد؛ معمولاً 100 تا 1000 شروع خوبی است و برای ردیفهای بزرگ (JSON/BYTEA) بهتر است مقدار کوچکتر باشد. در Spring JdbcTemplate و jOOQ میتوانید fetchSize را مستقیم تنظیم کنید؛ در JPA/Hibernate برای استریم با PostgreSQL علاوه بر hibernate.jdbc.fetch_size معمولاً نیاز به ResultSet رو به جلو و auto-commit خاموش دارید. حواستان باشد استریم باعث باز ماندن تراکنش میشود و میتواند VACUUM را به تأخیر بیندازد؛ پس جریانها را کوتاه نگه دارید و برای سناریوهای تعاملی از صفحهبندی استفاده کنید. این موضوع اخیراً در Golang Weekly برجسته شده است و برای تیمهایی که Java و Go را ترکیب میکنند کاربردی است.
#PostgreSQL #JDBC #FetchSize #DatabasePerformance #Java #GolangWeekly #Streaming #PerformanceTuning
🟣لینک مقاله:
https://postgresweekly.com/link/175727/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Understanding and Setting Postgres JDBC Fetch Size
🟢 خلاصه مقاله:
این مقاله اهمیت تنظیم درست Fetch Size در JDBC برای Postgres را توضیح میدهد: مقدار پیشفرض 0 عملاً کل نتایج را یکباره در حافظه میریزد و برای حجمهای بزرگ خطرناک است. برای استریم واقعی باید auto-commit را خاموش کنید (setAutoCommit(false)) و روی Statement/PreparedStatement مقدار setFetchSize(n) بگذارید یا از defaultRowFetchSize در اتصال استفاده کنید؛ در حالت auto-commit فعال، درایور از cursor سمت سرور استفاده نمیکند و Fetch Size نادیده گرفته میشود. انتخاب مقدار به اندازه ردیفها، تأخیر شبکه و حافظه بستگی دارد؛ معمولاً 100 تا 1000 شروع خوبی است و برای ردیفهای بزرگ (JSON/BYTEA) بهتر است مقدار کوچکتر باشد. در Spring JdbcTemplate و jOOQ میتوانید fetchSize را مستقیم تنظیم کنید؛ در JPA/Hibernate برای استریم با PostgreSQL علاوه بر hibernate.jdbc.fetch_size معمولاً نیاز به ResultSet رو به جلو و auto-commit خاموش دارید. حواستان باشد استریم باعث باز ماندن تراکنش میشود و میتواند VACUUM را به تأخیر بیندازد؛ پس جریانها را کوتاه نگه دارید و برای سناریوهای تعاملی از صفحهبندی استفاده کنید. این موضوع اخیراً در Golang Weekly برجسته شده است و برای تیمهایی که Java و Go را ترکیب میکنند کاربردی است.
#PostgreSQL #JDBC #FetchSize #DatabasePerformance #Java #GolangWeekly #Streaming #PerformanceTuning
🟣لینک مقاله:
https://postgresweekly.com/link/175727/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🛩️ Shane Borden's Technology Blog
Understanding and Setting PostgreSQL JDBC Fetch Size
By default, the PostgreSQL JDBC driver fetches all rows at once and attempts to load them into memory vs. other drivers such as Oracle that by default only fetches 10 rows at a time. Both defaults …
🔵 عنوان مقاله
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? (9 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد که در جدولهای Iceberg، چیدمان Stream-order با حفظ ترتیب ورود داده برای پردازش ترتیبی و راهاندازی سریع جریانها مناسب است، در حالیکه چیدمان Batch-order با خوشهبندی دادهها کارایی پرسوجوهای تحلیلی را بهینه میکند. تلاش برای پشتیبانی همزمان هر دو نیاز در یک جدول، به سربار محاسباتی پنهان منجر میشود؛ بهویژه هنگام راهاندازی jobهای جریانی از دادههای Batch-order که مستلزم مرتبسازی و shuffling پرهزینه است. نتیجه این است که صرفهجویی ظاهری در فضای ذخیرهسازی با افزایش هزینههای محاسباتی از بین میرود. راهکار پیشنهادی، Confluent Tableflow است که دادههای جریانی را در Iceberg مادیسازی میکند و با نگهداشتن نمای مناسب برای هر سناریو، انعطافپذیری و کارایی بهتری ارائه میدهد—even اگر به معنای تقریباً دو برابر شدن فضای ذخیرهسازی باشد.
#ApacheIceberg #Streaming #BatchProcessing #DataEngineering #Confluent #Tableflow #DataLake #Lakehouse
🟣لینک مقاله:
https://jack-vanlightly.com/blog/2025/11/5/how-would-you-like-your-iceberg-sir-stream-or-batch-ordered?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? (9 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد که در جدولهای Iceberg، چیدمان Stream-order با حفظ ترتیب ورود داده برای پردازش ترتیبی و راهاندازی سریع جریانها مناسب است، در حالیکه چیدمان Batch-order با خوشهبندی دادهها کارایی پرسوجوهای تحلیلی را بهینه میکند. تلاش برای پشتیبانی همزمان هر دو نیاز در یک جدول، به سربار محاسباتی پنهان منجر میشود؛ بهویژه هنگام راهاندازی jobهای جریانی از دادههای Batch-order که مستلزم مرتبسازی و shuffling پرهزینه است. نتیجه این است که صرفهجویی ظاهری در فضای ذخیرهسازی با افزایش هزینههای محاسباتی از بین میرود. راهکار پیشنهادی، Confluent Tableflow است که دادههای جریانی را در Iceberg مادیسازی میکند و با نگهداشتن نمای مناسب برای هر سناریو، انعطافپذیری و کارایی بهتری ارائه میدهد—even اگر به معنای تقریباً دو برابر شدن فضای ذخیرهسازی باشد.
#ApacheIceberg #Streaming #BatchProcessing #DataEngineering #Confluent #Tableflow #DataLake #Lakehouse
🟣لینک مقاله:
https://jack-vanlightly.com/blog/2025/11/5/how-would-you-like-your-iceberg-sir-stream-or-batch-ordered?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Jack Vanlightly
How Would You Like Your Iceberg Sir? Stream or Batch Ordered? — Jack Vanlightly
Today I want to talk about stream analytics, batch analytics and Apache Iceberg. Stream and batch analytics work differently but both can be built on top of Iceberg, but due to their differences there can be a tug-of-war over the Iceberg table itself. In…