من در تعجبم ، چطور میشه به دیتابیس 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
ضعف در 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
Telegram
Academy and Foundation unixmens | Your skills, Your future
@unixmens_support
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
@yashar_esm
[email protected]
یک کانال علمی تکنولوژی
فلسفه متن باز-گنو/لینوکس-امنیت - اقتصاد
دیجیتال
Technology-driven -بیزینس های مبتنی بر تکنولوژی
Enterprise open source
ارایه دهنده راهکارهای ارتقای سازمانی - فردی - تیمی
❤1😨1
https://www.linkedin.com/posts/yashar-esmaildokht_microsoft-database-mssql-activity-7392632583261671424-ubUc?utm_source=share&utm_medium=member_android&rcm=ACoAAAnfO_YBNNy0I0KDbmiPAF0Wc2Zthlv-zco
انحصار تدریجی در عصر ابر: تحلیلی بر سیاستهای Azure SQL و مفهوم "Lock-in"
#microsoft #database #mssql #oracle #mysql #mariadb
unixmens
https://t.iss.one/unixmens
انحصار تدریجی در عصر ابر: تحلیلی بر سیاستهای Azure SQL و مفهوم "Lock-in"
#microsoft #database #mssql #oracle #mysql #mariadb
unixmens
https://t.iss.one/unixmens
Linkedin
انحصار تدریجی در عصر ابر: تحلیلی بر سیاستهای Azure SQL و مفهوم "Lock-in" | Yashar Esmaildokht
انحصار تدریجی در عصر ابر: تحلیلی بر سیاستهای Azure SQL و مفهوم "Lock-in"
#microsoft #database #mssql #oracle #mysql #mariadb
unixmens
https://t.iss.one/unixmens
#microsoft #database #mssql #oracle #mysql #mariadb
unixmens
https://t.iss.one/unixmens