Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Ben Handy

dblp:81/3648 · DBLP profile ↗
← Back
4ranked-venue papers
0as first author
0since 2021 · last 2018
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Databases, data management, data science and information retrieval · 4

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Databases, data mining, and information retrieval
4 papers
Distributed and cloud data management · 36% Database system architecture and tuning · 34% Query processing and optimization · 15%
Computer architecture, parallel and distributed computing, and storage systems
3 papers
Distributed systems · 76% Cloud and datacenter computing · 24%

Topics — the 9 heaviest of 11, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Distributed and cloud data management › federated database
federated query processing
0.312018
F1 Query: Declarative Querying at Scale · Proc. VLDB Endow. 2018
Information retrieval › web search
data freshness
0.212016
Shasta: Interactive Reporting At Scale · SIGMOD Conference 2016
Query processing and optimization
online query processing
0.212016
Shasta: Interactive Reporting At Scale · SIGMOD Conference 2016
Distributed and cloud data management › distributed database architecture
distributed relational database
0.212013
F1: A Distributed SQL Database That Scales · Proc. VLDB Endow. 2013
Distributed systems
replication and consistency
0.212013
F1: A Distributed SQL Database That Scales · Proc. VLDB Endow. 2013
Database system architecture and tuning
relational database system
0.112012
F1: the fault-tolerant distributed RDBMS supporting google's ad business · SIGMOD Conference 2012
Distributed systems
distributed database
0.112012
F1: the fault-tolerant distributed RDBMS supporting google's ad business · SIGMOD Conference 2012
Distributed and cloud data management › distributed query processing
distributed query engine
0.012013
F1: A Distributed SQL Database That Scales · Proc. VLDB Endow. 2013
Distributed and cloud data management
distributed data store
0.012012
F1: the fault-tolerant distributed RDBMS supporting google's ad business · SIGMOD Conference 2012

Methods — techniques the papers use, named apart from their topics

declarative querying · 0.7SQL · 0.7query transformation · 0.2join processing over many tables · 0.2
YearPublicationVenuePosition
2018 F1 Query: Declarative Querying at Scale
abstract
F1 Query is a stand-alone, federated query processing platform that executes SQL queries against data stored in different file-based formats as well as different storage systems at Google (e.g., Bigtable, Spanner, Google Spreadsheets, etc.). F1 Query eliminates the need to maintain the traditional distinction between different types of data processing workloads by simultaneously supporting: (i) OLTP-style point queries that affect only a few records; (ii) low-latency OLAP querying of large amounts of data; and (iii) large ETL pipelines. F1 Query has also significantly reduced the need for developing hard-coded data processing pipelines by enabling declarative queries integrated with custom business logic. F1 Query satisfies key requirements that are highly desirable within Google: (i) it provides a unified view over data that is fragmented and distributed over multiple data sources; (ii) it leverages datacenter resources for performant query processing with high throughput and low latency; (iii) it provides high scalability for large data sizes by increasing computational parallelism; and (iv) it is extensible and uses innovative approaches to integrate complex business logic in declarative query processing. This paper presents the end-to-end design of F1 Query. Evolved out of F1, the distributed database originally built to manage Google's advertising data, F1 Query has been in production for multiple years at Google and serves the querying needs of a large number of users and systems.
Bart Samwel, John Cieslewicz, Ben Handy, Jason Govig, Petros Venetis, Chanjun Yang, Keith Peters, Jeff Shute, Daniel Tenedorio, Himani Apte, Felix Weigel, David Wilhite, Jiexing Li, Zhan Yuan, Craig Chasseur, Ian Rae, Anurag Biyani, Andrew Harn, Andrey Gubichev, Amr El-Helw, Orri Erling, Zhepeng Yan, Mohan Yang, Yiqun Wei, Thanh Do, Colin Zheng, Goetz Graefe, Somayeh Sardashti, Ahmed M. Aly, Divyakant Agrawal, Shivakumar Venkataraman
Proc. VLDB Endow.3
2016 Shasta: Interactive Reporting At Scale
abstract
We describe Shasta, a middleware system built at Google to support interactive reporting in complex user-facing applications related to Google's Internet advertising business. Shasta targets applications with challenging requirements: First, user query latencies must be low. Second, underlying transactional data stores have complex "read-unfriendly" schemas, placing significant transformation logic between stored data and the read-only views that Shasta exposes to its clients. This transformation logic must be expressed in a way that scales to large and agile engineering teams. Finally, Shasta targets applications with strong data freshness requirements, making it challenging to precompute query results using common techniques such as ETL pipelines or materialized views. Instead, online queries must go all the way from primary storage to user-facing views, resulting in complex queries joining 50 or more tables.
Gokul Nath Babu Manoharan, Stephan Ellner, Karl Schnaitter, Sridatta Chegu, Alejandro Estrella-Balderrama, Stephan Gudmundson, Apurv Gupta, Ben Handy, Bart Samwel, Chad Whipkey, Larysa Aharkava, Himani Apte, Nitin Gangahar, Shivakumar Venkataraman, Divyakant Agrawal, Jeffrey D. Ullman
SIGMOD Conference8
2013 F1: A Distributed SQL Database That Scales
abstract
F1 is a distributed relational database system built at Google to support the AdWords business. F1 is a hybrid database that combines high availability, the scalability of NoSQL systems like Bigtable, and the consistency and usability of traditional SQL databases. F1 is built on Spanner, which provides synchronous cross-datacenter replication and strong consistency. Synchronous replication implies higher commit latency, but we mitigate that latency by using a hierarchical schema model with structured data types and through smart application design. F1 also includes a fully functional distributed SQL query engine and automatic change tracking and publishing.
Jeff Shute, Radek Vingralek, Bart Samwel, Ben Handy, Chad Whipkey, Eric Rollins, Mircea Oancea, Kyle Littlefield, David Menestrina, Stephan Ellner, John Cieslewicz, Ian Rae, Traian Stancescu, Himani Apte
Proc. VLDB Endow.4
2012 F1: the fault-tolerant distributed RDBMS supporting google's ad business
abstract
Many of the services that are critical to Google's ad business have historically been backed by MySQL. We have recently migrated several of these services to F1, a new RDBMS developed at Google. F1 implements rich relational database features, including a strictly enforced schema, a powerful parallel SQL query engine, general transactions, change tracking and notification, and indexing, and is built on top of a highly distributed storage system that scales on standard hardware in Google data centers. The store is dynamically sharded, supports transactionally-consistent replication across data centers, and is able to handle data center outages without data loss.
Jeff Shute, Mircea Oancea, Stephan Ellner, Ben Handy, Eric Rollins, Bart Samwel, Radek Vingralek, Chad Whipkey, Beat Jegerlehner, Kyle Littlefield, Phoenix Tong
SIGMOD Conference4