Academy and Foundation unixmens | Your skills, Your future
2.3K subscribers
6.68K photos
1.39K videos
1.24K files
6.17K links
@unixmens_support
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
Download Telegram
من در تعجبم ، چطور میشه به دیتابیس mssql اعتماد کرد ، وقتی مفهوم xtransaction و sharding را هنوز پشتیبانی نمیکنه


ضعف در Sharding (افقی‌سازی داده)

در حالی که MSSQL مفهومی به نام Partitioning دارد، اما این بیشتر شبیه Horizontal Partitioning داخلی در همان دیتابیس است، نه Sharding واقعی.

همچنین Sharding واقعی یعنی توزیع داده در چند نود مستقل (با استقلال پردازشی و storage)، در حالی که Partitioning در MSSQL همه‌چیز را داخل یک Instance نگه می‌دارد.

حتی قابلیت‌های “Federation” و “Elastic Database” که مایکروسافت در Azure معرفی کرده بود، عملاً depreciated شدند و به جای آنها Azure SQL Hyperscale یا Cosmos DB معرفی شد.
یعنی خود مایکروسافت هم پذیرفته که MSSQL به‌صورت native توان Sharding ندارد

⚙️ ۲. ضعف در Cross-Transaction / Distributed Transaction

در واقع MSSQL از Transaction Coordinator (MSDTC) برای تراکنش‌های توزیع‌شده استفاده می‌کند،
اما این مدل:

وابسته به Windows و DCOM است (در نسخه‌های لینوکسی هم محدودیت شدید دارد

باعث افزایش latency، overhead شبکه و کاهش scalability می‌شود.

برای معماری‌های Microservices و Cloud-native اصلاً قابل توصیه نیست.


در مقابل، دیتابیس‌هایی مثل:

وCockroachDB → از Raft و MVCC برای تراکنش‌های ACID توزیع‌شده استفاده می‌کند.

و TiDB → از مدل Percolator (گوگل) برای snapshot isolation در شاردهای مختلف بهره می‌برد.
یعنی در این دیتابیس‌ها، تراکنش به‌صورت natively distributed است، نه از طریق سرویس جانبی

🧠 ۳. دیدگاه فلسفی طراحی

در واقع SQL Server ذاتاً برای دنیای Monolithic Enterprise طراحی شده بود:

“یک دیتابیس مرکزی، روی یک سرور قدرتمند، برای کل سازمان.”



اما امروزه معماری‌ها تغییر کرده‌اند:

“چندین نود، در چند دیتاسنتر، با نیاز به eventual consistency و elastic scale.”



بنابراین حتی با وجود قابلیت‌هایی مثل:

Always On Availability Groups

Read Scale-Out Replicas

Clustered Instances


باز هم MSSQL در واقع Shared-Nothing Sharding یا Multi-Region Write واقعی ندارد.

این قابلیت در mariadb و mysql هم حتی وجود دارد در spider database storage engine و مدیریت با maxscale



وقتی حتی MySQL/MariaDB چنین قابلیت‌هایی دارند، اعتماد کامل به MSSQL در دنیای مدرن سخت است.



و SQL Server شاید از نظر ابزار مدیریتی (SSMS, Data Studio, Profiler, Integration Services) قوی‌تر باشد،
اما از نظر فلسفه‌ی توزیع، مقیاس‌پذیری و استقلال نودها، واقعاً عقب مانده است.



#mssql #windows #database
https://t.iss.one/unixmens
1😨1