Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
1–10 of 39 posts
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#2This was discussed here 2 years ago.
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#3Summary:
> We ended up building a key-value store which allows you to save any JSON data without strict schema validation, in a schemaless fashion (hence the name). It has append-only sharded MySQL with buffered writes to support failing MySQL masters and a publish-subscribe feature for data change notification which we call triggers. Lastly, Schemaless supports global indexes over the data.
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#4[deleted]
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#5Can this have a 2016 added to it, please?
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#6And it still needs a different name.
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#7This was discussed here 2 years ago. https://news.ycombinator.com/item?id=10894047
Indeed discussed 4 times before https://hn.algolia.com/?query=schemaless%20datastore%20mysql...
This also should be titled "(2016)"
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#8pronounced "she-males"
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#9Summary: > We ended up building a key-value store which allows you to save any JSON data without strict schema validation, in a schemaless fashion (hence the name). It has append-only sharded MySQL with buffered writes to support failing MySQL masters and a publish-subscribe feature for data change notification which we call triggers. Lastly, Schemaless supports global indexes over the data.
Let’s also not be smug, let’s explain for everyone who comes here: why is this good or why is it bad. So describe why this is good or describe why it’s bad
That comment was edited with more info...
Re: Designing Schemaless, Uber Engineering’s Scalable Datastore Using MySQL (2016)
#10Still 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?