Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon DynamoDB Transactions

aws.amazon.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Amazon DynamoDB Transactions

#51

Post by airwot4 »

otterley wrote: post #23
ryanworl wrote: post #10

“DynamoDB is the only non-relational database that supports transactions across multiple partitions and tables.” Uh... this is just not true.

Can you identify some others?

As far as I'm aware these offerings support transactions across the entire database.

Google Cloud Spanner: https://cloud.google.com/spanner/docs/transactions

Google Cloud Firestore: https://firebase.google.com/docs/firestore/manage-data/trans...

Plus if you use Cloud Firestore in Datastore Mode then Google Cloud Datastore would satisfy this requirement as well.

Re: Amazon DynamoDB Transactions

#52

Post by airwot4 »

stickfigure wrote: post #28
otterley wrote: post #23

Earlier quoted context omitted.

Can you identify some others?

The Google Cloud Datastore (formerly the "App Engine Datastore") has had cross-entity-group transactions since 2011: https://googleappengine.blogspot.com/2011/10/app-engine-155-...

The cross group transactions are a little limited - https://cloud.google.com/appengine/docs/standard/java/datast...

I don't think it's fair to compare them.

However, the more recent Google storage offerings based on Cloud Spanner do seem to offer this. I don't see how Amazon can make this statement - that doesn't stop it being an excellent enhancement to DynamoDB though.

Re: Amazon DynamoDB Transactions

#53

Post by ngrilly »

manigandham wrote: post #48
ngrilly wrote: post #40

Earlier quoted context omitted.

> It's slower because of SQL parsing and generally the SQL clients are not as fast I'd be really surprised if the client library introduces a latency significant enough to be compared to the network latency between the app server and the database server.

Many libraries handle db connections poorly, or have heavy-handled pooling systems, or aren't fully async, all of which limits total throughput. The key/value clients usually have a much simpler APIs like HTTP which scale much better.

I don't understand. What makes you think it's easier for NoSQL clients (versus SQL clients) to correctly implement connection pooling and async networking? For example, MongoDB and Cassandra wire protocols are not based on HTTP. And even if they were based on HTTP, connection pooling and async networking still requires a specific effort. Which libraries are you thinking of (as examples of good and bad behavior)?

Re: Amazon DynamoDB Transactions

#54

Post by anentropic »

Rafuino wrote: post #18
piinbinary wrote: post #2

My wishlist for DynamoDB is now down to: * Fast one-time data import without permanently creating a lot of shards (important if you are restoring from a backup) * Better visibility into what causes throttling (e.g. was it a hot shard? Was it a brief but large burst of traffic?) * Lower p99.9 latency. It occasionally has huge latency spikes. * Indexes of more than 2 columns * A solution for streaming out updates that…

What kind of p99.9 latency are you looking for?

and would Dax help?

Re: Amazon DynamoDB Transactions

#55

Post by ddorian43 »

ngrilly wrote: post #53
manigandham wrote: post #48

Earlier quoted context omitted.

Many libraries handle db connections poorly, or have heavy-handled pooling systems, or aren't fully async, all of which limits total throughput. The key/value clients usually have a much simpler APIs like HTTP which scale much better.

I don't understand. What makes you think it's easier for NoSQL clients (versus SQL clients) to correctly implement connection pooling and async networking? For example, MongoDB and Cassandra wire protocols are not based on HTTP. And even if they were based on HTTP, connection pooling and async networking still requires a specific effort. Which libraries are you thinking of (as examples of good and bad behavior)?

Example: psycopg2 (python-postgresql driver) doesn't have (or sucks) prepared statements compared to cassandra driver.

Re: Amazon DynamoDB Transactions

#56

Post by antonp »

piinbinary wrote: post #2

My wishlist for DynamoDB is now down to: * Fast one-time data import without permanently creating a lot of shards (important if you are restoring from a backup) * Better visibility into what causes throttling (e.g. was it a hot shard? Was it a brief but large burst of traffic?) * Lower p99.9 latency. It occasionally has huge latency spikes. * Indexes of more than 2 columns * A solution for streaming out updates that…

> * A solution for streaming out updates that is better than dynamodb streams

What bothers you about dynamodb streams specifically?

Re: Amazon DynamoDB Transactions

#57

Post by ngrilly »

ddorian43 wrote: post #55
ngrilly wrote: post #53

Earlier quoted context omitted.

I don't understand. What makes you think it's easier for NoSQL clients (versus SQL clients) to correctly implement connection pooling and async networking? For example, MongoDB and Cassandra wire protocols are not based on HTTP. And even if they were based on HTTP, connection pooling and async networking still requires a specific effort. Which libraries are you thinking of (as examples of good and bad behavior)?

Example: psycopg2 (python-postgresql driver) doesn't have (or sucks) prepared statements compared to cassandra driver.

Right, but that has nothing to do with connection pooling and sync. And there is no structural reason that makes easier to implemented prepared statements for PostgreSQL than for Cassandra. It's anecdotal evidence.

Re: Amazon DynamoDB Transactions

#59

Post by monstrado »

otterley wrote: post #43
monstrado wrote: post #26

Earlier quoted context omitted.

FoundationDB https://www.foundationdb.org/ not only supports transactions, they are mandatory. They also go one step further and support atomic operations, which are especially killer.

I don’t think FDB supports cross-database transactions, though.

There's not really a concept of "Database" in FDB. There is however a concept of key spaces, and "directories", which are basically the same, and these all support transactions.

i.e.

/database1/key1 = foo

/database2/key2 = bar

Re: Amazon DynamoDB Transactions

#60

Post by kevan »

airwot4 wrote: post #52
stickfigure wrote: post #28

Earlier quoted context omitted.

The Google Cloud Datastore (formerly the "App Engine Datastore") has had cross-entity-group transactions since 2011: https://googleappengine.blogspot.com/2011/10/app-engine-155-...

The cross group transactions are a little limited - https://cloud.google.com/appengine/docs/standard/java/datast... I don't think it's fair to compare them. However, the more recent Google storage offerings based on Cloud Spanner do seem to offer this. I don't see how Amazon can make this statement - that doesn't stop it being an excellent enhancement to DynamoDB though.

I don't know if the overall statement is true, but Spanner is relational and the statement was limited to non-relational databases.
Post reply on HN