f you’ve used Go for a while you’re probably aware of some of the basic Go concurrency primitives:
go keyword for spawning goroutines
- Channels, for communicating between goroutines
context package for propagating cancellation
sync/atomic packages for lower-level primitives such as mutexes and atomic memory access
These language features and packages combine to provide a very rich set of tools for building concurrent applications. What you might not have discovered yet is a set of higher-level concurrency primitives available in the “extended standard library” available at golang.org/x/sync. We’ll be taking a look at these in this article.
This article is based on Go 1.13.
Go provides us a tool to enable tracing during the runtime and get a detailed view of the execution of our program. This tool can be enabled by flag
-trace with the tests, from
pprof to get live tracing, or anywhere in our code thanks to the
trace package. This tool can be even more powerful since you can enhance it with your own traces. Let’s review how it works.
Yet data modeling with DynamoDB is tricky for those used to the relational databases that have dominated for the past few decades. There are a number of quirks around data modeling with DynamoDB, but the biggest one is the recommendation from AWS to use a single table for all of your records.
In this post, we’ll do a deep dive on the concepts behind single-table design. You’ll learn:
“I have learned a lot more internal things about Google Cloud Spanner from past two days. I read some of the portions of the Spanner white paper and the deep internal things from the Google Cloud Next event videos from Youtube. I’ll share the video links here, but I want to summarize all the learnings in one place. That’s why I wrote this blog post. A special thanks to Deepti Srivastava(Product Manager for Spanner) who presented the Spanner Deep Dive sessions in the Google Cloud Next Event.”