Showing entries 1 to 4
Displaying posts with tag: Uber (reset)
Peloton: Uber’s Unified Resource Scheduler for Diverse Cluster Workloads

Cluster management, a common software infrastructure among technology companies, aggregates compute resources from a collection of physical hosts into a shared resource pool, amplifying compute power and allowing for the flexible use of data center hardware. At Uber, cluster management …

The post Peloton: Uber’s Unified Resource Scheduler for Diverse Cluster Workloads appeared first on Uber Engineering Blog.

Databook: Turning Big Data into Knowledge with Metadata at Uber

From driver and rider locations and destinations, to restaurant orders and payment transactions, every interaction on Uber’s transportation platform is driven by data. Data powers Uber’s global marketplace, enabling more reliable and seamless user experiences across our products for riders, …

The post Databook: Turning Big Data into Knowledge with Metadata at Uber appeared first on Uber Engineering Blog.

Percona Live Featured Session with Casper Kejlberg-Rasmussen: Placing Databases @ Uber

Welcome to another post in the series of Percona Live featured session blogs! In these blogs, we’ll highlight some of the session speakers that will be at this year’s Percona Live conference. We’ll also discuss how these sessions can help you improve your database environment. Make sure to read to the end to get a special Percona Live 2017 registration bonus!

In this Percona Live featured session, we’ll meet Casper Kejlberg-Rasmussen, Software Developer at Uber. His session is Placing Databases @ Uber. Uber has many thousands of MySQL databases running inside of Docker containers on thousands …

[Read more]
Choosing Whether to Migrate to Another Database: Uber

Uber Engineering explains the technical reasoning behind its switch in database technologies, from Postgres to MySQL: https://eng.uber.com/mysql-migration/

These things are always an interesting read, because it looks at one company’s decision making process and operational steps.

At Open Query we’re not a fan of migrations – it doesn’t matter from what brand to what brand, migrations tend to be expensive and painful.  Any application tends to be more suited to a particular brand – because of design and implementation choices. This is neither good nor bad, it’s just a fact that has to be acknowledged when considering these things.

Similarly, infrastructure (what hardware there is and how it’s set up and connected) tends to be dependent on the brand choice, as different databases have different needs in that space, …

[Read more]
Showing entries 1 to 4