4 ms·

I am not an expert on RDBMSs, but isn't the issue of distributed computing and the CAP theorem a far more important driving force behind the NoSQL movement than

I am not an expert on RDBMSs, but isn't the issue of distributed computing and the CAP theorem a far more important driving force behind the NoSQL movement than any of the reasons in the article?

gfodor 13y ago
People who cite the CAP theorem as the reason they went with MongoDB etc for their tiny new project deserve some kind of premature optimization medal. The CAP theorem starts to matter when you are dealing with highly distributed systems, and even then there is almost certainly a long series of simpler workarounds to keep things usable than redoing your data architecture. Some downtime, too, is of course undesirable but acceptable up to a certain point, which is also something people tend to gloss over when raising concerns about CAP. The biggest hangup other than the UX issues the author talks about is the fear of having to manually shard your data. There are a lot of promises about automatically sharding your data from NoSQL vendors but I have no idea if they actually are able to deliver on this. If you are just doing a K-V store, then of course sharding is easy, regardless of the database you are using. I don't think there is really a silver bullet here, just maybe better tooling and removing redundant manual steps. You still need to think carefully about data access paths and queries and so on. Any additional sharding-centric features of NoSQL databases missing in mainstream databases could presumably be added, if they don't exist already with poor UX. For example PostgreSQL replication, wal log archiving, etc works great but it's still a bit tougher to set up than the more magical cluster auto discovery/configuration/sync stuff you see in things like elasticsearch. It would be interesting if the PostgreSQL people made a real push for a release to tighten up the operational UX of the product to be more human friendly instead of adding on more core features. (Not that I'm complaining, it's great!)
- craigkerstiens 13y ago
  > The biggest hangup other than the UX issues the author talks about is the fear of having to manually shard your data. There are a lot of promises about automatically sharding your data from NoSQL vendors but I have no idea if they actually are able to deliver on this. If you are just doing a K-V store, then of course sharding is easy, regardless of the database you are using. I don't think there is really a silver bullet here, just maybe better tooling and removing redundant manual steps. You still need to think carefully about data access paths and queries and so on. Any additional sharding-centric features of NoSQL databases missing in mainstream databases could presumably be added, if they don't exist already with poor UX. Original author here. Yes this is definitely another real hangup, though I semi-intentionally left this one out as magical sharding is still a bit unclear of how well it works depending on who you talk to. > For example PostgreSQL replication, wal log archiving, etc works great but it's still a bit tougher to set up than the more magical cluster auto discovery/configuration/sync stuff you see in things like elasticsearch. It would be interesting if the PostgreSQL people made a real push for a release to tighten up the operational UX of the product to be more human friendly instead of adding on more core features. (Not that I'm complaining, it's great!) A big plus one on all this as well, and we're doing what we can to push it forward.
hcarvalhoalves 13y ago
NoSQL databases are not a magic solution for CAP, they just make different trade-offs, so nothing stops you from using a RDBMS and choosing your own trade-offs too. For instance, you could choose to lose the C and have a multi-master PostgreSQL cluster by taking some measures, like using uuids and appending-only. In practice, you always have to solve some things on the application layer (e.g., distributed queries), so that's why out-of-the-box solutions are popular.
willlll 13y ago
no
- virmundi 13y ago
  Go on...
- eloff 13y ago
  Read the community rules please. Comments should add value. Nobody cares whether you agree or not. We want to know why you disagree.

I am not an expert on RDBMSs, but isn't the issue of distributed computing and the CAP theorem a far more important driving force behind the NoSQL movement than any of the reasons in the article?

gfodor 13y ago

People who cite the CAP theorem as the reason they went with MongoDB etc for their tiny new project deserve some kind of premature optimization medal. The CAP theorem starts to matter when you are dealing with highly distributed systems, and even then there is almost certainly a long series of simpler workarounds to keep things usable than redoing your data architecture. Some downtime, too, is of course undesirable but acceptable up to a certain point, which is also something people tend to gloss over when raising concerns about CAP. The biggest hangup other than the UX issues the author talks about is the fear of having to manually shard your data. There are a lot of promises about automatically sharding your data from NoSQL vendors but I have no idea if they actually are able to deliver on this. If you are just doing a K-V store, then of course sharding is easy, regardless of the database you are using. I don't think there is really a silver bullet here, just maybe better tooling and removing redundant manual steps. You still need to think carefully about data access paths and queries and so on. Any additional sharding-centric features of NoSQL databases missing in mainstream databases could presumably be added, if they don't exist already with poor UX. For example PostgreSQL replication, wal log archiving, etc works great but it's still a bit tougher to set up than the more magical cluster auto discovery/configuration/sync stuff you see in things like elasticsearch. It would be interesting if the PostgreSQL people made a real push for a release to tighten up the operational UX of the product to be more human friendly instead of adding on more core features. (Not that I'm complaining, it's great!)

craigkerstiens 13y ago
> The biggest hangup other than the UX issues the author talks about is the fear of having to manually shard your data. There are a lot of promises about automatically sharding your data from NoSQL vendors but I have no idea if they actually are able to deliver on this. If you are just doing a K-V store, then of course sharding is easy, regardless of the database you are using. I don't think there is really a silver bullet here, just maybe better tooling and removing redundant manual steps. You still need to think carefully about data access paths and queries and so on. Any additional sharding-centric features of NoSQL databases missing in mainstream databases could presumably be added, if they don't exist already with poor UX. Original author here. Yes this is definitely another real hangup, though I semi-intentionally left this one out as magical sharding is still a bit unclear of how well it works depending on who you talk to. > For example PostgreSQL replication, wal log archiving, etc works great but it's still a bit tougher to set up than the more magical cluster auto discovery/configuration/sync stuff you see in things like elasticsearch. It would be interesting if the PostgreSQL people made a real push for a release to tighten up the operational UX of the product to be more human friendly instead of adding on more core features. (Not that I'm complaining, it's great!) A big plus one on all this as well, and we're doing what we can to push it forward.

hcarvalhoalves 13y ago

NoSQL databases are not a magic solution for CAP, they just make different trade-offs, so nothing stops you from using a RDBMS and choosing your own trade-offs too. For instance, you could choose to lose the C and have a multi-master PostgreSQL cluster by taking some measures, like using uuids and appending-only. In practice, you always have to solve some things on the application layer (e.g., distributed queries), so that's why out-of-the-box solutions are popular.

willlll 13y ago

virmundi 13y ago
Go on...
eloff 13y ago
Read the community rules please. Comments should add value. Nobody cares whether you agree or not. We want to know why you disagree.