🔵 عنوان مقاله
On Postgres 18's New Default for Data Checksums

🟢 خلاصه مقاله:
در نسخه ۱۸ پایگاه داده پسترگس، قابلیت جدیدی به صورت پیش‌فرض فعال شده است که مربوط به بررسی چک‌سام‌های داده‌ها است. این ویژگی به عنوان یکی از مکانیزم‌های حفاظتی طراحی شده است تا از بروز خطاهای خاموش و پنهان در داده‌ها جلوگیری کند. در واقع، با فعال‌سازی این قابلیت، سیستم به طور دائم و خودکار صحت و سلامت داده‌ها را نظارت می‌کند و در صورت بروز هرگونه تغییر غیرعادی، سریعاً هشدار می‌دهد یا اقدام لازم را انجام می‌نماید.

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

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

#پسترگس #دیتابیس #چک‌سام #امنیت_داده

🟣لینک مقاله:
https://postgresweekly.com/link/178680/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

وقتی یه تأخیر کوچیک توی لایه‌ی شبکه می‌تونه CPU همه‌ی نودهای Redis Cluster رو به ۱۰۰٪ برسونه و کل سرویس رو از کار بندازه — توی این شرایط چیکار می‌کنید؟ 😨💥

توی یکی از پیچیده‌ترین اینسیدنت‌های Figma، دقیقاً همین اتفاق افتاد.
یه تأخیر جزئی توی شبکه باعث شد Cluster Bus در Redis وارد یه loop پردازشی بشه؛ CPU همه‌ی نودها به سقف رسید و برخلاف انتظار، حتی افزایش منابع سخت‌افزاری هم مشکل رو حل نکرد.

نکات کلیدی‌ای که معمولاً نادیده گرفته می‌شن:
🔹 توی معماری Redis Cluster، Pub/Sub یه سربار پنهان توی مدیریت بافر داره
🔹 این سربار توی ترافیک پایین عملاً دیده نمی‌شه
🔹 اما توی اسکیل بالا، می‌تونه به یه CPU Storm جدی تبدیل بشه و استراتژی ساده‌ی Scale-up رو بی‌اثر کنه

اگه توی تیم‌های SRE یا DevOps هستید و Redis رو به‌عنوان Cache یا Message Broker توی یه سیستم Distributed استفاده می‌کنید، حتماً باید حواستون به این رفتارها و محدودیت‌هاش باشه.

توی جدیدترین قسمت Inspect، رفتیم سراغ Root Cause این اینسیدنت و دقیق بررسیش کردیم:
• چرا Cluster Bus این‌قدر به latency شبکه حساسه؟
• محدودیت‌های ذاتی Redis Pub/Sub توی کلاستر چیه؟
• چطور می‌شه با راهکارهایی مثل Sharded Pub/Sub یا انتخاب جایگزین‌های مناسب، معماری رو مقاوم‌تر کرد؟

🔗https://www.youtube.com/watch?v=9niQgeEUavg

اExecution Plan Query یعنی برنامه‌ای که دیتابیس برای اجرای یک Query انتخاب می‌کند.

به زبان ساده 👇
وقتی شما یک SQL Query می‌نویسید، دیتابیس قبل از اجرا تصمیم می‌گیرد:

* از کدام Index استفاده کند
* جدول‌ها را به چه ترتیبی بخواند
*ا Joinها را چطور انجام دهد
* چقدر هزینه (Cost) دارد

این نقشه‌ی اجرا همان Execution Plan است.

چرا Execution Plan مهم است؟

چون کمک می‌کند بفهمیم:

* چرا یک Query کند است
* آیا Index درست استفاده می‌شود یا نه
* کدام بخش Query بیشترین فشار را دارد


مثال ساده

SELECT *
FROM users
WHERE email = 'test@gmail.com';

اExecution Plan مشخص می‌کند:


* آیا از Index روی email استفاده می‌شود؟
* یا کل جدول (Full Table Scan) خوانده می‌شود؟



چطور Execution Plan ببینیم؟


MySQL

EXPLAIN SELECT * FROM users WHERE email = 'test@gmail.com';

PostgreSQL

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'test@gmail.com';

SQL Server

SET STATISTICS PROFILE ON;

یا

ا`Include Actual Execution Plan` در SSMS


چه زمانی باید Execution Plan چک کنیم؟


* اQuery کند است
* بعد از اضافه کردن Index تغییری نکرده
* دیتابیس CPU یا RAM زیادی مصرف می‌کند
* پروژه‌های بزرگ یا Production

🔵 عنوان مقاله
a $50 PlanetScale Metal plan

🟢 خلاصه مقاله:
طرح PlanetScale Metal به ارزش ۵۰ دلار، در واقع یک نسخه کوچک‌تر از برنامه‌های حرفه‌ای این سرویس است. این برنامه برای کسب‌وکارهایی طراحی شده است که نیازمند قدرت و انعطاف‌پذیری کمتری هستند، اما همچنان می‌خواهند از امکانات قدرتمند بانک اطلاعاتی بهره‌مند شوند. این طرح به کاربر این امکان را می‌دهد تا با کم‌ترین میزان منابع، یعنی تنها ۱ گیگابایت رم و حداقل ۱۰ گیگابایت فضای ذخیره‌سازی، پروژه‌های خود را اداره کند و نیازهای روزمره خود را برطرف نماید.

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

در نتیجه، PlanetScale Metal یک گزینه عالی برای کسانی است که نیازمند یک پایگاه داده کارآمد، راحت و اقتصادی هستند و می‌خواهند پروژه‌های خود را بدون نیاز به سرمایه‌گذاری زیاد راه‌اندازی و مدیریت کنند.

#پایگاه_داده #پلاکمقابل_ارتقا #توسعه_وب #پروژه‌های_حرفه‌ای

🟣لینک مقاله:
https://postgresweekly.com/link/178678/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
What You Can Expect From PGConf.dev

🟢 خلاصه مقاله:
در ادامه برنامه‌های پیش روی کنفرانس PGConf.dev، شما می‌توانید انتظار چه مواردی را داشته باشید؟ ملانی پلاگمن در این باره با کلر جیوردانو گفتگو کرده است تا جزئیات و برنامه‌های مهم این رویداد مهم در ماه مه آینده در ونکوور، کانادا را با شما به اشتراک بگذارد. این کنفرانس فرصت بی‌نظیری است برای توسعه‌دهندگان و فعالان حوزه فناوری برای آشنایی با جدیدترین دستاوردها، به‌اشتراک‌گذاری تجربیات، و برقراری ارتباط با متخصصان برجسته در صنعت. حضور در چنین رویدادی نه تنها امکان یادگیری مهارت‌های جدید را فراهم می‌آورد، بلکه راه‌های تازه‌ای برای گسترش شبکه حرفه‌ای شما باز می‌کند و نقش مؤثری در پیشرفت شخصی و حرفه‌ای‌تان دارد. در نهایت، این کنفرانس برآن است تا با برگزاری جلسات، کارگاه‌ها و گفتگوهای آموزشی غنی، آینده فناوری و توسعه نرم‌افزار را شکل دهد و فرصت ارزشمندی برای شرکت‌کنندگان فراهم آورد.

#کنفرانس_توسعه #فناوری #شبکه_سازى #رشد_حرفه‌ای

🟣لینک مقاله:
https://postgresweekly.com/link/178681/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🥇 اگر عاشق تکنولوژی‌های روز دنیا هستی، اینجا هر روز تازه‌ترین و مهم‌ترین مطالب درباره:👇

🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژی‌های نو
🔌 دنیای الکترونیک و گجت‌های هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حمل‌ونقل

همه چیز به‌صورت کوتاه، خلاصه و کاملاً قابل‌فهم👇👇

🥈 @futurepulse_persian

🔵 عنوان مقاله
Postgres, MongoDB, and What “Cannot Scale” Really Means

🟢 خلاصه مقاله:
در دنیای پایگاه‌های داده، مقوله مقیاس‌پذیری همواره یکی از چالش‌های مهم توسعه‌دهندگان و مدیران فناوری اطلاعات بوده است. در این میان، چندین سیستم محبوب مانند PostgreSQL و MongoDB نقش مهمی در استراتژی‌های داده‌ای شرکت‌ها ایفا می‌کنند. اما مفهومی که اغلب درباره آن صحبت می‌شود، یعنی «نتوانستن در مقیاس بزرگ» یا همان «Cannot Scale»، موضوعی است که باید به دقت بررسی شود تا حقیقت پشت آن مشخص گردد.

در خبر اخیر منتشر شده در نشریه «ذا ریجستر»، صحبت‌هایی از مدیرعامل شرکت MongoDB نقل شده است که ادعا می‌کند «PostgreSQL نمی‌تواند به راحتی در مقیاس بزرگ عمل کند». این دیدگاه، بازتاب دهنده نگرانی‌های رایج درباره محدودیت‌های سیستم‌های رابطه‌ای در مقایسه با سامانه‌های NoSQL است. ولی آیا واقعاً این ادعا درست است؟ یا شاید تعریفی نادرست از توانایی‌های هر سیستم است که در اینجا مطرح شده است؟

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

بنابراین، ادعای اینکه یکی توانایی «نمی‌تواند در مقیاس بزرگ باشد»، شاید اغراق‌آمیز یا نگاهی نادرست به توانایی‌های کامل آن سیستم باشد. تصمیم‌گیری در مورد نوع پایگاه داده باید بر اساس نیازهای خاص پروژه، حجم داده‌ها، سطح ترافیک و معیارهای امنیت باشد، نه بر اساس کلیشه‌ها یا نظرات مقطعی.

در نهایت، درک صحیح از محدودیت‌ها و قابلیت‌های هر سیستم، کلید موفقیت در طراحی زیرساخت‌های داده‌ای است. هر دو نوع پایگاه داده، یعنی PostgreSQL و MongoDB، ابزارهای قدرتمندی هستند که در مواقع مناسب، می‌توانند نیازهای مختلف سازمان‌ها را برآورده کنند، بدون اینکه به عبارتی «نمی‌توانند در مقیاس بزرگ» خرده‌ای وارد باشد.

#پایگاه_داده #مقیاس_پذیری #PostgreSQL #MongoDB

🟣لینک مقاله:
https://postgresweekly.com/link/178321/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
pgEdge shows off its new Postgres MCP server

🟢 خلاصه مقاله:
شرکت pgEdge به تازگی از سرور جدید خود با نام Postgres MCP رونمایی کرده است. این سرور قدرتمند امکان اتصال ابزارهای هوشمند مانند Claude Code به هر پایگاه داده پستگرس را فراهم می‌کند، تا کاربران بتوانند به راحتی با طرحواره‌ها، معیارها و داده‌های مختلف کار کنند. این فناوری نوآورانه به توسعه‌دهندگان و مدیران دیتابایک‌ها این امکان را می‌دهد که فرآیند مدیریت، تحلیل و بهره‌برداری از داده‌های خود را ساده‌تر و سریع‌تر انجام دهند. سرور MCP جدید، با طراحی مدرن و قابلیت‌های گسترده، نویدبخش پیشرفت‌های چشمگیری در حوزه مدیریت دیتابیک است و می‌تواند نقش مهمی در بهبود بهره‌وری و توسعه سیستم‌های پایگاه داده ایفا کند.

#پایگاه_دیتا #توسعه_فناوری #مدیریت_دیتابیس #پستگرس

🟣لینک مقاله:
https://postgresweekly.com/link/178677/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Microsoft Unveiled its VS Code 'IDE for Postgres'

🟢 خلاصه مقاله:
در ماه مه گذشته، شرکت مایکروسافت نسخه آزمایشی افزونه جدیدی برای ویرایشگر VS Code رونمایی کرد که مخصوص مدیریت پایگاه‌های داده پستگرس طراحی شده است. این افزونه امکانات متعددی را فراهم می‌کند، از جمله امکان مدیریت اشیاء دیتابیس، استفاده از فناوری IntelliSense برای ساخت کوئری‌ها و همچنین ادغام با سیستم هوشمند Copilot. این ابزار جدید، قابلیت‌های قدرتمندی را در اختیار توسعه‌دهندگان قرار می‌دهد تا بتوانند به راحتی و با سرعت بیشتری عملیات مربوط به پایگاه‌ داده‌های پستگرس را انجام دهند، بدون نیاز به ابزارهای جداگانه یا محیط‌های پیچیده.

این پیش‌نمایش نشان می‌دهد که مایکروسافت قصد دارد ابزارهای توسعه پایگاه داده‌ها را برای کاربران VS Code بیش از پیش یکپارچه و کاربرپسند کند، و توسعه‌دهندگان را در انجام وظایف مربوط به دیتابیس‌ها یاری دهد. با امکاناتی نظیر مدیریت اشیاء و کوئری‌نویسی هوشمند، این افزونه می‌تواند به طور چشمگیری فرآیندهای توسعه و نگهداری پایگاه‌های داده را تسهیل کند و بهره‌وری کلی را افزایش دهد.

#مایکروسافت #پستگرس #VSCode #توسعه‌دهندگان

🟣لینک مقاله:
https://postgresweekly.com/link/178689/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

بعضی وقتا گلوگاه performance دیتابیس از query یا infra نیست، از primary key میاد.

اUUID چون randomه، هر insert رو می‌فرسته یه جای متفاوت از B-treeی که برای ایندکس ها ساخته شده و ممکنه باعث شه درخت دوباره ساخت بشه؛ نتیجه‌اش cache miss، page split و write cost بالاتره. زیر بار دیتابیس زود به سقف CPU می‌رسه.

در مقابل، bigint auto-increment همیشه آخر index می‌نویسه و رفتار دیتابیس قابل پیش‌بینی میشه. تو تست‌های واقعی، فقط با عوض کردن UUID به bigserial، throughput چند برابر بهتر شده بدون اینکه data model یا business logic تغییر کنه.
اprimary key تصادفی یعنی مالیات دائمی روی هر write

راه بهتر اینه که primary key داخلی bigint باشه و یه public UUID برای بیرون سیستم داشته باشی. اگه client-generated id لازم داری، می‌تونی از time-orderd مثله Snowflake استفاده کنی تا keyها تقریبا ترتیبی باشن و توی سیستم های توزیع شده هم یکتا باشن و هم index اذیت نشه.

<Go Talk | گو تاک/>

🔵 عنوان مقاله
Multigres: Vitess for Postgres

🟢 خلاصه مقاله:
ویتس یک سیستم خوشه‌بندی محبوب است که عمدتاً برای افزایش مقیاس‌پذیری و تقسیم‌بندی داده‌ها در MySQL استفاده می‌شود. این سیستم توانسته است نیازهای شرکت‌ها و توسعه‌دهندگان را برای مدیریت حجم بزرگ داده‌ها و بهبود عملکرد پایگاه‌های داده برآورده کند. امسال، تیم Supabase یکی از بنیان‌گذاران و طراحان اصلی ویتس، آقای سوگو سوجومارانه، را برای توسعه نسخه‌ای مخصوص پایگاه داده PostgreSQL استخدام کرد. این پروژه در حال حاضر در مراحل اولیه قرار دارد و تیم توسعه در حال کار بر روی آن است تا بتواند امکانات و قابلیت‌های مشابه ویتس در محیط PostgreSQL را فراهم کند.

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

در این مسیر، توسعه‌دهندگان و علاقه‌مندان به پایگاه داده‌ها باید منتظر بمانند تا امکانات و قابلیت‌های نهایی این نسخه جدید در دسترس قرار گیرد، تا بتوانند از آن در پروژه‌های خود بهره‌مند شوند.

#پایگاه_داده #PostgreSQL #پروژه_بازمتن #توسعه

🟣لینک مقاله:
https://postgresweekly.com/link/178690/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

راهنمای کامل انواع Lock در Redis

از سری آموزش Redis رسیدیم 🔥
این بار یک پست جامع و کامل درباره تمامی Redis Locks منتشر می‌کنم.
چون هر کدام از این Redis Lock نیاز به سناریوی واقعی، کد ، تست دارن و این کار خیلی زمان‌بره، اول یک نمای کلی دقیق از همه‌شون می‌دم و بعد به‌مرور برای هر کدام یک پست جداگانه + پروژه واقعی + کد کامل منتشر می‌کنم.
لیست کامل ۱۲ نوع قفل مهم Redis که در این سری پوشش داده می‌شن:

1- Simple Lock
2- Safe Simple Lock
3- Redlock
4- Reentrant Lock
5- Read-Write Lock
6- Semaphore Lock
7- Fair Lock
8- Fencing Token Lock
9- Striped / Sharded Lock
10- Multi-Resource Lock
11- Auto-Renewal / Watchdog Lock
12- Leased Lock

لینک مقاله در Medium:
https://lnkd.in/dqWcJixP

👉Amirhossein Jafari
Devops EngineerDevops Engineer


آخر هفته گذشته روی راه‌اندازی Redis در Kubernetes کار می‌کردم و عملاً دوباره تفاوت مودهای مختلف Redis را بررسی کردم؛ از Standalone و Replication تا Sentinel و در نهایت Redis Cluster. چیزی که خیلی واضح مشخص می‌شه اینه که اگر مود اشتباه انتخاب بشه، حتی با infrastructure قوی هم خیلی سریع به مشکل performance یا availability می‌خوریم. Redis Cluster تنها مدلی هست که هم write scalability دارد و هم high availability واقعی، ولی در عوض کمی پیچیدگی بیشتری در اجرا و سمت کلاینت داره.
پیاده‌سازی Redis Cluster روی Kubernetes با StatefulSet و Headless Service، وقتی درست انجام شود، نتیجه‌اش کاملاً قابل مشاهده است: توزیع بهتر load، latency پایدارتر زیر فشار، و حذف single point of failure. توی تست‌هایی که داشتم، پخش شدن writeها روی چند master تأثیر مستقیم روی throughput داشت، مخصوصاً در workloadهای write-heavy. در نهایت، Redis فقط یک cache سریع نیست؛ معماری‌ای که براش انتخاب می‌کنیم مستقیماً روی رفتار سیستم در مقیاس و موقع failure اثر میذاره.

🔵 عنوان مقاله
PostgREST 14: A RESTful API for Postgres Databases

🟢 خلاصه مقاله:
در سال ۲۰۲۵، سال پرکاری برای سرورهای وب مستقل بود که به طور مستقیم، بانک اطلاعاتی پستگرس شما را به یک رابط برنامه‌نویسی تحت وب RESTful تبدیل می‌کنند. در این سال، نسخه‌های ۱۳ و ۱۴ این ابزار قدرتمند و محبوب عرضه شدند، هر کدام با قابلیت‌ها و بهبودهای خاص خودشان که کار توسعه‌دهندگان را بسیار راحت‌تر و کارآمدتر کرده است.

این پروژه، که PostgREST نام دارد، به توسعه‌دهندگان اجازه می‌دهد تا بدون نیاز به نوشتن کدهای پیچیده، به سرعت و با سهولت، از بانک اطلاعاتی پستگرس خود در قالب APIهای استاندارد استفاده کنند. نسخه‌های جدید علاوه بر بهبودهای عملکرد، امکانات تازه‌ای ارائه می‌دهند که توسعه و مدیریت APIها را ساده‌تر و انعطاف‌پذیرتر می‌سازند.

در مجموع، سال ۲۰۲۵ نشان داد که ابزارهای متن‌باز و مخصوص مدیریت بانک‌های اطلاعاتی، همچنان در حال توسعه و ارتقاء هستند و آینده‌ای روشن در انتظار آن‌ها است، چیزی که به توسعه‌دهندگان این امکان را می‌دهد تا در پروژه‌هایشان بهره‌وری بیشتری داشته باشند.

#پستگرس #API #وبسرویس #توسعه

🟣لینک مقاله:
https://postgresweekly.com/link/178696/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

مروری بر مفاهیم Vector Database

در ارائه اخیرم برای شرکت آپ، یک مخزن GitHub طراحی کردم تا اصول و الگوریتم‌های پایه‌ای vector databases را به شکل عملی نشان دهد. هدف این پروژه، آشنایی با حوزه‌های semantic search، vector similarity metrics و سیستم‌های بازیابی مبتنی بر بردار است و در عین حال فرصتی برای یادگیری عملی فراهم می‌کند.

ویژگی‌های کلیدی این repository شامل:
Neural network ساده با TensorFlow برای درک نحوه تولید بردارهای embedding
پیاده‌سازی یک vector database from scratch با cosine similarity برای فهم الگوریتم‌های جستجوی برداری
تحلیل داخلی Milvus internals برای بررسی معماری و بهینه‌سازی‌های عملکردی
نمونه عملی semantic search روی جملات با Milvus، شامل نحوه indexing و query بردارها
سرور MNIST FastAPI با PyTorch که تصویر عدد کاربر را دریافت کرده و نزدیک‌ترین بردارهای برچسب‌دار (nearest neighbor search) را پیش‌بینی می‌کند

این پروژه برای من علاوه بر یک تمرین عملی، فرصتی بود تا دانش خودم در زمینه vector-based retrieval systems را با دیگران به اشتراک بگذارم.

https://github.com/ap-incubator/vector-database

<Mohammad Nasr/