31–39 of 39 posts
Still blows my mind that it took Uber so long to migrate away from a single db solution. The bit about wanting an event system to handle downstream trip processing w/o having one failure block the whole job was shocking. I’m all for avoiding premature optimization but this was taken to the extreme. PostgreSQL is capable of all of this out of the box. Wonder why a custom tool was built instead?
I wish I had video of the faces I was undoubtedly pulling, during the few seconds I spent puzzling out the pronunciation and meaning of the word "Schemaless". /Shema-leez/ ? /Szhee-males/ ? Naming products is demonstrably a hard problem.
Still blows my mind that it took Uber so long to migrate away from a single db solution. The bit about wanting an event system to handle downstream trip processing w/o having one failure block the whole job was shocking. I’m all for avoiding premature optimization but this was taken to the extreme. PostgreSQL is capable of all of this out of the box. Wonder why a custom tool was built instead?
They have over-hired engineers is the obvious answer.
Earlier quoted context omitted.
> Does MySQL not have a TEXT data type It does, but it's still length limited--more precisely, there are several different TEXT data types, with different length limits. This bit me recently on a project, where I was sending strings over the length limit to a TEXT field and wondered why they got truncated until I read the spec more carefully.
does the new json storage not re-use mysql's TEXT storage? It is stored directly on the data pages? But then it would be limited in length, or does it use something else entirely?
[1] https://dev.mysql.com/doc/refman/8.0/en/storage-requirements...
so, has anyone ever pointed out that 'Schemaless' looks like how a spammer would spell 'shemales'?
I'm serious, yo, I bet these guys will have all kinds of issues trying to set up a newsletter. Also gmail might start serving up ads for expertsexchange.com
Earlier quoted context omitted.
> MySQL's 'utf8' encoding, perversely, supports only a subset of utf8 and will break if you try to write an emoji. Almost every programming platform makes the same mistake. Characters outside of the basic multilingual plane (i.e., characters taking more than two bytes to store) will break certain string functions. It's due to using (fixed length) ucs2 for in-memory storage, instead of variable-length utf8. Imagine, f…
Well, sort of. Java and Javascript use 2-byte strings in memory, yet both can represent an emoji just fine. (They do so via a hack that uses multiple indices in a String to represent a single character. If you want to go down the rabbit hole of how much this sucks, check out the MDN pages for charCodeAt vs codePointAt ...) Modern languages like Go just represent strings as UTF8 in memory. This has lots of advantages:…
Earlier quoted context omitted.
does the new json storage not re-use mysql's TEXT storage? It is stored directly on the data pages? But then it would be limited in length, or does it use something else entirely?
From the documentation[1], it looks like the underlying storage requirement is similar to what would be required to store the string representation of the JSON in a TEXT-type field; however, unlike TEXT fields, there is no length limit other than the global system variable max_allowed_packet (which defaults to 4 MB). [1] https://dev.mysql.com/doc/refman/8.0/en/storage-requirements...
Earlier quoted context omitted.
From the documentation[1], it looks like the underlying storage requirement is similar to what would be required to store the string representation of the JSON in a TEXT-type field; however, unlike TEXT fields, there is no length limit other than the global system variable max_allowed_packet (which defaults to 4 MB). [1] https://dev.mysql.com/doc/refman/8.0/en/storage-requirements...
max_allowed_packet seems like it would limit the length of any internal string, so maybe it would bound the max length of any individual json field contents?