itcmcgrath

German goes into some of the details here: https://neo4j.com/blog/graph-database/property-sharding-infi...

* >20 when this was published in 2016.

The most important part is at the end:

According to Agnieszka Grabska-Barwinska, a member of the team, the graph neural network learned to encode a pattern that physicists call correlation length. That is, as DeepMind’s graph neural network restructured itself to reflect the training data, it came to exhibit the following tendency: When predicting propensities at higher temperatures (where molecular movement looks more liquid-like than solid), for each node’s prediction the network depended on information from neighboring nodes two or three connections away in the graph. But at lower temperatures closer to the glass transition, that number — the correlation length — increased to five.

“We see that the network extracts, as we lower the temperature, information from larger and larger neighborhoods” of particles, said Thomas Keck, a physicist on the DeepMind team. “At these different temperatures, the glass looks, to the naked eye, just identical. But the network sees something different as we go down.”

Increased correlation length is a hallmark of phase transitions, in which particles transition from a disordered to an ordered arrangement or vice versa. It happens, for instance, when atoms in a block of iron collectively align so that the block becomes magnetized. As the block approaches this transition, each atom influences atoms farther and farther away in the block.

My favorite so far: https://captcha.nsa.gov/logos/2019/loteria/rc2/loteria19.htm...

It was 2015 when I first encountered this while working with Andrew and James. I couldn't find any online info on the origin, and the few Firebasers I asked couldn't tell me. I feel like I have closure now that it really wasn't a thing. Or, I guess it was and it really is now.

It's funny how little things can snowball.

Only 89 (it wasn't KFC). But yes; common pattern.

I've been around a company that was 180+ years old (so rebranding was non-trivial ;)). They switched to an acronym based on the original name, so there was was 1) a direct link between old and new, 2) old branded tgat was mussed wasnt a big deal for bew customers, and 3) everyone called it by the acronym going forward.

A similar approach might work for you and allow an incremential phase out of the old brand over time. Instead of HxHxHx, it's now HITD (HxHxHx IT Desktop)

One example would be where you have conditional logic that requires a database call. Without workers, everything would go back to the backend system, perhaps across the ocean. With workers in front you could shortcircuit that for all calls that don't require the DB call. You could also handle routing logic at that layer, allowing it to pick closer DB instances, etc.

[Disclaimer: Product Manager on Cloud Firestore who thought this was an interesting use-case]

Status board is green: https://status.salesforce.com/ But reports of log-in issues are slightly up: https://downdetector.com/status/salesforcecom

We listed a sample in the blog post, including The Telegraph, The New York Times, Skip Scooters, Now IMS, and Hawkin Dynamics

Thank you for being a paying user.

1. Mainly because it's both a different search problem (general DB vs specific to web search) and hard engineering wise given our model; we implement not only the cloud database, but embedded versions for iOS, Android, and Web - not to mention real-time functionality and tailoring it to how our index engine works, etc. While we have a lot of customers and use-cases that don't need Fulltext Search, we totally agree it's important and have done explorations on how we'd deliver something along these lines.

2. Agreed. During the beta program we've delivered the managed export and import service for backups, adding array contains capabilities to queries and have got close enough to delivering Collection Group queries to mention them as part of GA. For documentation our tech writing team as done a lot of updates, new pages, and fixes - we know there is always more to do. Cloud Firestore is definitely used in production and at scale by our customers, and with nearly 1 million databases being created the range of use cases and traffic/load patterns has been vast. Our beta program involved working with a lot of them to improve things like hardening and scalability to ensure we can meet our 5 nines of availability SLA.

"Isn't half a solution better than no solution?" -> In a lot of cases, absolutely not. A half solution that falls over when you tip a certain point of scale can result in extended downtimes, since the solution often ends up being "we need to completely rearchitect this", which isn't easy or quick when your business is out of commission.

"from the perspective of a customer and outside observer, a number of things smell quite off." -> Sorry to hear this, I can only hope the continued hard work from the team will turn you around.

If Cloud Spanner is too big, then you'll almost certainly be well served by Cloud SQL (fully managed MySQL and PostgreSQL): http://cloud.google.com/sql/

We built it specifically for Cloud Firestore and as an integral part of the system from the beginning. We always like to hear where we can do better to help prioritize the next set of improvements, and would love to know what gives you the impression of being bolted on.

If you want a scalable relational database, that's Cloud Spanner.

We aren't, but we know customers to create GraphQL access layers themselves.

Thanks for the feedback. Feel free to send any feedback on missing examples/tutorials that would have made things easier to our discussion group (https://groups.google.com/forum/#!forum/google-cloud-firesto...). Our tech writers see the feedback and use it to help plan their work.

Thanks! It's something we're discussing, but won't be "soon".

Our discussion group has a lot of the team, including me, on it: https://groups.google.com/forum/#!topic/google-cloud-firesto...

We're looking at more comprehensive backup solutions, but in the meantime we have a fully managed export system you can schedule (https://cloud.google.com/firestore/docs/manage-data/export-i...) with the added benefit of this exports being importable into BigQuery for ad-hoc analytics (https://cloud.google.com/bigquery/docs/loading-data-cloud-fi...)

I'll talk to our Developer Relations team in Colorado to follow up!

Hi EZ-E - completely understand the concern. Cloud Firestore's architecture is very different and engineered to be an extremely highly available system backed by a 5 nines SLA. It has no scheduled downtime either.

It's technically possible for us to build that, but we're focusing on the most common requests at this time. If anyone has that please let your account reps know (they feed us lots of great feedback for prioritization), or start a discussion on our Google Group: https://groups.google.com/forum/#!forum/google-cloud-firesto...

None, still a fully supported option for users.

Yes, it runs on racks of Google Pixel devices rather than servers. (I jest)

It's a point of internal discussion on scalable ways to achieve this, but nothing we can promise. We definitely see the need for it.

Cloud Firestore supports HIPAA compliance, we are working to update the documentation here: https://cloud.google.com/security/compliance/hipaa/#covered-...

This isn't true, but Cloud Spanner is awesome too!

Product manager for Cloud Firestore here. We extremely grateful for all the amazing beta program customers and all the feedback they've given us.

A cube 55 meters on a side, not 55 cubic meters. That's a huge difference: 166K+ cubic meters

Look up Case Folding for how this is done, most languages have libraries to handle it.