Quite possible the best NoSQL explanation articles I've seen. I usually describe it as "A database that sacrifices or reduces one of the tenants of a traditional SQL database for performance, availability and/or scale."
The harder part, is depending on your needs there are some ideal, and less than ideal fits for many of the options. As to one adjustment, I would consider DynamoDB closer to a column/bigtable store more than a key/value store.
Personally, I tend to favor some of the nosql variants or regular SQL depending on your needs. You can handle some issues in other ways. Also, if your db/system/site can be down for a few minutes for an upgrade/migration, then it's less of an issue, until it isn't.
In the beginning, developer time/comfort can and should account for a lot... as should insourcing and outsourcing and knowing your market, audience and potential needs. There are plenty of use cases that absolutely do NOT need to scale beyond a hundred users or so. There are others where you must scale to tens of thousands of requests per second and zero collective down time.
Of course, right now seeing the migration of a few problematic tables into separate service implementations backed by DynamoDB (each major cloud provider will have their own bigtable data solution), and it isn't always an easy transition. The hardest part is selling to some of the upper management types about eventual consistency and real-time enough.
1 comment
[ 4.0 ms ] story [ 10.6 ms ] threadThe harder part, is depending on your needs there are some ideal, and less than ideal fits for many of the options. As to one adjustment, I would consider DynamoDB closer to a column/bigtable store more than a key/value store.
Personally, I tend to favor some of the nosql variants or regular SQL depending on your needs. You can handle some issues in other ways. Also, if your db/system/site can be down for a few minutes for an upgrade/migration, then it's less of an issue, until it isn't.
In the beginning, developer time/comfort can and should account for a lot... as should insourcing and outsourcing and knowing your market, audience and potential needs. There are plenty of use cases that absolutely do NOT need to scale beyond a hundred users or so. There are others where you must scale to tens of thousands of requests per second and zero collective down time.
Of course, right now seeing the migration of a few problematic tables into separate service implementations backed by DynamoDB (each major cloud provider will have their own bigtable data solution), and it isn't always an easy transition. The hardest part is selling to some of the upper management types about eventual consistency and real-time enough.