itcmcgrath

I can't upvote this enough. It also means it is easier for all internal people (not just tech writers or engineers) to make modifications (such as fixing typos, grammar, or adding missing context) safely and without needing to set up complicated tooling/tests or annoy people beyond review diffs+approval.

It does. It's not in the documentation because it doesn't have boundaries within the database.

It does, and has for several years.

DynamoDB is limited to 10 items, whereas the Cloud Datastore limits are 25 different 'tables' -> The new version via Cloud Firestore doesn't even have that restriction. AWS is several years behind and several NoSQL systems behind in this area. Still, a cool addition.

Note this is about Cloud Firestore, not Firebase RTDB. It's very different infra. We announced our beta limits increased to 1M concurrent connections at the Next 18 conference, and we'll continue to improve from there.

We've also been rolling out updates to rules to enable you to enforce these types of things. There is performance implications to limit queries for the real-time update system at scale, but for most use cases this shouldn't be a problem.

Definitely more we can improve here for control, and we're open to feedback.

Urgh, that's terrible! That definitely shouldn't be the case. I'd love for you to send me any support case you had so I can review.

Even if the front door of the system didn't help you, we definitely shouldn't have been able to get you in a good state much quicker. My profile has Twitter and my DMs are open (I can give you my email there too).

Doing my kids dinner, so responses might be slightly delayed.

Caps are definitely hard, getting them right as both a feature as well as setting them as a customer is still an art. This holds true for 'flat rate' too, where your trading correct sizing vs downtime when either get code wrong or get unexcepted success. I've been involved in all these situations so I definitely emphasize.

We had daily hard caps and budgets alerts, but it's still an area we can do better.

(Disclaimer: Product Manager for Cloud Firestore)

Product Manager for Cloud Firestore here. It's worth noting we do have the ability to set hard daily caps, as well as budgets that can have alerts tied to them. It's something we also looking at ways to improve it.

That's simply not true. Quotes superseded pluses and they definitely still work and it's trivial to demonstrate.

"mainframe" "kubernetes" vs mainframe kubernetes

https://www.google.com/advanced_search?hl=en&fg=1

I lot has changed in the last year or so, might be worth looking again. Most of the backend services are under GCP's terms of service, products like Cloud Firestore all do encryption at rest, etc.

Try Cloud Firestore, it has a lot of improvements with querying over the RTDB. I can also confirm sorting/querying is handled server-side. (Disclaimer: I'm the PM for it and use it for my own side-projects)

Add double quotes around the words, works like the old +word syntax.

(I don't work on Search, but use it a lot :))

Ctrl-F Evil, and it's still there.

"And remember… don’t be evil, and if you see something that you think isn’t right – speak up!"

It's the open source version of Redis v3.2.11

* Take Backup 1 which contains users A,B and C.

* User A requests to be deleted and is from prod.

* Deploy bad code between backup 1 and 2 - oh noes prod is corrupted!

* Restore backup 1, which restores user A

So - how doesn't this work for GDPR?

PM for Cloud Firestore here -> thanks for the feedback, we're working on getting to GA.

Feel free to email(dan + mcg at google), Twitter DM, etc more details about your cost concerns.

The quota change issue is complex, but yes we'd like to make it faster :)

It's worth noting that Google Cloud has its own terms of service that is very different from what you may be thinking of: https://cloud.google.com/terms/

Also, even Google's general consume terms of service really isn't what you think: https://www.google.com/policies/terms/

"You retain ownership of any intellectual property rights that you hold in that content. In short, what belongs to you stays yours."

Seems to be a common misconception. Look at EU Model Contract Clauses: e.g. https://cloud.google.com/terms/eu-model-contract-clause

I doubt that would be lower latency. Even forgetting the physics and curvature issues, you'll end up with many more hops which is going slow it down due to processing and retransmission delays.

TL;DR: Google created an open source version of the internal Census library. We use Census to monitor/debug systems at scale.

It's a single distribution of vendor-neutral libraries that automatically collects traces and metrics from your app, displays them locally, and sends them to any analysis tool (we currently have exporters for Zipkin, Prometheus, Datadog, Stackdriver, and Azure App Insights).

I think that's far from truth. It'll just be another issue that splits opinion.

Yes.

We deploy new code binaries all the time so it's not a big deal.

"Of course there's going to be less questions"

Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false

It doesn't, the authors are calling this out to limit the scope of linearizability to per-object. You're thinking about strict serializability.

The authors mention that transactions can be implemented in a way to support this by including a first step to steal all objects needed by the transaction. I believe this would give you strict serializability at a global level, but does have trade-offs in needing to know all objects at the start of a transaction, and other implications on latency, etc from this step.

The authors also note they haven't implemented transactions yet.

Also worth noting that some of the extensions/optimizations, such as the mentioned 'locality adaptive object stealing optimization' won't work as described with multi-object transactions. I could see additional work to identify groups of objects, but this would be very workload specific and not suitable as a generic solution.

Our network definitely makes a big difference, but even we don't just use straight up vanilla Paxos.

Need some non holiday time to read this fully, but it's worth noting that aside from Spanner, Cloud Datastore (using Megastore tech) and Cloud Firestore (using the same tech as Cloud Spanner) all do Paxos across several data centers over a wide area and achieve millions non batched writes/second.

Sometimes it can be hard to tease out the true trade-offs in the systems as they don't get as detailed acknowledgement, but from a quick read it looks like tail latency will will be worse.

Improvements in consensus algos often have issues, correct implementation is hard, but it can make previously impossible things tenable which I find exciting.

Yet many non-relational systems do support ACID transactions across multiple resources. Just from Google there is Megastore, Cloud Datastore, Spanner, Cloud Firestore

Nice!

Will you be adding something like a categories tag?

Any initial feedback on using Cloud Firestore you'd want to share? [Good | Bad]