既然可通过分片扩展SQL数据库并保障ACID，为何选用NoSQL？
Great question—you’re absolutely correct that sharding a SQL database using a hash strategy like id%4 lets you scale horizontally while retaining ACID guarantees within individual shards. But this approach has key limitations, and NoSQL databases fill critical gaps for specific use cases. Let’s break down the reasons you might still choose NoSQL:
1. Cross-shard complex queries become a bottleneck
When you shard SQL by hash, any query that needs to span multiple shards (like joins across tables on different shards, cross-shard GROUP BY, or aggregate reports) gets messy. You either have to:
- Pull data from multiple shards into your application layer and compute results there (adding complexity and latency), or
- Force the database to handle distributed queries, which often requires heavyweight coordination (like two-phase commit for transactions) that kills performance and introduces failure points.
NoSQL databases are often designed around denormalized or non-relational data models that avoid these cross-shard operations entirely. For example, a document database might store all related data (like a user and their orders) in a single document, eliminating the need for joins.
2. Schema rigidity slows down iteration
SQL databases enforce strict schemas. If you need to add a new field to a large sharded table, you have to run ALTER TABLE commands across every single shard—this can take hours (or longer) for big datasets, and may lock tables in the process.
Many NoSQL databases (like document or key-value stores) support dynamic schemas. You can add new fields to some records without affecting others, making it much easier to iterate on your data model as your business evolves (think: e-commerce products with wildly varying attributes, or user profiles that grow over time).
3. Optimized for specific workloads
NoSQL isn’t a single tool—it’s a category of databases built for specific use cases that SQL sharding struggles with:
- Key-value stores (e.g., Redis): Blazing-fast read/write performance for simple lookups (caching, session storage) that would require extensive tuning for a SQL cluster to match.
- Column-family stores (e.g., Cassandra): Built for high-volume, write-heavy workloads like time-series data or logs, with linear scalability and no single point of failure.
- Graph databases (e.g., Neo4j): Designed to model and query complex relationships (social networks, recommendation engines) far more efficiently than SQL, which would require messy joins across shards.
4. Operational simplicity at extreme scale
Sharding SQL manually works for moderate scale, but as you grow to hundreds of shards or PB-level data, the overhead skyrockets:
- Shard rebalancing: If you need to go from 4 to 8 servers, your
id%4strategy breaks—you’ll have to migrate millions of rows between shards, which is risky and time-consuming. - Failure recovery: Fixing a downed shard in a SQL cluster often requires manual intervention to reassign data or restore backups.
Most NoSQL databases handle these tasks natively: they use consistent hashing or automatic sharding to rebalance data without manual work, and built-in replication ensures failover happens seamlessly.
5. Consistency vs. availability trade-offs
ACID is great, but not every use case needs strict, immediate consistency. For example:
- Log aggregation: It’s fine if a log entry shows up a few seconds late.
- User likes/retweets: A small delay in updating counts doesn’t hurt.
NoSQL databases let you prioritize availability and performance over strict consistency (per the CAP theorem). For example, Cassandra lets you choose between strong consistency for critical operations and eventual consistency for high-throughput workloads—a flexibility that’s hard to achieve with a sharded SQL cluster, where cross-shard ACID transactions are either slow or impossible.
To be clear: Sharded SQL is an excellent choice for many businesses, especially if you rely heavily on complex relational queries and need strict ACID. NoSQL isn’t a replacement—it’s a complementary tool that solves problems SQL sharding can’t address efficiently.
内容的提问来源于stack exchange，提问作者Atharwa Adawdakar
