درستترش این است که به این موضوع نه بهعنوان یک «بهینهسازی جادویی»، بلکه بهعنوان یک تصمیم معماری…
انتشار: 2026/07/02 13:48 UTC
درستترش این است که به این موضوع نه بهعنوان یک «بهینهسازی جادویی»، بلکه بهعنوان یک تصمیم معماری با هزینه و محدودیتهای واقعی نگاه کنیم.اینکه آیا همه جدولها باید Index داشته باشند یا نه، در ظاهر یک سؤال ساده به نظر میرسد، اما در عمل یکی از جاهایی است که طراحی دیتابیس میتواند کاملاً از مسیر درست خارج شود. واقعیت این است که Indexها همیشه ابزار بهینهسازی نیستند؛ آنها در عین اینکه سرعت خواندن را بالا میبرند، هزینهی سنگینی روی نوشتن، نگهداری و حتی طراحی فیزیکی داده تحمیل میکنند. هر Index یعنی یک ساختار اضافه که باید همزمان با داده اصلی آپدیت شود و این موضوع در سیستمهای پرتراکنش بهسرعت به یک گلوگاه تبدیل میشود.در همین نقطه است که قابلیتهایی مثل Oracle Database In-Memory وارد بازی میشوند. ایدهی اصلی این تکنولوژی این نیست که Indexها را حذف کند، بلکه این است که یک مسیر کاملاً متفاوت برای اجرای Queryهای تحلیلی ارائه بدهد. در این مدل، دادهها علاوه بر ساختار سنتی سطری (Row Store)، بهصورت ستونی (Column Store) نیز در حافظه RAM نگهداری میشوند. این طراحی باعث میشود موتور دیتابیس بتواند روی حجمهای بزرگ داده، عملیاتهایی مثل Aggregation، Scan و Join را با الگوهای پردازشی بسیار سریعتر اجرا کند.اما نکتهای که معمولاً در توضیحات سادهشده نادیده گرفته میشود این است که In-Memory یک «حالت جایگزین عمومی» برای دیتابیس نیست. این قابلیت بهشدت وابسته به نوع workload است. در سناریوهای تحلیلی (OLAP)، جایی که Queryها روی حجم زیادی از داده اجرا میشوند و الگوی دسترسی بیشتر Scan محور است، In-Memory میتواند اثر چشمگیری داشته باشد. در چنین شرایطی حتی ممکن است نیاز به تعداد زیادی Index کاهش پیدا کند، چون موتور میتواند بهجای traversal در ساختارهای B-Tree، مستقیماً روی دادههای ستونی در RAM عملیات vectorized انجام دهد.اما در سیستمهای تراکنشی (OLTP)، داستان کاملاً متفاوت است. در اینجا Queryها معمولاً کوچک، هدفمند و وابسته به کلیدهای مشخص هستند. در چنین شرایطی Indexها همچنان نقش حیاتی دارند، چون دسترسی نقطهای (Point Lookup) چیزی نیست که In-Memory بتواند بهصورت بهینه جایگزین آن شود. حتی اگر In-Memory فعال باشد، حذف Index در این نوع سیستمها معمولاً به افت عملکرد منجر میشود، نه بهبود آن.نکته مهمتر این است که In-Memory فقط یک «ستونی شدن داده در RAM» نیست. پشت این قابلیت، مکانیزمهای پیچیدهای مثل فشردهسازی ستونمحور، پردازش SIMD، ساختارهای IMCU و انتخاب هوشمند Query Plan توسط Optimizer وجود دارد. یعنی اینکه یک جدول In-Memory باشد، به این معنا نیست که همیشه از آن استفاده میشود. تصمیم نهایی همچنان به Query Optimizer وابسته است و اگر شرایط مناسب نباشد، سیستم ممکن است مسیرهای سنتی دیسکی را انتخاب کند.از طرف دیگر، نباید هزینه را نادیده گرفت. In-Memory یعنی مصرف RAM بیشتر، و در مقیاسهای بزرگ این موضوع میتواند بسیار گران باشد. علاوه بر هزینه مستقیم حافظه، فشار روی Buffer Cache و رقابت منابع نیز میتواند اثرات جانبی ایجاد کند. بنابراین فعال کردن این قابلیت بدون تحلیل دقیق workload، بیشتر شبیه یک ریسک معماری است تا یک بهینهسازی.در نتیجه، نگاه درست به این موضوع این است که نه Indexها «همهجا ضروری هستند» و نه In-Memory «جایگزین آنهاست». هر دو ابزارهایی در یک جعبه ابزار هستند که باید بر اساس نوع بار کاری، الگوی دسترسی، هزینه منابع و هدف سیستم انتخاب شوند. سیستمهای مدرن دیتابیس به سمت مدلهای ترکیبی حرکت کردهاند، جایی که OLTP و OLAP در یک معماری همزیستی دارند و تصمیمگیری بین Index و In-Memory دیگر یک انتخاب مطلق نیست، بلکه یک طراحی دقیق و context-aware است.اگر بخواهیم جمعبندی سختگیرانهتری داشته باشیم، مسئله اصلی این نیست که «چه چیزی بهتر است»، بلکه این است که «در چه شرایطی چه چیزی کمتر اشتباه است».#database #oracle #devops
پستهای تلگرام — Academy and Foundation unixmens | Your skills, Your future
AI is entering the era of large-scale, distributed, agentic systems. Applications coordinate multiple models, tools, and services, process millions of requests, and demand enormous amounts of computer capacity. At the same time, infrastructure costs continue to climb, and access to AI hardware remains constrained by supply chains, vendor roadmaps, and rapidly evolving accelerator technologies.For many organizations, this creates a new kind of dependency. They've embraced open models and retained ownership of their data, yet their AI strategy still depends on a single hardware ecosystem.That's via Red Hat Blog ift.tt/3QGdiE0
Many believe that building models is the most challenging thing in AI, but managing the data that powers those models is equally difficult. We’ve all been there: a model's performance shifts or a data analysis yields inconsistent results, and you’re left wondering, "Wait, which version of the dataset did I use for this training run or report?"But, there’s good news. If you’re working in a Red Hat environment, our new AI quickstart helps address this exact problem. It combines the orchestration power of Red Hat OpenShift AI with the "Git-for-data" versioning capabilities of lakeFS.The Avia Red Hat Blog ift.tt/37TAZMI
Deploying Single Node OpenShift (SNO) using the Agent-Based Installer on KVM provides a fast, repeatable way to create a fully functional OpenShift cluster without dedicatedvia kifarunix.com ift.tt/aPoKtQC
وقتی میگوییم agent نباید در production استفاده شود . #agent #ai t.me/unixmenshttps://www.business-standar…
Large language model (LLM) API costs have a way of sneaking up on a business. What begins as a promising chatbot prototype often transforms into an invoice nightmare as users consume tokens at an unpredictable rate.A significant portion of these costs stems from repetitive queries. Users often ask the same questions. "What is the return policy?" or "Can I send this back?" phrased in slightly different ways. Another hidden cost can be from questions that are not relevant to the application, topic, or business, or that may even be abusive.Traditional caching fails in this situation because it revia Red Hat Blog ift.tt/35NChap