Google Cloud Community is a Medium publication where Google engineers and users write about Google Cloud products, Kubernetes, BigQuery and related engineering topics.
HN commenters cite it for how-to posts and technical analysis, including Ollama on Cloud Run, LLM temperature, and CPU price-performance.
> Most of what you are saying is unsubstantiated.
You're welcome to your opinion.
> 1/ How easy is it to get data in? Seems standard.
It supports a MySQL adapter and a PostgreSQL adapter and then a bunch of Google property adapaters. This is standard.
> 2/ Is my data safe? Doesn't use SSL, major red flag.
The PostgreSQL adapter doesnt use SSL (https://support.google.com/datastudio/answer/7288010?hl=en&ref_topic=7332343). This is a showstopper.
> 3/ How easy is authoring? [EDIT] seems decent, see demo in reply.
You can see Felipe's demo here and make your own assessment. https://medium.com/google-cloud/showing-off-the-new-free-google-analytics-data-studio-with-reddit-aprils-gilded-comments-for-ebe965dbbb15
> 4/ Does it support pivots? Can't tell from the website or examples, red flag.
If you find an example I'd love to see it. My expectation at a bare minimum is a table view with a dimension down the left, a dimension across the top, and a measure in the cells. I looked through all the examples and did not see a clear example of a pivot.
> 5/ Can I model joins? [EDIT] it cant, see reply
It can't. https://news.ycombinator.com/item?id=15446616
> 6/ Does it support dashboard-wide filters? Many examples of this in the gallery
Most of the examples in the gallery use this feature.
> 7/ Does it support complex time comparisons? No examples, red flag.
Here's a couple very basic examples of what I'm talking about.
- Plug an TY date range into the dashboard filter.…
For anyone else who is a Google Cloud Customer. I 100% recommend "Exporting Billing Data to BigQuery" [1]. This takes less than 5 minutes and will give you near real-time extremely detailed billing data into BQ where you can explore it via SQL. Second, generate a real-time report off this data with something like "Visualize GCP Billing using BigQuery and Data Studio" [2].
That blog post is good, but it is over built in my opinion, all you really need is a single daily sum of all spend across your account and chart that. Maybe a stacked column with product color or something. This will allow you to quickly see if one product consumption is shooting up unexpectedly at a glance vs checking something at the end of the month and working with your account reps to figure something out.
6k z z
5k z z
spend 4k z z z
3k z z z
2k x x x x x x x x x
1k x x x x x x x x x
date 1 2 3 4 5 6 7 8 d+
x = expected
z = unexpected
For example, maybe you left a test env running or something and all of the sudden you're spending an extra few K per day. Maybe you're doing some query loops over a large BQ dataset and racking up tons of $$. Put the chart up on your big TV screen in the Ops area so everyone can quickly check it with all your other metrics. When you're spending 100k+/month, with a few folks digging around the console, it's hard to notice an extra 5k-10k here or there. This quick tip will…
It is more like RAID0. VictoriaMetrics shards time series among available vmstorage nodes. I.e. each vmstorage node contains a part of data stored in the cluster. This is usually named shared nothing architecture [1].
As for data replication, VictoriaMetrics offloads this task to the underlying storage, since the replication is hard to make properly [2]. Proper replication must be able to perform the following tasks additionally to copying the data to multiple nodes:
* To heal the data (aka to return back replication factor) after a node becomes permanently unavailable. The healing process mustn't degrade cluster performance and it must properly handle other cases mentioned below.
* To gracefully handle temporary unavailability of nodes.
* To survive network partitioning when nodes are temporarily split into multiple isolated subnetworks.
* To handle data corruption.
* To continue accepting new data at normal rate when a part of nodes are unavailable.
* To continue serving incoming requests with acceptable latency when a part of nodes are unavailable.
* To replicate data among multiple availability zones (AZ), so the cluster should continue accepting new data and serving requests if a single AZ becomes unavailable.
I'm unsure whether popular systems that claim replication support can handle all the cases mentioned above. The only system that seems to handle these cases properly is GCP persistent disks based on Colossus storage [3]. That's why it is recommended…
It depends on the language you're using and how you manage your dependencies.
If you're using Java, see this writeup for how different frameworks can affect startup time:
https://medium.com/google-cloud/java-frameworks-performances-on-cloud-run-eb243fd84a5c
Similarly, if you're using Node or Python, you might want to see if any of your dependencies are enormous with lots of files and slow startup time -- you can check this locally by timing how long it takes to get to the initial listen() call and just print that wall time as you adjust dependencies.
If you're building Golang and you're seeing slow cold starts... I have no idea how you're doing that. For development, a lot of us on the open source http://knative.dev/ side are using Go http servers that take tens of milliseconds to start up, so there's probably some other initialization that's slowing you down.
As a Googler who has a lot of technical content on Medium, I have to agree that screenshots are much more flexible than Medium's gist support, but I always add a link to the actual code right under.
For example: https://medium.com/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b
In this example, I have a single gist with multiple files, but Medium can't display just a single file from that gist at a time (maybe things have changed, but I don't think so).
Medium's gist and code support in general is sub-par compared to other platforms IMO, but as a platform it does make it easy to create and share content that is also easily discoverable.
I'm probably going to start hosting the canonical post on my own domain and just use Medium to syndicate it.
Interesting. I've done dual-writes at the application level to migrate the datastore for a smaller feature (branch by abstraction), but never for an entire application. And the code path was quite simple, so it was easy to think about all of the edge cases at one time in your head.
Do you have any resources which talk through the read/write/backfill approach?
Here's what I found so far:
* https://medium.com/google-cloud/online-database-migration-by-dual-write-this-is-not-for-everyone-cb4307118f4b
* https://aws.amazon.com/blogs/architecture/middleware-assisted-zero-downtime-live-database-migration-to-aws/