🔵 عنوان مقاله
xlDuckDb (GitHub Repo)
🟢 خلاصه مقاله:
شرکتهای فناوری همواره در حال توسعه ابزارهای جدید برای افزایش بهرهوری کاربران هستند. یکی از این نوآوریها، افزونهای است که به کاربر امکان میدهد تا به راحتی از قدرت پایگاههای داده DuckDB در محیط Excel بهرهمند شود. این افزونه، با افزودن تابعی به نام DuckDbQuery()، اجازه میدهد که کاربران به سادگی دستورات SQL مربوط به DuckDB را مستقیماً در جدولهای اکسل اجرا کنند و نتایج را به طور مستقیم در سلولهای مورد نظر خود مشاهده کرده و استفاده کنند. این ویژگی به خصوص در هنگام کار با دادههای بزرگ و پیچیده که نیازمند تحلیل سریع و دقیق است، بسیار مفید و کارآمد است.
با بهرهگیری از این ابزار، کاربران قادر خواهند بود تا به صورت مستقیم و بدون نیاز به انتقال دادهها به محیطهای دیگر، از دادههای موجود در صفحات کاری، جداول، و فایلهای محلی یا راه دوری مانند JSON، CSV و Parquet بهرهمند شوند. این فرآیند، کارایی و انعطافپذیری استفاده از دادهها در Excel را به شکل قابل توجهی افزایش میدهد و توانمندیهای تحلیل داده را چند برابر میکند.
در نتیجه، این افزونه یک راه حل جامع برای کسانی است که میخواهند دادههای مختلف را در یک محیط یکپارچه و کاربرپسند مدیریت و تحلیل کنند. این ابزار نوآورانه، امکان اجرای کوئریهای پیچیده و بهروز را در کنار سادگی کاربری، فراهم میآورد و کمک میکند تا کاربران توانمندتر و کارآمدتر در پروژههای مربوط به داده کار کنند.
#داده #اکسل #پایگاهداده #تحلیل داده
🟣لینک مقاله:
https://github.com/RusselWebber/xlDuckDb?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
xlDuckDb (GitHub Repo)
🟢 خلاصه مقاله:
شرکتهای فناوری همواره در حال توسعه ابزارهای جدید برای افزایش بهرهوری کاربران هستند. یکی از این نوآوریها، افزونهای است که به کاربر امکان میدهد تا به راحتی از قدرت پایگاههای داده DuckDB در محیط Excel بهرهمند شود. این افزونه، با افزودن تابعی به نام DuckDbQuery()، اجازه میدهد که کاربران به سادگی دستورات SQL مربوط به DuckDB را مستقیماً در جدولهای اکسل اجرا کنند و نتایج را به طور مستقیم در سلولهای مورد نظر خود مشاهده کرده و استفاده کنند. این ویژگی به خصوص در هنگام کار با دادههای بزرگ و پیچیده که نیازمند تحلیل سریع و دقیق است، بسیار مفید و کارآمد است.
با بهرهگیری از این ابزار، کاربران قادر خواهند بود تا به صورت مستقیم و بدون نیاز به انتقال دادهها به محیطهای دیگر، از دادههای موجود در صفحات کاری، جداول، و فایلهای محلی یا راه دوری مانند JSON، CSV و Parquet بهرهمند شوند. این فرآیند، کارایی و انعطافپذیری استفاده از دادهها در Excel را به شکل قابل توجهی افزایش میدهد و توانمندیهای تحلیل داده را چند برابر میکند.
در نتیجه، این افزونه یک راه حل جامع برای کسانی است که میخواهند دادههای مختلف را در یک محیط یکپارچه و کاربرپسند مدیریت و تحلیل کنند. این ابزار نوآورانه، امکان اجرای کوئریهای پیچیده و بهروز را در کنار سادگی کاربری، فراهم میآورد و کمک میکند تا کاربران توانمندتر و کارآمدتر در پروژههای مربوط به داده کار کنند.
#داده #اکسل #پایگاهداده #تحلیل داده
🟣لینک مقاله:
https://github.com/RusselWebber/xlDuckDb?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - RusselWebber/xlDuckDb: Use DuckDB within Excel with the xlDuckDb addin
Use DuckDB within Excel with the xlDuckDb addin. Contribute to RusselWebber/xlDuckDb development by creating an account on GitHub.
🔵 عنوان مقاله
5 CDC tools and the tradeoffs you should know (14 minute read)
🟢 خلاصه مقاله:
ارزیابی ابزارهای CDC باید بر رفتارهای شکست تمرکز داشته باشد، نه فقط تعداد کانکتورها. در شروع این فرآیند، مهم است که به روشهای ضبط داده، وضعیت اولیه سنیپشاتها و فرآیندهای پشتیبانگیری، تکامل ساختار دادهها، semantics تحویل، قابلیت مشاهده وضعیت، مدل استقرار و نقش مالکیت بازیابی توجه کنیم. برای اثبات قابلیت اعتماد در محیط تولید، باید از دادههای نماینده و آزمونهای شکست در مقصد استفاده کنیم؛ به ویژه برای حفظ صحت نوع دادهها و مدیریت تکراریها. این رویکرد جامع به ما کمک میکند تا ابزارهای CDC را بهتر ارزیابی و انتخاب کنیم و نقاط قوت و محدودیت هر یک را بشناسیم، بنابراین تصمیمگیری در مورد فناوری مناسب بسیار مؤثرتر خواهد بود.
#ابزارهای_CDC #تحلیل_فناوری #مدیریت_داده #پایش_سیستم
🟣لینک مقاله:
https://www.theseattledataguy.com/5-cdc-tools-and-the-tradeoffs-you-should-know/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
5 CDC tools and the tradeoffs you should know (14 minute read)
🟢 خلاصه مقاله:
ارزیابی ابزارهای CDC باید بر رفتارهای شکست تمرکز داشته باشد، نه فقط تعداد کانکتورها. در شروع این فرآیند، مهم است که به روشهای ضبط داده، وضعیت اولیه سنیپشاتها و فرآیندهای پشتیبانگیری، تکامل ساختار دادهها، semantics تحویل، قابلیت مشاهده وضعیت، مدل استقرار و نقش مالکیت بازیابی توجه کنیم. برای اثبات قابلیت اعتماد در محیط تولید، باید از دادههای نماینده و آزمونهای شکست در مقصد استفاده کنیم؛ به ویژه برای حفظ صحت نوع دادهها و مدیریت تکراریها. این رویکرد جامع به ما کمک میکند تا ابزارهای CDC را بهتر ارزیابی و انتخاب کنیم و نقاط قوت و محدودیت هر یک را بشناسیم، بنابراین تصمیمگیری در مورد فناوری مناسب بسیار مؤثرتر خواهد بود.
#ابزارهای_CDC #تحلیل_فناوری #مدیریت_داده #پایش_سیستم
🟣لینک مقاله:
https://www.theseattledataguy.com/5-cdc-tools-and-the-tradeoffs-you-should-know/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Seattle Data Guy
5 CDC Tools and the Tradeoffs You Should Know - Seattle Data Guy
Not every data pipeline or process needs to be real-time. In fact, in my experience, often times when clients ask for real-time they mean daily or hourly loads. But, every so often there are use cases where real-time is required. Beyond how frequently a data…
🔵 عنوان مقاله
Jitter is the cheapest reliability fix you are not using (5 minute read)
🟢 خلاصه مقاله:
سیستمهای توزیعشده به طور طبیعی و بدون نیاز به دستور، همگام میشوند و عملیات مشترکی مانند استقرار برنامهها، پاکسازی کش، یا از دست رفتن اتصال، باعث میشود بار کاری مستقلها به صورت ناگهانی و مکرر افزایش یابد. این نوسانهای موقت که در اصطلاح فنی به آنها "جیتور" گفته میشود، نقش مهمی در کنترل این نوع ترافیکها ایفا میکنند. با افزودن جیتور به عملیاتهایی مانند تلاشهای اولیه مجدد، بروزرسانیهای TTL، نگهداشتن فعالیتهای قلب (heartbeats)، تمدید توکنها و اجرای وظایف زمانبندی شده، میتوان بار متوسط سیستم را حفظ کرد و همزمان از بروز ترافیکهای سنگین و همزمان جلوگیری کرد. این کار به جلوگیری از "طوفان تکراری" کمک میکند که در آن تعداد زیادی درخواست مجدد همزمان، توان سیستمهای پشتیبانی را تحت فشار قرار میدهند و ممکن است باعث اختلالهای گسترده شوند.
در واقع، افزودن جیتور یکی از ارزانترین و موثرترین روشهای بهبود قابلیت اطمینان سیستمهای توزیعشده است که شاید بسیاری از توسعهدهندگان آن را نادیده میگیرند. با تنظیم میزان نوسانپذیری در درخواستها، میتوان هم تدریجی بودن تکرار عملیاتها را تضمین و هم از نوسانات شدید جلوگیری کرد، بدون اینکه به هزینه زیادی نیاز باشد. این استراتژی نه تنها پایداری سیستم را افزایش میدهد، بلکه تجربه کاربری بهتر و کمتری اختلال دارد.
در نهایت، استفاده از جیتور یکی از موارد ساده ولی بسیار مهم در طراحی سیستمهای مقاوم و مقیاسپذیر است که دانستن و بهکارگیری آن میتواند تفاوت بزرگی در عملکرد و قدرت تحمل سیستمهای توزیعشده شما ایجاد کند.
#سیستم_توزیع_شده #پایداری_سیستم #مهندسی_نرمافزار #بهبود_عملکرد
🟣لینک مقاله:
https://ankit-rana.com/logs/49-jitter-synchronised-clients/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Jitter is the cheapest reliability fix you are not using (5 minute read)
🟢 خلاصه مقاله:
سیستمهای توزیعشده به طور طبیعی و بدون نیاز به دستور، همگام میشوند و عملیات مشترکی مانند استقرار برنامهها، پاکسازی کش، یا از دست رفتن اتصال، باعث میشود بار کاری مستقلها به صورت ناگهانی و مکرر افزایش یابد. این نوسانهای موقت که در اصطلاح فنی به آنها "جیتور" گفته میشود، نقش مهمی در کنترل این نوع ترافیکها ایفا میکنند. با افزودن جیتور به عملیاتهایی مانند تلاشهای اولیه مجدد، بروزرسانیهای TTL، نگهداشتن فعالیتهای قلب (heartbeats)، تمدید توکنها و اجرای وظایف زمانبندی شده، میتوان بار متوسط سیستم را حفظ کرد و همزمان از بروز ترافیکهای سنگین و همزمان جلوگیری کرد. این کار به جلوگیری از "طوفان تکراری" کمک میکند که در آن تعداد زیادی درخواست مجدد همزمان، توان سیستمهای پشتیبانی را تحت فشار قرار میدهند و ممکن است باعث اختلالهای گسترده شوند.
در واقع، افزودن جیتور یکی از ارزانترین و موثرترین روشهای بهبود قابلیت اطمینان سیستمهای توزیعشده است که شاید بسیاری از توسعهدهندگان آن را نادیده میگیرند. با تنظیم میزان نوسانپذیری در درخواستها، میتوان هم تدریجی بودن تکرار عملیاتها را تضمین و هم از نوسانات شدید جلوگیری کرد، بدون اینکه به هزینه زیادی نیاز باشد. این استراتژی نه تنها پایداری سیستم را افزایش میدهد، بلکه تجربه کاربری بهتر و کمتری اختلال دارد.
در نهایت، استفاده از جیتور یکی از موارد ساده ولی بسیار مهم در طراحی سیستمهای مقاوم و مقیاسپذیر است که دانستن و بهکارگیری آن میتواند تفاوت بزرگی در عملکرد و قدرت تحمل سیستمهای توزیعشده شما ایجاد کند.
#سیستم_توزیع_شده #پایداری_سیستم #مهندسی_نرمافزار #بهبود_عملکرد
🟣لینک مقاله:
https://ankit-rana.com/logs/49-jitter-synchronised-clients/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Ankit Rana
Jitter is the cheapest reliability fix you are not using | Ankit Rana
Why independent clients converge on the same instant without any coordination, how retries, cron schedules, health checks and reconnects all self-synchronise, and why adding randomness is a one line fix for a class of outage.
🔵 عنوان مقاله
Built for reliability: How American Express processes payments at scale (12 minute read)
🟢 خلاصه مقاله:
شرکت امریکن اکسپرس بر پایهای قدرتمند و قابل اعتماد ساخته شده است که هدف آن تضمین عملکرد مطمئن و ادامهدار در حین پردازش تعداد زیادی تراکنش است. در این سیستم، بخشهای مختلف عملیاتی به عنوان «سلول»های جداگانه طراحی شدهاند؛ هر سلول شامل سرویسهای میکروی، پایگاههای داده، سامانههای DNS و دادههای مرجع است که همه محلی و مستقل عمل میکنند. این سیستم به گونهای طراحی شده است که تراکنشهای پویا و در حال تغییر، بر اساس میزان و نوع فعالیت در هر تراکنش، به سلول مربوطه که وضعیت آن را در اختیار دارد، هدایت شوند. این معماری به شرکت امکان میدهد دامنههای شکست محدود و کنترلشدهای را تجربه کند؛ یعنی در صورت بروز خطا، سیستم به جای نگرانی درباره همگامسازی جهانی، تمرکز خود را بر روی حفظ پایداری و کنترل خطاهای جزئی میگذارد.
این رویکرد، در مقابل نیاز به هماهنگی جهانی، مزیت مهمی دارد؛ چرا که امکان میدهد سیستم در مقابل مشکلات یا هرگونه ناهماهنگی، واکنش سریعتری نشان دهد و عملیات خود را ادامه دهد. بنابراین، امریکن اکسپرس در طراحی خود، به صورت آگاهانه تراکنشهایی را که نمیتوانند همزمان و کامل مطابقت داده شوند، رد میکند. این تصمیم، به معنای آن است که کنترل و صحت دادهها در اولویت قرار دارد و از انجام عملیات ناقص یا ناسازگار جلوگیری میشود تا سیستم همواره قابل اعتماد باقی بماند.
در نتیجه، این طراحی خاص نه تنها موجب افزایش مقاومت پذیری و پایداری بالا میشود، بلکه با کاهش وابستگی به همگامسازی جهانی، توانسته است مقیاسپذیری و سرعت در پردازش تعداد عظیمی تراکنش را بهبود ببخشد. این روش، نمونهای کلاسیک از رویکردهای مهندسی سیستمهای توزیع شده است که هدف آن تضمین عملکرد بینظیر و در عین حال مقاوم در برابر خطاها است.
#پردازش_پولی #سیستم_مقاوم #توزیع_شده #خرده_فناوری
🟣لینک مقاله:
https://blog.bytebytego.com/p/built-for-reliability-how-american?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Built for reliability: How American Express processes payments at scale (12 minute read)
🟢 خلاصه مقاله:
شرکت امریکن اکسپرس بر پایهای قدرتمند و قابل اعتماد ساخته شده است که هدف آن تضمین عملکرد مطمئن و ادامهدار در حین پردازش تعداد زیادی تراکنش است. در این سیستم، بخشهای مختلف عملیاتی به عنوان «سلول»های جداگانه طراحی شدهاند؛ هر سلول شامل سرویسهای میکروی، پایگاههای داده، سامانههای DNS و دادههای مرجع است که همه محلی و مستقل عمل میکنند. این سیستم به گونهای طراحی شده است که تراکنشهای پویا و در حال تغییر، بر اساس میزان و نوع فعالیت در هر تراکنش، به سلول مربوطه که وضعیت آن را در اختیار دارد، هدایت شوند. این معماری به شرکت امکان میدهد دامنههای شکست محدود و کنترلشدهای را تجربه کند؛ یعنی در صورت بروز خطا، سیستم به جای نگرانی درباره همگامسازی جهانی، تمرکز خود را بر روی حفظ پایداری و کنترل خطاهای جزئی میگذارد.
این رویکرد، در مقابل نیاز به هماهنگی جهانی، مزیت مهمی دارد؛ چرا که امکان میدهد سیستم در مقابل مشکلات یا هرگونه ناهماهنگی، واکنش سریعتری نشان دهد و عملیات خود را ادامه دهد. بنابراین، امریکن اکسپرس در طراحی خود، به صورت آگاهانه تراکنشهایی را که نمیتوانند همزمان و کامل مطابقت داده شوند، رد میکند. این تصمیم، به معنای آن است که کنترل و صحت دادهها در اولویت قرار دارد و از انجام عملیات ناقص یا ناسازگار جلوگیری میشود تا سیستم همواره قابل اعتماد باقی بماند.
در نتیجه، این طراحی خاص نه تنها موجب افزایش مقاومت پذیری و پایداری بالا میشود، بلکه با کاهش وابستگی به همگامسازی جهانی، توانسته است مقیاسپذیری و سرعت در پردازش تعداد عظیمی تراکنش را بهبود ببخشد. این روش، نمونهای کلاسیک از رویکردهای مهندسی سیستمهای توزیع شده است که هدف آن تضمین عملکرد بینظیر و در عین حال مقاوم در برابر خطاها است.
#پردازش_پولی #سیستم_مقاوم #توزیع_شده #خرده_فناوری
🟣لینک مقاله:
https://blog.bytebytego.com/p/built-for-reliability-how-american?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Bytebytego
Built for Reliability: How American Express Processes Payments at Scale
In this article, we will try to understand how the transaction runs through such a cell-based architecture and how the payments are processed even when some services are failing.
Forwarded from VIP
🥇 اگر عاشق تکنولوژیهای روز دنیا هستی، اینجا هر روز تازهترین و مهمترین مطالب درباره:👇
🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژیهای نو
🔌 دنیای الکترونیک و گجتهای هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حملونقل
همه چیز بهصورت کوتاه، خلاصه و کاملاً قابلفهم👇👇
🥈 @futurepulse_persian
🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژیهای نو
🔌 دنیای الکترونیک و گجتهای هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حملونقل
همه چیز بهصورت کوتاه، خلاصه و کاملاً قابلفهم👇👇
🥈 @futurepulse_persian
🔵 عنوان مقاله
SQL/PGQ property graphs
🟢 خلاصه مقاله:
در نسخه ن وزدهم SQL/PGQ دیگر پشتیبانی نمیشود، اما هنوز پنج ویژگی مربوط به گرافهای ویژگی در این حوزه باقی مانده است. این ویژگیها که مربوط به کار با گرافهای پیچیده و دادههای ساختیافته در پایگاههای داده است، نقش مهمی در توسعه و بهبود قابلیتهای مدیریت دادهها بازی میکنند. هرچند برخی از امکانات قدیمیتر کنار گذاشته شدهاند، اما این پنج ویژگی همچنان ابزارهای قدرتمندی برای تحلیل و نمایش دادههای گرافی را فراهم میآورند که در برنامههای متعددی کاربرد دارند. این تغییرات نشان میدهد که جامعه توسعهدهندگان در حال جهتگیری به سمت ابزارهای مدرنتر و کارآمدتر است تا بتواند نیازهای پیچیدهتر کاربران را برآورده کند.
این امر به کاربران و توسعهدهندگان کمک میکند تا با بهرهگیری از قابلیتهای جدید، بتوانند ساختارهای پیچیدهتر و روابط میان دادهها را بهتر درک و مدیریت کنند. در نتیجه، تمرکز بر توسعه فناوریهای مرتبط با گرافها همچنان ادامه دارد و انتظار میرود این ویژگیها در نسخههای آینده بهبود یابند یا جایگزین شوند.
#گراف #پایگاهداده #تحلیل_داده #SQL
🟣لینک مقاله:
https://www.cybertec-postgresql.com/en/handling-graphs-with-sql-pgq-in-postgresql/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
SQL/PGQ property graphs
🟢 خلاصه مقاله:
در نسخه ن وزدهم SQL/PGQ دیگر پشتیبانی نمیشود، اما هنوز پنج ویژگی مربوط به گرافهای ویژگی در این حوزه باقی مانده است. این ویژگیها که مربوط به کار با گرافهای پیچیده و دادههای ساختیافته در پایگاههای داده است، نقش مهمی در توسعه و بهبود قابلیتهای مدیریت دادهها بازی میکنند. هرچند برخی از امکانات قدیمیتر کنار گذاشته شدهاند، اما این پنج ویژگی همچنان ابزارهای قدرتمندی برای تحلیل و نمایش دادههای گرافی را فراهم میآورند که در برنامههای متعددی کاربرد دارند. این تغییرات نشان میدهد که جامعه توسعهدهندگان در حال جهتگیری به سمت ابزارهای مدرنتر و کارآمدتر است تا بتواند نیازهای پیچیدهتر کاربران را برآورده کند.
این امر به کاربران و توسعهدهندگان کمک میکند تا با بهرهگیری از قابلیتهای جدید، بتوانند ساختارهای پیچیدهتر و روابط میان دادهها را بهتر درک و مدیریت کنند. در نتیجه، تمرکز بر توسعه فناوریهای مرتبط با گرافها همچنان ادامه دارد و انتظار میرود این ویژگیها در نسخههای آینده بهبود یابند یا جایگزین شوند.
#گراف #پایگاهداده #تحلیل_داده #SQL
🟣لینک مقاله:
https://www.cybertec-postgresql.com/en/handling-graphs-with-sql-pgq-in-postgresql/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
Handling graphs with SQL/PGQ in PostgreSQL
This blog explores Graph relationships in PostgreSQL with PGQ. Read and learn on, how to traverse and create Graph relationship.
🔵 عنوان مقاله
JupyterGIS 0.16: Collaborative story maps and remote geospatial workflows (3 minute read)
🟢 خلاصه مقاله:
نسخه ۰.۱۶ ابزار JupyterGIS به عنوان یک ابزار قدرتمند در حوزه اطلاعات جغرافیایی، ویژگیهای جدید و بسیار کاربردی را به مجموعه امکانات خود اضافه کرده است. یکی از این قابلیتها، امکان ایجاد نقشههای داستانی تعاملی و همزمان است، که به تیمهای جغرافیایی اجازه میدهد به صورت مشترک و در زمان واقعی روی پروژههایشان کار کنند و نظرها و تغییرات را به سرعت به اشتراک بگذارند. این ویژگی باعث افزایش هماهنگی در تیمهای چندنفره و تسهیل فرآیندهای تحلیل جغرافیایی میشود، زیرا همه اعضا میتوانند در کنفرانسهای تصویری درگیر شوند و نکات مورد نظر را مستقیم بر روی نقشهها مشاهده و ویرایش کنند.
علاوه بر این، در نسخه جدید، فناوریهای پیشرفتهتری برای بهبود کارایی در اجرای فرآیندهای از راه دور ارائه شده است. یکی از این فناوریها، پیادهسازی رندر کردن تنبل (Lazy Tile Rendering) است که به کاربران امکان میدهد بدون نیاز به بارگذاری کامل تمامی دادهها، نمای پیشفرض و جزئیات نقشه را به صورت سریع مشاهده کنند. این قابلیت به ویژه در پروژههایی که نیازمند همکاری در محیطهای ابری و در بستر شبکه هستند، بسیار مؤثر است و فرآیندهای تحلیل دادههای بزرگ جغرافیایی را سرعت میبخشد.
همچنین، JupyterGIS 0.16 از پشتیبانی بومی از استانداردهای GeoZarr و GeoPackage بهرهمند شده است. این امکانات به محققان و توسعهدهندگان اجازه میدهد تا دادههای جغرافیایی را به صورت مؤثر و بدون نیاز به تبدیلهای پیچیده مدیریت و ذخیره کنند. در کنار این، استفاده از سمبولسازیهای اعلامگرایانه و تقسیمبندی دادهها به بلوکهای Xarray، فرایند ایجاد و تکرار امور بصری را آسانتر کرده است؛ به گونهای که تصاویر و نمودارهای تولید شده قابلیت بازتولیدپذیری و همگامسازی سادهتر را دارند، در حالی که دادههای بزرگ در فضای ابری باقی میمانند و نیاز به انتقال یا ذخیرهسازی محلی ندارند.
در کل، نسخه جدید JupyterGIS ترکیبی از همکاری همزمان، عملکرد بهینه در بستر اینترنت، امکانات پیشرفته مدیریت دادههای جغرافیایی و ابزارهای نوآورانه برای تحلیلهای پیچیده ارائه میدهد که آن را به ابزار ایدهآلی برای متخصصان GIS و تیمهای تحقیقاتی تبدیل کرده است.
#اطلاعات_جغرافیایی #نقشه_درمانی #تحلیل_جغرافیایی #JupyterGIS
🟣لینک مقاله:
https://blog.jupyter.org/jupytergis-0-16-new-visualization-capabilities-collaborative-story-maps-and-more-03e6b78bacc0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
JupyterGIS 0.16: Collaborative story maps and remote geospatial workflows (3 minute read)
🟢 خلاصه مقاله:
نسخه ۰.۱۶ ابزار JupyterGIS به عنوان یک ابزار قدرتمند در حوزه اطلاعات جغرافیایی، ویژگیهای جدید و بسیار کاربردی را به مجموعه امکانات خود اضافه کرده است. یکی از این قابلیتها، امکان ایجاد نقشههای داستانی تعاملی و همزمان است، که به تیمهای جغرافیایی اجازه میدهد به صورت مشترک و در زمان واقعی روی پروژههایشان کار کنند و نظرها و تغییرات را به سرعت به اشتراک بگذارند. این ویژگی باعث افزایش هماهنگی در تیمهای چندنفره و تسهیل فرآیندهای تحلیل جغرافیایی میشود، زیرا همه اعضا میتوانند در کنفرانسهای تصویری درگیر شوند و نکات مورد نظر را مستقیم بر روی نقشهها مشاهده و ویرایش کنند.
علاوه بر این، در نسخه جدید، فناوریهای پیشرفتهتری برای بهبود کارایی در اجرای فرآیندهای از راه دور ارائه شده است. یکی از این فناوریها، پیادهسازی رندر کردن تنبل (Lazy Tile Rendering) است که به کاربران امکان میدهد بدون نیاز به بارگذاری کامل تمامی دادهها، نمای پیشفرض و جزئیات نقشه را به صورت سریع مشاهده کنند. این قابلیت به ویژه در پروژههایی که نیازمند همکاری در محیطهای ابری و در بستر شبکه هستند، بسیار مؤثر است و فرآیندهای تحلیل دادههای بزرگ جغرافیایی را سرعت میبخشد.
همچنین، JupyterGIS 0.16 از پشتیبانی بومی از استانداردهای GeoZarr و GeoPackage بهرهمند شده است. این امکانات به محققان و توسعهدهندگان اجازه میدهد تا دادههای جغرافیایی را به صورت مؤثر و بدون نیاز به تبدیلهای پیچیده مدیریت و ذخیره کنند. در کنار این، استفاده از سمبولسازیهای اعلامگرایانه و تقسیمبندی دادهها به بلوکهای Xarray، فرایند ایجاد و تکرار امور بصری را آسانتر کرده است؛ به گونهای که تصاویر و نمودارهای تولید شده قابلیت بازتولیدپذیری و همگامسازی سادهتر را دارند، در حالی که دادههای بزرگ در فضای ابری باقی میمانند و نیاز به انتقال یا ذخیرهسازی محلی ندارند.
در کل، نسخه جدید JupyterGIS ترکیبی از همکاری همزمان، عملکرد بهینه در بستر اینترنت، امکانات پیشرفته مدیریت دادههای جغرافیایی و ابزارهای نوآورانه برای تحلیلهای پیچیده ارائه میدهد که آن را به ابزار ایدهآلی برای متخصصان GIS و تیمهای تحقیقاتی تبدیل کرده است.
#اطلاعات_جغرافیایی #نقشه_درمانی #تحلیل_جغرافیایی #JupyterGIS
🟣لینک مقاله:
https://blog.jupyter.org/jupytergis-0-16-new-visualization-capabilities-collaborative-story-maps-and-more-03e6b78bacc0?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more
Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement
🔵 عنوان مقاله
Kafgres: A Kafka-Compatible Broker Embedded Inside Postgres
🟢 خلاصه مقاله:
در دنیای امروز، یکپارچهسازی سیستمهای مختلف نقش کلیدی در بهبود کارایی و سادگی مدیریت دادهها ایفا میکند. یکی از چالشهای رایج در این حوزه، اتصال سیستمهای پیامرسان مانند Kafka به پایگاههای داده است تا بتوان دادهها را به شکل مؤثر و بدون پیچیدگیهای اضافی هدایت و تحلیل کرد. در این میان، پروژه جدیدی به نام "کافرگرس" توسعه یافته است که این نیاز را به شیوهای نوآورانه برطرف میکند.
کافرگرس یک بروکر سازگار با پروتکل Kafka است که به طور کامل درون پایگاه داده پستگرس (Postgres) قرار گرفته و به وسیلهی افزونهای مبتنی بر پشتیبانی از پراجکتهای قدرتمند مانند پگاکس (pgrx) توسعه یافته است. این افزونه، پروتکل بروکر Kafka را از طریق یک کارگر پسزمینه در داخل پستگرس ارائه میدهد. به این ترتیب، سرویسهای کلاینتهای Kafka میتوانند بدون نیاز به سرور مستقل، به راحتی به این بروکر متصل شوند و عملیاتهایی مانند تولید و مصرف پیام، و همچنین تنظیم مجدد گروههای مصرفکننده بر روی موضوعاتی که در پایگاه داده ذخیره شدهاند، انجام دهند. این رویکرد نه تنها سادهسازی فرآیند یکپارچهسازی را ممکن میسازد بلکه کارایی و انعطافپذیری سیستمهای مدیریت دادهها را افزایش میدهد.
در نتیجه، "کافرگرس" به مدیران و توسعهدهندگان این امکان را میدهد که ساختارهای دادهای پیچیده را در پایگاه دادههای موجود خود حفظ کرده و در کنار آن از مزایای Kafka برای انتقال و مدیریت پیام بهرهمند شوند. این راهحل نوآورانه، مجموعه ابزارهای موثری برای بهبود فرآیندهای جریان داده و توسعه سیستمهای مقیاسپذیر ارائه میدهد که میتواند در پروژههای مختلف، از پایگاههای دادههای کوچک تا سامانههای بزرگ داده، نقش حیاتی ایفا کند.
#پایگاه_داده #Kafka #یکپارچه_سازی داده #مدیریت_پیام
🟣لینک مقاله:
https://rynr.dev/blog/kafgres/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Kafgres: A Kafka-Compatible Broker Embedded Inside Postgres
🟢 خلاصه مقاله:
در دنیای امروز، یکپارچهسازی سیستمهای مختلف نقش کلیدی در بهبود کارایی و سادگی مدیریت دادهها ایفا میکند. یکی از چالشهای رایج در این حوزه، اتصال سیستمهای پیامرسان مانند Kafka به پایگاههای داده است تا بتوان دادهها را به شکل مؤثر و بدون پیچیدگیهای اضافی هدایت و تحلیل کرد. در این میان، پروژه جدیدی به نام "کافرگرس" توسعه یافته است که این نیاز را به شیوهای نوآورانه برطرف میکند.
کافرگرس یک بروکر سازگار با پروتکل Kafka است که به طور کامل درون پایگاه داده پستگرس (Postgres) قرار گرفته و به وسیلهی افزونهای مبتنی بر پشتیبانی از پراجکتهای قدرتمند مانند پگاکس (pgrx) توسعه یافته است. این افزونه، پروتکل بروکر Kafka را از طریق یک کارگر پسزمینه در داخل پستگرس ارائه میدهد. به این ترتیب، سرویسهای کلاینتهای Kafka میتوانند بدون نیاز به سرور مستقل، به راحتی به این بروکر متصل شوند و عملیاتهایی مانند تولید و مصرف پیام، و همچنین تنظیم مجدد گروههای مصرفکننده بر روی موضوعاتی که در پایگاه داده ذخیره شدهاند، انجام دهند. این رویکرد نه تنها سادهسازی فرآیند یکپارچهسازی را ممکن میسازد بلکه کارایی و انعطافپذیری سیستمهای مدیریت دادهها را افزایش میدهد.
در نتیجه، "کافرگرس" به مدیران و توسعهدهندگان این امکان را میدهد که ساختارهای دادهای پیچیده را در پایگاه دادههای موجود خود حفظ کرده و در کنار آن از مزایای Kafka برای انتقال و مدیریت پیام بهرهمند شوند. این راهحل نوآورانه، مجموعه ابزارهای موثری برای بهبود فرآیندهای جریان داده و توسعه سیستمهای مقیاسپذیر ارائه میدهد که میتواند در پروژههای مختلف، از پایگاههای دادههای کوچک تا سامانههای بزرگ داده، نقش حیاتی ایفا کند.
#پایگاه_داده #Kafka #یکپارچه_سازی داده #مدیریت_پیام
🟣لینک مقاله:
https://rynr.dev/blog/kafgres/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
rynr.dev
Kafgres: Embedding a Kafka Broker into Postgres — rynr.dev blog
Embedding a performant singleton Kafka broker into Postgres.
🔵 عنوان مقاله
Filament (GitHub Repo)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، انتقال و همگامسازی اطلاعات بین منابع و مقصدها اهمیت بالایی دارد. پروژه Filament در این حوزه، راهحلی قدرتمند و قابل انعطاف ارائه میدهد که قادر است دادهها را با روشهای مختلفی مانند حالت کامل، افزایشی یا CDC (تغییر داده ها در زمان واقعی) از منبع به مقصد منتقل کند. این سیستم تضمین میکند که هر مجموعه دادهای که انتقال مییابد، تحت کنترل است و هر مرحله با دقت و پس از اطمینان کامل تایید میشود، بهگونهای که عملیات انتقال تنها پس از موفقیت هر بخش، پیش روی میکند. علاوه بر این، در Filament، قسمتهای مختلف مانند منابع، مقصدها، حافظهگذاریهای حالت و سیستم حملونقل رویدادها کاملاً قابل جاسازی و تعویض هستند، که این امکان انعطاف و تطابق با نیازهای متفاوت را فراهم میآورد.
در نتیجه، این ساختار قدرتمند و قابل تنظیم، کمک میکند تا فرآیندهای انتقال دادهها با کارایی بالا و بدون خطا انجام شوند و کاربران میتوانند به راحتی سیستم خود را بر اساس نیازهای خاصشان پیکربندی و بهروزرسانی کنند. این ویژگیها، Filament را به گزینهای بسیار مناسب برای پروژههای دادهمحور و نیازمند همگامسازی سریع و مطمئن بدل میکند.
#مدیریت_داده #همگامسازی #انتقال_داده #فیلمنت
🟣لینک مقاله:
https://github.com/galaxy-io/filament?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Filament (GitHub Repo)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، انتقال و همگامسازی اطلاعات بین منابع و مقصدها اهمیت بالایی دارد. پروژه Filament در این حوزه، راهحلی قدرتمند و قابل انعطاف ارائه میدهد که قادر است دادهها را با روشهای مختلفی مانند حالت کامل، افزایشی یا CDC (تغییر داده ها در زمان واقعی) از منبع به مقصد منتقل کند. این سیستم تضمین میکند که هر مجموعه دادهای که انتقال مییابد، تحت کنترل است و هر مرحله با دقت و پس از اطمینان کامل تایید میشود، بهگونهای که عملیات انتقال تنها پس از موفقیت هر بخش، پیش روی میکند. علاوه بر این، در Filament، قسمتهای مختلف مانند منابع، مقصدها، حافظهگذاریهای حالت و سیستم حملونقل رویدادها کاملاً قابل جاسازی و تعویض هستند، که این امکان انعطاف و تطابق با نیازهای متفاوت را فراهم میآورد.
در نتیجه، این ساختار قدرتمند و قابل تنظیم، کمک میکند تا فرآیندهای انتقال دادهها با کارایی بالا و بدون خطا انجام شوند و کاربران میتوانند به راحتی سیستم خود را بر اساس نیازهای خاصشان پیکربندی و بهروزرسانی کنند. این ویژگیها، Filament را به گزینهای بسیار مناسب برای پروژههای دادهمحور و نیازمند همگامسازی سریع و مطمئن بدل میکند.
#مدیریت_داده #همگامسازی #انتقال_داده #فیلمنت
🟣لینک مقاله:
https://github.com/galaxy-io/filament?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - galaxy-io/filament: Pluggable data replication with checkpointing, batching, and integrity events
Pluggable data replication with checkpointing, batching, and integrity events - galaxy-io/filament
🔵 عنوان مقاله
chdb: An Extension for Fast Imports from S3, GCS and Azure
🟢 خلاصه مقاله:
موتور چدبی (chDB) در واقع یک افزونه برای سیستم کلیکهاوس است که فرآیند واردات و صادرات حجم زیادی از دادهها را با سرعت بالا تسهیل میکند. این افزونه، باعث میشود که عملیاتهایی مانند COPY یا ایجاد جدولهای جدید به راحتی و به سرعت انجام شوند و بتوان دادهها را مستقیم از سرویسهای ابری معروف مثل S3، GCS، Azure و یا از طریق پروتکل HTTP دریافت کرد.
افزونه چدبی به صورت یک بستر قدرتمند، امکاناتی را فراهم میکند تا دادههای ساختاریافته مانند فایلهای Parquet، Avro، ORC، Arrow و سایر قالبهای محبوب، بدون نیاز به فایلهای محلی، مستقیماً از سرویسهای ابری بارگذاری شوند. این کار نه تنها فرآیند واردات را ساده میکند، بلکه سرعت اجرای عملیات را نیز چندین برابر میسازد، و در نتیجه به teams و مراکز داده این امکان را میدهد که به شکل بهینهتری دادههای بزرگ و پیچیده را مدیریت کنند.
با استفاده از این افزونه، امکان اجرای عملیاتهای دادهای سریع و موثر در محیطهای ابری فراهم میشود، که این امر به ویژه در پروژههای نیازمند پردازش سریع دادههای عظیم اهمیت فراوانی دارد.
#ابرناشی #توسعه_داده #کلیکهاوس #واردات_مبتنی_بر_ابری
🟣لینک مقاله:
https://clickhouse.com/blog/introducing-chdb-postgres
➖➖➖➖➖➖➖➖
👑 @Database_Academy
chdb: An Extension for Fast Imports from S3, GCS and Azure
🟢 خلاصه مقاله:
موتور چدبی (chDB) در واقع یک افزونه برای سیستم کلیکهاوس است که فرآیند واردات و صادرات حجم زیادی از دادهها را با سرعت بالا تسهیل میکند. این افزونه، باعث میشود که عملیاتهایی مانند COPY یا ایجاد جدولهای جدید به راحتی و به سرعت انجام شوند و بتوان دادهها را مستقیم از سرویسهای ابری معروف مثل S3، GCS، Azure و یا از طریق پروتکل HTTP دریافت کرد.
افزونه چدبی به صورت یک بستر قدرتمند، امکاناتی را فراهم میکند تا دادههای ساختاریافته مانند فایلهای Parquet، Avro، ORC، Arrow و سایر قالبهای محبوب، بدون نیاز به فایلهای محلی، مستقیماً از سرویسهای ابری بارگذاری شوند. این کار نه تنها فرآیند واردات را ساده میکند، بلکه سرعت اجرای عملیات را نیز چندین برابر میسازد، و در نتیجه به teams و مراکز داده این امکان را میدهد که به شکل بهینهتری دادههای بزرگ و پیچیده را مدیریت کنند.
با استفاده از این افزونه، امکان اجرای عملیاتهای دادهای سریع و موثر در محیطهای ابری فراهم میشود، که این امر به ویژه در پروژههای نیازمند پردازش سریع دادههای عظیم اهمیت فراوانی دارد.
#ابرناشی #توسعه_داده #کلیکهاوس #واردات_مبتنی_بر_ابری
🟣لینک مقاله:
https://clickhouse.com/blog/introducing-chdb-postgres
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickHouse
Introducing chdb Postgres extension: High-performance imports from cloud storage | ClickHouse
The chdb Postgres extension brings fast imports and exports across cloud storage platforms and data formats, powered by the embedded ClickHouse engine.
🔵 عنوان مقاله
Pretraining progress is mostly coming from data (11 minute read)
🟢 خلاصه مقاله:
در حال حاضر، پیشرفت در مرحله پیشآموزش عمدتاً ناشی از بهبودهای دادهای است. در یک مطالعه مقایسهای کنترلشده، مجموعههای داده و الگوریتمهای مدلهای آزاد (Open-Model) بین سالهای ۲۰۱۹ تا ۲۰۲۵ مورد بررسی قرار گرفتند. نتایج نشان داد که بهبودهای دادهای باعث افزایش بهرهوری محاسباتی تا ۱۲ برابر شده است، در حالی که بهبودهای مربوط به طراحی مدلها تنها حدود ۳.۷ برابر اثر داشتند، و این با بودجهای معادل یک اگزافلوب (۱۰^19 FLOP) صورت گرفته است.
این یافته اهمیت فرآیندهای استخراج، غربالگری و فراهمآوری دادهها را به عنوان یک عامل عمده در سیستمهای یادگیری ماشینی نشان میدهد. با این حال، باید توجه داشت که تأثیرات دادههای بزرگتر و تولید دادههای مصنوعی هنوز به اندازه کافی آزمایش نشدهاند و نیاز به بررسیهای بیشتر دارند. در مجموع، این بررسی نشان میدهد که تمرکز بر بهبود کیفیت و تنوع دادهها میتواند نقش کلیدی در تسریع پیشرفتهای فناوری هوش مصنوعی ایفا کند و آینده توسعه را بیشتر از تغییرات در ساختار مدلها شکل دهد.
#هوش_مصنوعی #پیشرفت_در_دادهها #یادگیری_ماشینی #مطالعات_علمی
🟣لینک مقاله:
https://www.dwarkesh.com/p/pretraining-progress-is-mostly-data?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Pretraining progress is mostly coming from data (11 minute read)
🟢 خلاصه مقاله:
در حال حاضر، پیشرفت در مرحله پیشآموزش عمدتاً ناشی از بهبودهای دادهای است. در یک مطالعه مقایسهای کنترلشده، مجموعههای داده و الگوریتمهای مدلهای آزاد (Open-Model) بین سالهای ۲۰۱۹ تا ۲۰۲۵ مورد بررسی قرار گرفتند. نتایج نشان داد که بهبودهای دادهای باعث افزایش بهرهوری محاسباتی تا ۱۲ برابر شده است، در حالی که بهبودهای مربوط به طراحی مدلها تنها حدود ۳.۷ برابر اثر داشتند، و این با بودجهای معادل یک اگزافلوب (۱۰^19 FLOP) صورت گرفته است.
این یافته اهمیت فرآیندهای استخراج، غربالگری و فراهمآوری دادهها را به عنوان یک عامل عمده در سیستمهای یادگیری ماشینی نشان میدهد. با این حال، باید توجه داشت که تأثیرات دادههای بزرگتر و تولید دادههای مصنوعی هنوز به اندازه کافی آزمایش نشدهاند و نیاز به بررسیهای بیشتر دارند. در مجموع، این بررسی نشان میدهد که تمرکز بر بهبود کیفیت و تنوع دادهها میتواند نقش کلیدی در تسریع پیشرفتهای فناوری هوش مصنوعی ایفا کند و آینده توسعه را بیشتر از تغییرات در ساختار مدلها شکل دهد.
#هوش_مصنوعی #پیشرفت_در_دادهها #یادگیری_ماشینی #مطالعات_علمی
🟣لینک مقاله:
https://www.dwarkesh.com/p/pretraining-progress-is-mostly-data?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dwarkesh
Pretraining progress is mostly coming from data
Breaking down 6 years of pretraining progress into data vs model improvements
Forwarded from VIP
🚀 رونمایی از DevSponsors | هاب اسپانسرشیپ و رتبهبندی توسعهدهندگان متنباز ایران
پلتفرم DevSponsors با هدف ایجاد کانال ارتباطی مستقیم و جذب حامیان مالی و زیرساختی از شرکتهای هاستینگ، ابری و هوش مصنوعی برای پروژههای فعال متنباز راهاندازی شد.
🔹 رتبهبندی زنده توسعهدهندگان گیتهاب
🔹 بانک پروژههای کاربردی و پرمخاطب
🔹 برنامه اعطای گرنت سرور و زیرساخت ابری
🌐 مشاهده پروژهها و رتبهبندی:
https://devsponsors.github.io/
پلتفرم DevSponsors با هدف ایجاد کانال ارتباطی مستقیم و جذب حامیان مالی و زیرساختی از شرکتهای هاستینگ، ابری و هوش مصنوعی برای پروژههای فعال متنباز راهاندازی شد.
🔹 رتبهبندی زنده توسعهدهندگان گیتهاب
🔹 بانک پروژههای کاربردی و پرمخاطب
🔹 برنامه اعطای گرنت سرور و زیرساخت ابری
🌐 مشاهده پروژهها و رتبهبندی:
https://devsponsors.github.io/
🔵 عنوان مقاله
Sixteen Locks Ought to Be Enough for Anybody
🟢 خلاصه مقاله:
در هنگام برنامهریزی یک پرسوجو در پایگاه داده پستگرس، نکتهای جالب وجود دارد که شاید خیلی از کاربران ندانند. این سیستم به طور خودکار و به صورت ظریف، روی هر ایندکسی که جدول مورد نظر دارد، قفلی (لاک)ضعیف میگیرد؛ حتی اگر در آن لحظه از آن ایندکسها استفاده نکند. این فرآیند معمولاً مشکلی ایجاد نمیکند و عملکرد سیستم را مختل نمیسازد، اما یک نکته مهم در نسخههای قدیمیتر پستگرس وجود داشت. پیش از نسخه ۱۸، اگر یک پرسوجو بیش از ۱۶ جدول و ایندکس مختلف را درگیر میکرد، این موضوع میتوانست مشکلساز باشد و کارایی سیستم را کاهش دهد. در آن زمان، محدودیت تعداد لاکهایی که سیستم به طور همزمان میگیرد، میتوانست باعث شود که پرسوجوهای پیچیدهتر با محدودیت مواجه شوند و کاربر مجبور باشد در طراحی و ساخت پرسوجوهای خود تجدیدنظر کند تا از این محدودیت عبور کند. خوشبختانه، در نسخههای جدیدتر این محدودیت برطرف شده و اکنون پستگرس این موضوع را بدون مشکل مدیریت میکند، اما دانستن این نکته برای توسعهدهندگان و مدیران پایگاه داده اهمیت دارد.
#پایگاه_داده #پستگرس #مدیریت_لاک #پرسوجو
🟣لینک مقاله:
https://thebuild.com/blog/sixteen-locks-ought-to-be-enough-for-anybody/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Sixteen Locks Ought to Be Enough for Anybody
🟢 خلاصه مقاله:
در هنگام برنامهریزی یک پرسوجو در پایگاه داده پستگرس، نکتهای جالب وجود دارد که شاید خیلی از کاربران ندانند. این سیستم به طور خودکار و به صورت ظریف، روی هر ایندکسی که جدول مورد نظر دارد، قفلی (لاک)ضعیف میگیرد؛ حتی اگر در آن لحظه از آن ایندکسها استفاده نکند. این فرآیند معمولاً مشکلی ایجاد نمیکند و عملکرد سیستم را مختل نمیسازد، اما یک نکته مهم در نسخههای قدیمیتر پستگرس وجود داشت. پیش از نسخه ۱۸، اگر یک پرسوجو بیش از ۱۶ جدول و ایندکس مختلف را درگیر میکرد، این موضوع میتوانست مشکلساز باشد و کارایی سیستم را کاهش دهد. در آن زمان، محدودیت تعداد لاکهایی که سیستم به طور همزمان میگیرد، میتوانست باعث شود که پرسوجوهای پیچیدهتر با محدودیت مواجه شوند و کاربر مجبور باشد در طراحی و ساخت پرسوجوهای خود تجدیدنظر کند تا از این محدودیت عبور کند. خوشبختانه، در نسخههای جدیدتر این محدودیت برطرف شده و اکنون پستگرس این موضوع را بدون مشکل مدیریت میکند، اما دانستن این نکته برای توسعهدهندگان و مدیران پایگاه داده اهمیت دارد.
#پایگاه_داده #پستگرس #مدیریت_لاک #پرسوجو
🟣لینک مقاله:
https://thebuild.com/blog/sixteen-locks-ought-to-be-enough-for-anybody/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Thebuild
Sixteen Locks Ought to Be Enough for Anybody
Every query locks every index on a table, even ones it doesn't use.
🔵 عنوان مقاله
How to Optimize When You Can’t Do Anything
🟢 خلاصه مقاله:
وقتی نمیتوانید کاری انجام دهید، بهترین استراتژی چیست؟ روزی هتی با مشکلی در یکی از جداول بزرگ پایگاه دادهاش مواجه شد. این جدول حدود ۷۵۰ گیگابایت حجم داشت و شامل ۱۶ میلیارد ردیف بود، و ناگهان سرعت اجرای عملیاتهای آن کاهش یافته بود. در چنین شرایطی، معمولاً ایجاد اندیکس جدید، یک راهحل سریع نبود چون زمان لازم برای ساخت آن بیش از یک روز میکشید و احتمالا نتیجه مطلوب نخواهد بود. در عوض، هتی با نگاهی دقیق به دادههای زیرین، موفق شد یک راهحل ابتکاری و کارآمد بیابد که مشکلها را برطرف کند.
در مواقعی که امکان تغییر مستقیم در ساختار دادهها یا انجام اقدامات بزرگ و زمانبر نیست، بررسی دقیق و دقیقنگرانه دادهها و روندهای داخلی بسیار اهمیت دارد. هتی با تحلیل عمیق دادهها و شناخت دقیق از نحوه ذخیره و بازیابی آنها، توانست راهحلی خلاقانه و مؤثر پیدا کند، بدون اینکه نیاز باشد زمان زیادی صرف اصلاحات ساختاری کند. این نمونه نشان میدهد که حتی در شرایطی که محدودیتهای زیادی داریم، با رویکردهای هوشمندانه و نگاهی متفاوت، میتوان از پس مشکلات پیچیده برآمد و عملکرد سیستمها را بهبود داد.
در نتیجه، مهم است که در مواجهه با مشکلات غیرمنتظره، اولویت را به تحلیل دقیق و روشهای هوشمندانه بدهیم؛ چرا که همین توجههای جزیی و خلاقانه، ممکن است کلید حل مشکلات بزرگ باشند. این رویکرد نشان میدهد که گاهی راهحلهای نوآورانه و مبتنی بر بررسی عمیق دادهها، راحتترین راه حل در مقابل محدودیتهای زمانی و فنی هستند.
#بهبود_پایگاه_داده #تکنیکهای_خلاقانه #مدیریت_مشکلات #راهکارهای_هوشمند
🟣لینک مقاله:
https://hdombrovskaya.wordpress.com/2026/08/25/how-to-optimize-when-you-cant-do-anything/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Optimize When You Can’t Do Anything
🟢 خلاصه مقاله:
وقتی نمیتوانید کاری انجام دهید، بهترین استراتژی چیست؟ روزی هتی با مشکلی در یکی از جداول بزرگ پایگاه دادهاش مواجه شد. این جدول حدود ۷۵۰ گیگابایت حجم داشت و شامل ۱۶ میلیارد ردیف بود، و ناگهان سرعت اجرای عملیاتهای آن کاهش یافته بود. در چنین شرایطی، معمولاً ایجاد اندیکس جدید، یک راهحل سریع نبود چون زمان لازم برای ساخت آن بیش از یک روز میکشید و احتمالا نتیجه مطلوب نخواهد بود. در عوض، هتی با نگاهی دقیق به دادههای زیرین، موفق شد یک راهحل ابتکاری و کارآمد بیابد که مشکلها را برطرف کند.
در مواقعی که امکان تغییر مستقیم در ساختار دادهها یا انجام اقدامات بزرگ و زمانبر نیست، بررسی دقیق و دقیقنگرانه دادهها و روندهای داخلی بسیار اهمیت دارد. هتی با تحلیل عمیق دادهها و شناخت دقیق از نحوه ذخیره و بازیابی آنها، توانست راهحلی خلاقانه و مؤثر پیدا کند، بدون اینکه نیاز باشد زمان زیادی صرف اصلاحات ساختاری کند. این نمونه نشان میدهد که حتی در شرایطی که محدودیتهای زیادی داریم، با رویکردهای هوشمندانه و نگاهی متفاوت، میتوان از پس مشکلات پیچیده برآمد و عملکرد سیستمها را بهبود داد.
در نتیجه، مهم است که در مواجهه با مشکلات غیرمنتظره، اولویت را به تحلیل دقیق و روشهای هوشمندانه بدهیم؛ چرا که همین توجههای جزیی و خلاقانه، ممکن است کلید حل مشکلات بزرگ باشند. این رویکرد نشان میدهد که گاهی راهحلهای نوآورانه و مبتنی بر بررسی عمیق دادهها، راحتترین راه حل در مقابل محدودیتهای زمانی و فنی هستند.
#بهبود_پایگاه_داده #تکنیکهای_خلاقانه #مدیریت_مشکلات #راهکارهای_هوشمند
🟣لینک مقاله:
https://hdombrovskaya.wordpress.com/2026/08/25/how-to-optimize-when-you-cant-do-anything/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The World of Data
How to optimize when you can’t do anything!
It’s hard to say anything new about query optimization. On the one hand, each new Postgres release includes multiple query planner improvements, and it feels like there is something for any p…
پروژه Datayar مشکل پراکندگی جستوجوی دیتاست و ریپازیتوری بین چند منبع مختلف رو کمتر کنه.
امکانات اصلی:
جستوجوی همزمان در Hugging Face، GitHub، Kaggle و OpenML
مقایسه نتایج از چند منبع
امکان سؤال پرسیدن درباره هر Dataset یا Repository به صورت اختصاصی
استخراج و ساختاردهی اطلاعات مهم قبل از ارسال به مدل
یکپارچهسازی مسیر جستوجو، بررسی و انتخاب منابع
کاهش توکن سوزی ایجنت ها برای مراحل ریسرچ پروژه ها
https://github.com/Elcapunnn/Datayar.git
@ | <MohammadAmin/>
امکانات اصلی:
جستوجوی همزمان در Hugging Face، GitHub، Kaggle و OpenML
مقایسه نتایج از چند منبع
امکان سؤال پرسیدن درباره هر Dataset یا Repository به صورت اختصاصی
استخراج و ساختاردهی اطلاعات مهم قبل از ارسال به مدل
یکپارچهسازی مسیر جستوجو، بررسی و انتخاب منابع
کاهش توکن سوزی ایجنت ها برای مراحل ریسرچ پروژه ها
https://github.com/Elcapunnn/Datayar.git
@ | <MohammadAmin/>
GitHub
GitHub - Elcapunnn/Datayar: AI-powered discovery engine for datasets and code repositories across Hugging Face, GitHub, OpenML…
AI-powered discovery engine for datasets and code repositories across Hugging Face, GitHub, OpenML, and Kaggle. - Elcapunnn/Datayar
🔵 عنوان مقاله
Why Spotify is not using Bayesian A/B testing (12 minute read)
🟢 خلاصه مقاله:
در دنیای آزمایشهای مقایسهای، روشهای متعددی برای ارزیابی تفاوتهای احتمالی در دادهها وجود دارد، اما اسپاتیفای نشان میدهد که استفاده از رویکرد بیزی در آزمایشهای A/B چه تفاوتهایی با سایر روشها دارد. بیزین نمونهگیری، در واقع به مجموعهای از تصمیمات مرتبط با انتخاب فرضیه شروع، روشهای احتمال و قواعد توقف بستگی دارد. این شرکت ثابت کرده است که استفاده از آستانههای احتمالاتی مبتنی بر فرضیههای پایه ثابت و بدون تغییر میتواند همان عملکرد آزمایشهای متداول فرکانسگرایانه در فهم پنهانسازیها یا "peek" کردنهای پایانناپذیر را داشته باشد. اما تفاوت مهم این است که فاکتورهای بیزی میتوانند کنترل خوبی بر روی نتایج نادرست و مثبت کاذب زمانی که آزمایشها به صورت اختیاری متوقف میشوند، ارائه دهند.
برای اجرای موفقیتآمیز آزمایشهای بیزی، باید از ابتدا تصمیم بگیرید که چه تضمینهایی برای صحت و اعتبار برنامه آزمایش در نظر گرفتهاید، و سپس تنظیمات استنباط یا تفسیر دادهها را بر اساس این اولویتها انجام دهید. انتخابهای اولیه در طراحی آزمایش، تاثیر مستقیم بر روی نتایج نهایی و درستی نتیجهگیری دارند؛ بنابراین، تعیین استراتژی و رعایت قواعد آن اهمیت حیاتی دارد.
در نهایت، اسپاتیفای ثابت کرده است که با انتخاب سیاستهای مناسب و تمرکز بر تضمینهای پایه در طراحی آزمایش، میتوان بهرهوری و دقت تجزیه و تحلیل دادهها را در مسیر توسعه و بهبود خدمات تضمین کرد. این رویکرد میتواند راهی موثر برای کنترل خطاهای احتمالی و بهبود تصمیمگیریهای مبتنی بر داده باشد، بدون اینکه نیاز باشد به روشهای سنتی و مرسوم که ممکن است ناپایدار یا نادرست باشند، تکیه کنیم.
#آزمایش_آیبی #تجربه_کاربری #تحلیل_داده #تصمیم_گیری
🟣لینک مقاله:
https://engineering.atspotify.com/2026/9/why-spotify-is-not-using-bayesian-a-b-testing?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why Spotify is not using Bayesian A/B testing (12 minute read)
🟢 خلاصه مقاله:
در دنیای آزمایشهای مقایسهای، روشهای متعددی برای ارزیابی تفاوتهای احتمالی در دادهها وجود دارد، اما اسپاتیفای نشان میدهد که استفاده از رویکرد بیزی در آزمایشهای A/B چه تفاوتهایی با سایر روشها دارد. بیزین نمونهگیری، در واقع به مجموعهای از تصمیمات مرتبط با انتخاب فرضیه شروع، روشهای احتمال و قواعد توقف بستگی دارد. این شرکت ثابت کرده است که استفاده از آستانههای احتمالاتی مبتنی بر فرضیههای پایه ثابت و بدون تغییر میتواند همان عملکرد آزمایشهای متداول فرکانسگرایانه در فهم پنهانسازیها یا "peek" کردنهای پایانناپذیر را داشته باشد. اما تفاوت مهم این است که فاکتورهای بیزی میتوانند کنترل خوبی بر روی نتایج نادرست و مثبت کاذب زمانی که آزمایشها به صورت اختیاری متوقف میشوند، ارائه دهند.
برای اجرای موفقیتآمیز آزمایشهای بیزی، باید از ابتدا تصمیم بگیرید که چه تضمینهایی برای صحت و اعتبار برنامه آزمایش در نظر گرفتهاید، و سپس تنظیمات استنباط یا تفسیر دادهها را بر اساس این اولویتها انجام دهید. انتخابهای اولیه در طراحی آزمایش، تاثیر مستقیم بر روی نتایج نهایی و درستی نتیجهگیری دارند؛ بنابراین، تعیین استراتژی و رعایت قواعد آن اهمیت حیاتی دارد.
در نهایت، اسپاتیفای ثابت کرده است که با انتخاب سیاستهای مناسب و تمرکز بر تضمینهای پایه در طراحی آزمایش، میتوان بهرهوری و دقت تجزیه و تحلیل دادهها را در مسیر توسعه و بهبود خدمات تضمین کرد. این رویکرد میتواند راهی موثر برای کنترل خطاهای احتمالی و بهبود تصمیمگیریهای مبتنی بر داده باشد، بدون اینکه نیاز باشد به روشهای سنتی و مرسوم که ممکن است ناپایدار یا نادرست باشند، تکیه کنیم.
#آزمایش_آیبی #تجربه_کاربری #تحلیل_داده #تصمیم_گیری
🟣لینک مقاله:
https://engineering.atspotify.com/2026/9/why-spotify-is-not-using-bayesian-a-b-testing?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spotify Engineering
Why Spotify Is Not Using Bayesian A/B Testing | Spotify Engineering
Forwarded from VIP
💼 به دنبال استخدام برنامهنویس هستید؟ یا به دنبال فرصت شغلی مناسب میگردید؟
🟢 کارفرمایان:
اگر به دنبال جذب برنامهنویس هستید، آگهی استخدام خود را برای ما ارسال کنید تا منتشر شود.
🟢 کارجویان:
اگر به دنبال فرصت شغلی هستید، رزومه خود را برای ما ارسال کنید تا در صورت وجود موقعیت مناسب، به شرکتها و کارفرمایان معرفی شوید. 🚀
👤 ادمین:
@mrbardia72
📄 لطفاً موارد زیر را به همراه فایل PDF رزومه ارسال کنید:
✅ نام و نام خانوادگی (اجباری)
✅ سابقه کار (اجباری)
✅ محل سکونت (اجباری)
✅ امکان نقل مکان برای کار (اجباری)
🔹 لینک LinkedIn (اختیاری)
🔹 لینک GitHub (اختیاری)
👇توی چنل زیر قرار میگیره 👇
https://t.me/job_labdon
🟢 کارفرمایان:
اگر به دنبال جذب برنامهنویس هستید، آگهی استخدام خود را برای ما ارسال کنید تا منتشر شود.
🟢 کارجویان:
اگر به دنبال فرصت شغلی هستید، رزومه خود را برای ما ارسال کنید تا در صورت وجود موقعیت مناسب، به شرکتها و کارفرمایان معرفی شوید. 🚀
👤 ادمین:
@mrbardia72
📄 لطفاً موارد زیر را به همراه فایل PDF رزومه ارسال کنید:
✅ نام و نام خانوادگی (اجباری)
✅ سابقه کار (اجباری)
✅ محل سکونت (اجباری)
✅ امکان نقل مکان برای کار (اجباری)
🔹 لینک LinkedIn (اختیاری)
🔹 لینک GitHub (اختیاری)
👇توی چنل زیر قرار میگیره 👇
https://t.me/job_labdon
🔵 عنوان مقاله
Cloudfloe's query engine in a celld cell (9 minute read)
🟢 خلاصه مقاله:
در این مقاله، به بررسی عملکرد موتور جستوجوی Cloudfloe در یک سلول واحد (Cell) پرداخته شده است. Cloudfloe یک رابط کاربری وب است که امکان استعلام دادههای Iceberg را روی سرویس S3 با بهرهگیری از DuckDB فراهم میکند. آزمایشهایی که انجام شده نشان میدهد که این سیستم چگونه میتواند جایگزین کانتینرهای مجزا برای هر درخواست شود که این موضوع اهمیت زیادی دارد، زیرا کاهش نیاز به ایجاد کانتینرهای جدید میتواند سرعت و کارایی سیستم را بهبود بخشد.
در این آزمایش، با استفاده از نسخه وباسمبلی DuckDB، یک جدول Iceberg شامل ۳۷،۵۳۷ رکورد در عرض ۱۴۸ میلیثانیه خوانده شد. اما زمانی که سلولهای سرورلس حالت سرد داشتند یا تازه بیدار شده بودند، زمان پاسخ به بازهای بین ۲۵۰ تا ۳۲۰ میلیثانیه میرسید و اکثر حافظه خود را حفظ کرده بودند. این نشان میدهد که راهاندازی و بیدار کردن مجدد سلولها هزینهبر است و بنابراین، حفظ نگهداری سلولهای فعال، راهکار موثرتری است.
در ادامه، متوجه میشویم که نگهداشتن اتصال دائمی و گرم نگه داشتن سلولها، تکرار درخواستها را به طور قابل توجهی کاهش میدهد؛ در واقع، پاسخها در این حالت تنها حدود ۳ میلیثانیه طول میکشید. این موضوع نشان میدهد که سیاستهای مدیریت چرخه عمر سلولها، کلید اصلی در طراحی سیستم است و نه تنها خاموش یا روشن کردن سریع سلولها؛ بلکه ماندگاری آنها و نگهداری فعال بودنشان، نقش بسیار مهمی در کارایی سامانه دارد.
در جمعبندی، این آزمایش نشان میدهد که ارتقاء و توسعه سیستمهای سرورلس باید تمرکز بر مدیریت وضعیت و ماندگاری سلولها داشته باشد تا پاسخ سریعتر و بهینهتری به کاربران ارائه دهند و هزینههای مربوط به راهاندازی مجدد و خاموش کردن سلولها را کاهش دهند.
#هوش_مرزی #سرورلس #پایگاههای_داده #کلودفلو
🟣لینک مقاله:
https://gordonmurray.ie/data/2026/09/05/cloudfloes-query-engine-in-a-celld-cell.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Cloudfloe's query engine in a celld cell (9 minute read)
🟢 خلاصه مقاله:
در این مقاله، به بررسی عملکرد موتور جستوجوی Cloudfloe در یک سلول واحد (Cell) پرداخته شده است. Cloudfloe یک رابط کاربری وب است که امکان استعلام دادههای Iceberg را روی سرویس S3 با بهرهگیری از DuckDB فراهم میکند. آزمایشهایی که انجام شده نشان میدهد که این سیستم چگونه میتواند جایگزین کانتینرهای مجزا برای هر درخواست شود که این موضوع اهمیت زیادی دارد، زیرا کاهش نیاز به ایجاد کانتینرهای جدید میتواند سرعت و کارایی سیستم را بهبود بخشد.
در این آزمایش، با استفاده از نسخه وباسمبلی DuckDB، یک جدول Iceberg شامل ۳۷،۵۳۷ رکورد در عرض ۱۴۸ میلیثانیه خوانده شد. اما زمانی که سلولهای سرورلس حالت سرد داشتند یا تازه بیدار شده بودند، زمان پاسخ به بازهای بین ۲۵۰ تا ۳۲۰ میلیثانیه میرسید و اکثر حافظه خود را حفظ کرده بودند. این نشان میدهد که راهاندازی و بیدار کردن مجدد سلولها هزینهبر است و بنابراین، حفظ نگهداری سلولهای فعال، راهکار موثرتری است.
در ادامه، متوجه میشویم که نگهداشتن اتصال دائمی و گرم نگه داشتن سلولها، تکرار درخواستها را به طور قابل توجهی کاهش میدهد؛ در واقع، پاسخها در این حالت تنها حدود ۳ میلیثانیه طول میکشید. این موضوع نشان میدهد که سیاستهای مدیریت چرخه عمر سلولها، کلید اصلی در طراحی سیستم است و نه تنها خاموش یا روشن کردن سریع سلولها؛ بلکه ماندگاری آنها و نگهداری فعال بودنشان، نقش بسیار مهمی در کارایی سامانه دارد.
در جمعبندی، این آزمایش نشان میدهد که ارتقاء و توسعه سیستمهای سرورلس باید تمرکز بر مدیریت وضعیت و ماندگاری سلولها داشته باشد تا پاسخ سریعتر و بهینهتری به کاربران ارائه دهند و هزینههای مربوط به راهاندازی مجدد و خاموش کردن سلولها را کاهش دهند.
#هوش_مرزی #سرورلس #پایگاههای_داده #کلودفلو
🟣لینک مقاله:
https://gordonmurray.ie/data/2026/09/05/cloudfloes-query-engine-in-a-celld-cell.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
gordonmurray.ie
Cloudfloe's query engine in a celld cell | Gordon Murray
Cloudfloe is a web interface I made a while back for querying Apache Iceberg data on S3 with DuckDB. A user saves a connection, writes SQL, runs it, and can ...
🔵 عنوان مقاله
The Scary Postgres 19 Patch Contest
🟢 خلاصه مقاله:
در حالی که هنوز هالووین فرا نرسیده است، اما در یک گفتوگو جذاب در لیست پستی pgsql-hackers، رابرت هاس و کلود به بررسی و ارزیابی مخزنهای نسخه ۱۹ پستگرس پرداختند و تصمیم گرفتند مشخص کنند کدام یک از این آپدیتها ترسناکترین هستند. یکی از این اصلاحات، مربوط به ویژگی گرافهای اموال SQL/PGQ بود که پس از مدتی از نسخه ۱۹ حذف شد؛ اما هنوز پنج مورد دیگر باقی ماندهاند و همچنان موضوع بحث و بررسی هستند. این مسابقه جذاب نشان میدهد که توسعه دهندگان پستگرس چگونه با چالشهای فنی و تصمیمات دشوار روبرو میشوند، هرکدام با ویژگیها و تغییراتی که ممکن است در نگاه اول معمولی به نظر برسند، اما در واقع تأثیرات قابلتوجهی روی کارایی، امنيت و قابلیتهای این سیستم قدرتمند دارند. رقابت بر سر این که کدام تغییرات بیشترین ترس و دغدغه را در دل جامعه توسعه دهندگان ایجاد میکنند، نشاندهنده دغدغههای فنی و نیازهای رو به رشد این پایگاه داده محبوب است.
#پستگرس #نسخه۱۹ #توسعه_پایگاه_داده #گرافهای_SQL
🟣لینک مقاله:
https://www.postgresql.org/message-id/CA%2BTgmob9NY6m0YNFTQ4nFH2d0iC9SQRruDYxfndGKKzh8OC80w%40mail.gmail.com
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Scary Postgres 19 Patch Contest
🟢 خلاصه مقاله:
در حالی که هنوز هالووین فرا نرسیده است، اما در یک گفتوگو جذاب در لیست پستی pgsql-hackers، رابرت هاس و کلود به بررسی و ارزیابی مخزنهای نسخه ۱۹ پستگرس پرداختند و تصمیم گرفتند مشخص کنند کدام یک از این آپدیتها ترسناکترین هستند. یکی از این اصلاحات، مربوط به ویژگی گرافهای اموال SQL/PGQ بود که پس از مدتی از نسخه ۱۹ حذف شد؛ اما هنوز پنج مورد دیگر باقی ماندهاند و همچنان موضوع بحث و بررسی هستند. این مسابقه جذاب نشان میدهد که توسعه دهندگان پستگرس چگونه با چالشهای فنی و تصمیمات دشوار روبرو میشوند، هرکدام با ویژگیها و تغییراتی که ممکن است در نگاه اول معمولی به نظر برسند، اما در واقع تأثیرات قابلتوجهی روی کارایی، امنيت و قابلیتهای این سیستم قدرتمند دارند. رقابت بر سر این که کدام تغییرات بیشترین ترس و دغدغه را در دل جامعه توسعه دهندگان ایجاد میکنند، نشاندهنده دغدغههای فنی و نیازهای رو به رشد این پایگاه داده محبوب است.
#پستگرس #نسخه۱۹ #توسعه_پایگاه_داده #گرافهای_SQL
🟣لینک مقاله:
https://www.postgresql.org/message-id/CA%2BTgmob9NY6m0YNFTQ4nFH2d0iC9SQRruDYxfndGKKzh8OC80w%40mail.gmail.com
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL Mailing List Archives
scary patch contest
I asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed …
🔵 عنوان مقاله
Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability Signals (12 minute read)
🟢 خلاصه مقاله:
در دنیای حملونقل مدرن، داشتن دادههای دقیق و بهروز درباره زمان سفر در محلهها اهمیت بسیاری دارد. شرکت Lyft با بازآفرینی و بروزرسانی مجموعه دادههای قدیمی خود درمورد زمان سفرهای محلی، تلاش کرده است تا اطلاعات بهتر و معتبرتری ارائه دهد. این بهروزرسانی شامل تخمینهای زمان سفر با دقت بیشتری است، حوزههای پشتیبانی گستردهتری دارد و فیلترهای مربوط به مکانهای قابل حرکت و مسیرهای قابل رانندگی به آن افزوده شده است. بهعلاوه، بخشهای مربوط به سرویسهای خودکار و مدیریت میدان دید در سامانهاش بهبود یافته است، که نتیجه آن بهبود در فرایند قیمتگذاری و تهیه نقشههای حرارتی رانندگان است، چراکه این دادهها به آنها کمک میکند تا بهطور دقیقتری تقاضا و عرضه را در نزدیکی محل کار و زندگی خود ارزیابی کنند.
این بهروزرسانیها قرار است هر شش ماه یکبار انجام شوند تا اطلاعات همواره بهروز باقی بمانند. همچنین، بر اساس برنامهریزیهای جدید، زمانهای سفر تخمینی به نحوی تنظیم خواهند شد که تغییرات ترافیکی در طول هفته را بهتر منعکس کنند، از اینرو رانندگان و کاربران تنها بر اساس نتایج واقعی و قابل اعتماد برنامهریزی خواهند کرد. این استراتژی به Lyft امکان میدهد تا تجربه مشترک و کارآمدتری در سفرهای روزمره ارائه دهد و رضایت کاربران و رانندگان خود را افزایش دهد.
در نتیجه، با این بهروزرسانیها، سیستمهای مسیریابی و قیمتگذاری Lyft بسیار هوشمندتر و انعطافپذیرتر میشوند، و این امر به نفع تمام افرادی است که در شبکه آن فعالیت میکنند، یا در جستوجوی سفرهای مطمئن و سریع هستند.
#هوشمندسازی_سفر #ترافیک_لحظه_ای #تکنولوژی_موبایل #نقشههای_حرارتی
🟣لینک مقاله:
https://eng.lyft.com/refreshing-the-travel-time-map-behind-lyfts-marketplace-rebuilding-neighborhood-reachability-5be3efbc82ea?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Refreshing the Travel-Time Map Behind Lyft's Marketplace: Rebuilding Neighborhood Reachability Signals (12 minute read)
🟢 خلاصه مقاله:
در دنیای حملونقل مدرن، داشتن دادههای دقیق و بهروز درباره زمان سفر در محلهها اهمیت بسیاری دارد. شرکت Lyft با بازآفرینی و بروزرسانی مجموعه دادههای قدیمی خود درمورد زمان سفرهای محلی، تلاش کرده است تا اطلاعات بهتر و معتبرتری ارائه دهد. این بهروزرسانی شامل تخمینهای زمان سفر با دقت بیشتری است، حوزههای پشتیبانی گستردهتری دارد و فیلترهای مربوط به مکانهای قابل حرکت و مسیرهای قابل رانندگی به آن افزوده شده است. بهعلاوه، بخشهای مربوط به سرویسهای خودکار و مدیریت میدان دید در سامانهاش بهبود یافته است، که نتیجه آن بهبود در فرایند قیمتگذاری و تهیه نقشههای حرارتی رانندگان است، چراکه این دادهها به آنها کمک میکند تا بهطور دقیقتری تقاضا و عرضه را در نزدیکی محل کار و زندگی خود ارزیابی کنند.
این بهروزرسانیها قرار است هر شش ماه یکبار انجام شوند تا اطلاعات همواره بهروز باقی بمانند. همچنین، بر اساس برنامهریزیهای جدید، زمانهای سفر تخمینی به نحوی تنظیم خواهند شد که تغییرات ترافیکی در طول هفته را بهتر منعکس کنند، از اینرو رانندگان و کاربران تنها بر اساس نتایج واقعی و قابل اعتماد برنامهریزی خواهند کرد. این استراتژی به Lyft امکان میدهد تا تجربه مشترک و کارآمدتری در سفرهای روزمره ارائه دهد و رضایت کاربران و رانندگان خود را افزایش دهد.
در نتیجه، با این بهروزرسانیها، سیستمهای مسیریابی و قیمتگذاری Lyft بسیار هوشمندتر و انعطافپذیرتر میشوند، و این امر به نفع تمام افرادی است که در شبکه آن فعالیت میکنند، یا در جستوجوی سفرهای مطمئن و سریع هستند.
#هوشمندسازی_سفر #ترافیک_لحظه_ای #تکنولوژی_موبایل #نقشههای_حرارتی
🟣لینک مقاله:
https://eng.lyft.com/refreshing-the-travel-time-map-behind-lyfts-marketplace-rebuilding-neighborhood-reachability-5be3efbc82ea?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Refreshing the Travel-Time Map Behind Lyft’s Marketplace: Rebuilding Neighborhood Reachability Signals
Every time Lyft calculates pricing to balance a market, nudges a driver toward an under-served pocket of a city, or paints a heatmap of…
🔵 عنوان مقاله
118 million queries per second on Neki (9 minute read)
🟢 خلاصه مقاله:
پلانیتاسکیل تصمیم گرفت در آزمایشی بینظیر، یک میلیون درخواست در ثانیه بر روی سیستم جدید و شارد شدهی خودش به نام نکی، اجرا کند. این آزمایش در همان ابتدا، به سرعت و تقریباً بلافاصله با استفاده از ۵ شارد، به این هدف رسید. سپس با ادامه آزمایش و افزودن شاردهای بیشتر، تعداد شاردها تا ۵۱۲ افزایش پیدا کرد و در نتیجه، توانست در مجموع به ۱۱۸ میلیون درخواست در ثانیه دست یابد. این حجم از درخواستها، بر روی دادههایی به حجم ۱.۲۲ پتابایبای قرار داشتند.
در حقیقت، نوع بار کاری مورد آزمایش بسیار خاص و محدود است: انجام یک درخواست نقطهای در یک شارد، که تنها یک ردیف مشخص را بر اساس کلید اصلی بازیابی میکند؛ بدون نوشتن، عملیاتهای اتصال (join) یا درخواستهای میان شاردی. این محدودیتها و سادگی، سبب میشود نتایج و منحنی مقیاسپذیری بسیار واضح و منظم باشد، چون تقاضای سیستم در این حالت کمتر پیچیده است و منابع به شکل بهینه و مستقیم استفاده میشوند.
در این نمونه، توانایی سیستم در مدیریت حجم بینظیر درخواستها، نشان میدهد که چگونه یک معماری شاردینگ هوشمند و طراحی مناسب، میتواند عملیات عظیم و بوتسلم درخواستها را به راحتی تحمل کند. این آزمایش، نمونهای است برای نشان دادن پتانسیل مقیاسپذیری سیستمهای پایگاه داده در آینده، جایی که نیازمند پاسخگویی سریع و حجم بالای درخواستها هستیم.
#پایگاه_داده #مقیاسپذیری #سیستمهای_پایگاه #کلود
🟣لینک مقاله:
https://planetscale.com/blog/118-million-queries-per-second-on-neki?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
118 million queries per second on Neki (9 minute read)
🟢 خلاصه مقاله:
پلانیتاسکیل تصمیم گرفت در آزمایشی بینظیر، یک میلیون درخواست در ثانیه بر روی سیستم جدید و شارد شدهی خودش به نام نکی، اجرا کند. این آزمایش در همان ابتدا، به سرعت و تقریباً بلافاصله با استفاده از ۵ شارد، به این هدف رسید. سپس با ادامه آزمایش و افزودن شاردهای بیشتر، تعداد شاردها تا ۵۱۲ افزایش پیدا کرد و در نتیجه، توانست در مجموع به ۱۱۸ میلیون درخواست در ثانیه دست یابد. این حجم از درخواستها، بر روی دادههایی به حجم ۱.۲۲ پتابایبای قرار داشتند.
در حقیقت، نوع بار کاری مورد آزمایش بسیار خاص و محدود است: انجام یک درخواست نقطهای در یک شارد، که تنها یک ردیف مشخص را بر اساس کلید اصلی بازیابی میکند؛ بدون نوشتن، عملیاتهای اتصال (join) یا درخواستهای میان شاردی. این محدودیتها و سادگی، سبب میشود نتایج و منحنی مقیاسپذیری بسیار واضح و منظم باشد، چون تقاضای سیستم در این حالت کمتر پیچیده است و منابع به شکل بهینه و مستقیم استفاده میشوند.
در این نمونه، توانایی سیستم در مدیریت حجم بینظیر درخواستها، نشان میدهد که چگونه یک معماری شاردینگ هوشمند و طراحی مناسب، میتواند عملیات عظیم و بوتسلم درخواستها را به راحتی تحمل کند. این آزمایش، نمونهای است برای نشان دادن پتانسیل مقیاسپذیری سیستمهای پایگاه داده در آینده، جایی که نیازمند پاسخگویی سریع و حجم بالای درخواستها هستیم.
#پایگاه_داده #مقیاسپذیری #سیستمهای_پایگاه #کلود
🟣لینک مقاله:
https://planetscale.com/blog/118-million-queries-per-second-on-neki?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
118 million queries per second on Neki — PlanetScale
We ran a massive, sharded Postgres database at 118.5 million queries per second, with 200k queries per second on each shard across 512 shards.