It's terrifying in a hacker/cool way. Making the wrong query, creating millions of rows, and sending possibly millions of requests to the LLM provider sounds risky. But I like it :)
Founder and CEO here. Great question. Right now, since you are linking MySQL files that means that all the extenions need to be GLPv2 or compatible license. In the future, we are hoping to have a stable SDK that is indepedent of the MySQL files so that if you run it out of process, that would give more licensing options to folks. There is a proof of concept of an out-of-process mode for the extensions in the alpha, but we haven't spent much time on proving it out.
With Bring-Your-Own-Media (BYOM), customers supply their own installation media and bring their SQL Server licenses to Amazon’s RDS Custom managed cloud service. RDS Custom for SQL Server is a managed database service which provides administrative access to the OS and DB configuration.
Thanks for the feedback. As the person that named both products, I can say we spent a ton of time debating this but we felt that the fact one is an enterprise file share and the other a document database service focused on mobile and web would mean very little conflict for customers. We will keep an eye on any customer confusion it might cause.
It explains why this is linguistically bad. Basically, a billion people on this planet don't distinguish between the l and r sounds, so for 1/6 of the planet, these names are identical.
Native Chinese speaker here. That post is comically wrong. For one thing, you don't pronounce either "file" or "fire" like "filer" or "firer" -- isn't English amazing ;) -- so there's no L/R sound in the first place for us to supposedly confuse.
I mean all of the following in the best possible way:
Perhaps also worth looking at the screenshot in the blogpost.
You have in there:
---
Datastore
Storage
Filestore
---
So, datastore is not storage, nor is filestore. What is it storage storing if not data or files? Why are files not data? I have no idea what should go where.
> We know folks need to create, read and write large files with low latency. We also know that film studios and production shops are always looking to render movies and create CGI images faster and more efficiently. So alongside our LA region launch,
So I couldn't create, read or write before without low latency? I thought this was already a feature of your other products
> we’re pleased to enable these creative projects by bringing file storage capabilities to GCP for the first time with Cloud Filestore.
For the first time? I couldn't store files before?
I'm not trying to be an arse, but I really don't get from this what the key difference is from everything else you offer.
> What is it storage storing if not data or files?
Objects. Cloud Storage is the S3 competitor.
> Why are files not data?
“Data” as in rows in a database. Like Dynamo.
Everything on a computer is data. The thing you’ve got to understand is that the terms we use, “objects”, “files”, “data” — these don’t refer to types of data, but rather to access paradigms for data. The semantics of their storage, indexing, mutability, etc.
An object is a blob of data named by a key, that you can retrieve entirely, or overwrite entirely, and where usually you automatically get a version history of old versions that have been overwritten that you can retrieve, with a cutoff for automatic GC.
“Data” is a structured tuple that a database knows how to index into, and sort by the columns of. You insert rows, update columns of rows by a key, or delete rows by a key.
“Files” are seekable streams where you can index anywhere into a file by position and then read(2) or write(2) data at that position, and where other clients can see those updates as soon as you sync(2), without needing to close(2) the file first.
All could be used to implement the other (S3 is implemented in terms of Dynamo rows holding chunks of object data, for example.) But each access semantics has use-cases for which it is an impedance match or mismatch.
Thanks for the explanation, the file/object/data difference makes sense.
> An object is a blob of data named by a key, that you can retrieve entirely, or overwrite entirely, and where usually you automatically get a version history of old versions that have been overwritten that you can retrieve, with a cutoff for automatic GC.
And yet they refer to the objects inside as "Files" and support seeking
I know this is just bikeshedding about names and terms but it feels confused.
I think some of the confusion in the list is because of the mix of generic and product naming.
Data can be stored in datastore. But also in "spanner" or "bigtable", which are not parts of "datastore", or in "SQL" which is a language. Object can be stored in the object store called "storage" which is also within an entire category itself called "storage". So there's "Storage" which is a group of all these kinds of stores, and "Storage" which is a very specific type of store.
I think its worth adding some additional phonetic context around this remark (I made a similar remark and my coworkers thought I was making a racist joke).
The reason native Japanese speakers struggle with "R" and "L" sounds is because they just have one phoneme to work with, which sounds (to a native English speaker) like a combination of "R", "L", and "D". If you aren't exposed to phonemes at a young age, it is difficult to expand your set later in life.
An analogous difficulty might exist for English speakers if a Chinese company came up with two product names which used the exact same sequence of syllables, but had "tonal" differences in pronunciation.
Similarly for Japanese, "file" is pronounced/written as "fairu" and "fire" as "faiyaa". If the service docs are translated, then they would look like (and sound as) difference names.
Not only is it confusingly similar to other storage products, but the abbreviations collide among all of them. GCF means how many different things now? (I always considered it to mean Google Cloud Functions - kind of an important product.) Don't underestimate the importance of these things. I can't even talk to my colleagues about your products without us all misunderstanding each other.
> I can say we spent a ton of time debating this but we felt that the fact one is an enterprise file share and the other a document database service focused on mobile and web would mean very little conflict for customers.
How about naming one as Cloud FileStore and other as Cloud DbStore?
Oh oh, it's already causing a lot of confusion. Just check the 70+ comments in this thread alone hating on the naming and professing their confusion and it's been out less than 12 hours... and that is from a self selecting very tech savvy audience. I think you've got a problem.
To be fair, I think “Filestore” in itself is a pretty descriptive name, and the real problem is the name “Firestore”. I can imagine the internal discussion when a bit like that as well, and here we have the result.
It's a clear blunt suggestion to get out of their bubble.
No one outside Google would hear that explanation and say "Yeah totally makes sense one of them is an enterprise file share and the other a document database service focused on mobile and web, crystal clear and very little confusion.".
What more do you want out of my comment for it to not be low effort? Write a 3 page essay about it carefully making a case based on peer reviewed scientific evidence?
To understand, what services got pulled? we have a very long deprecation policy and I can't think of anything that has been removed in the last couple of years.
Quick question. Which version of MySQL were you running? 5.6 is single thread on the slave and falls behind more easily. 5.7 gives you multiple threads and does a better job of keeping up.
Whichever the highest version offered in the second generation Google Cloud SQL offering as of November/December 2016. If 5.7 was available, I would have chosen that. I don't specifically recall though.
2) Google Cloud Platform has a 1 year deprecation policy, which would never happen with a product that so many companies and customer rely on (Google Reader had a small but passionate base)
To clarify on #2, are you saying that Google Cloud Platform in its entirety has a 1 year deprecation policy? Or that individual products within the platform have a 1 year deprecation policy? I'm not worried about Google deprecating the Storage service but that they could kill off the entire platform.
Also just wanted to say that I've been extremely happy with GCP thus far and all the services I've tried thus far have more features than RS. I really hope GCP is here for the long haul.
Sorry, for any product on GCP, there is a 1 year deprecation policy. GCP isn't going anywhere. See the comment about Snap and Diane Greene's involvement (she is an Alphabet board member).
There is real work to migrate you application to use Cloud Spanner. Your schemas and queries will work with some tweaking but we don't have ORM support at beta.
We are going to produce some additional collateral on migrating from popular RDBMS, but the Quizlet post is the best reference right now for migrating from MySQL.
We have released client libraries for Java, Go, Node and Python on Github, but we haven't used those clients to implement support for popular ORMs.
Basically, the open-source ecosystem will need to add support for these ORMs but we will contribute wherever we can to push these initiatives. If we get lots of demand for a specific ORM, we will look into doing something special for that.
Dumb question: Since strings are supported, couldn't you just store some JSON as a string? Or are you talking about supporting queries that involve parsing the JSON on the "server"?
I think the OP was saying "dumb question" as in "I have a dumb question" rather than "this is a dumb question". At least that's the context I inferred.
reply