3 ms·
Yes, you're right about the need for many flat tables specific to each vertical. However, if other aspects of these verticals need to be specific to the vertica
by geuszb 8y ago
Yes, you're right about the need for many flat tables specific to each vertical. However, if other aspects of these verticals need to be specific to the vertical anyway (for example, UI: weather for the week is presented differently than a list of movies and their ratings; or: data quality), then there's still a significant amount of eng work per vertical, so that data flattening step may not be the bottleneck in growing the number of verticals served...
- mrjn 8y agoThat was the exact issue Google found itself in. Every OneBox had their own backend, which meant many different teams were involved in running and maintaining them. Now, with the graph serving system in place, all they need to do is to slap a new UI for the vertical, while the backend remains the same. Of course, there's real effort involved in building a new UI for the vertical, but it's a lot smaller compared to building a whole stack for each vertical. Not to mention, just the movie vertical itself has many "types" of data. Movies, Actors, Directors, Producers, Cinematographers, etc. -- all of these have different properties. By the time one is done flattening all of these into relational tables, they've built a custom graph solution -- which is what happens repeatedly in companies.
- geuszb 8y agoThat makes sense... Though after reading the article, I thought Google wasn't using a system that supported arbitrary join depths?