dbTouch: Analytics at your Fingertips

1 . dbTouch: Analytics at your Fingertips Stratos Idreos† Erietta Liarou † CWI, Amsterdam EPFL, Lausanne stratos.idreos@cwi.nl erietta.liarou@epfl.ch ABSTRACT 1. INTRODUCTION As we enter the era of data deluge, turning data into knowl- The Big Data Era. Turning data into knowledge has edge has become the major challenge across most sciences become an essential need for businesses and sciences. As and businesses that deal with data. In addition, as we in- more data is generated, knowledge hides better within the crease our ability to create data, more and more people are “pile of big data”. With several innovative ideas, systems confronted with data management problems on a daily basis and research directions, the database community is making for numerous aspects of every day life. A fundamental need strong steps towards dealing with the new challenges of big is data exploration through interactive tools, i.e., being able data across several data management areas. For example, to quickly and effortlessly determine data and patterns of recent highlights include research on databases that exploit interest. However, modern database systems have not been the map reduce and the cloud paradigms [1, 12, 34, 2, 38, designed with data exploration and usability in mind; they 32], database kernels for approximate query processing [3, require users with expert knowledge and skills, while they 31, 40], adaptive indexing [26, 27, 28, 18, 16, 29], adaptive react in a strict and monolithic way to every user request, data loading [24, 4], high performance column-store [43, 8, resulting in correct answers but slow response times. 25] and hybrid database kernels [6, 30, 11, 17, 13], crowd- sourcing [35, 15, 39, 14] and anthropocentric systems [44], In this paper, we introduce the vision of a new generation of exploitation of modern hardware [20, 10, 36, 7], usability [37] data management systems, called dbTouch; our vision is to and energy aware systems [21, 33]. Still though, the big data enable interactive and intuitive data exploration via data- era poses several more unique challenges and opportunities. base kernels which are tailored for touch-based exploration. No expert knowledge is needed. Data is represented in a Interactive Data Exploration. Here, we propose a novel visual format, e.g., a column shape for an attribute or a research direction to address one of the most critical data fat rectangle shape for a table, while users can touch those management needs today, namely data exploration [9], i.e., shapes and interact/query with gestures as opposed to firing when we are in search for interesting patterns often not complex SQL queries. The system does not try to consume knowing a priori exactly what we are looking for. For exam- all data; instead it analyzes only parts of the data at a time, ple, an astronomer wants to browse parts of the sky to look continuously refining the answers and continuously reacting for interesting effects, while a data analyst of an IT business to user input. Every single touch on a data object can be browses daily data of monitoring streams to figure out user seen as a request to run an operator or a collection of opera- behavior patterns. What both cases have in common is a tors over part of the data. Users react to running results and daily stream of big data, i.e., in the order of multiple Ter- continuously adjust the data exploration - they continuously abytes and the need to observe something interesting and determine the data to be processed next by adjusting the di- useful. The vision of interactive data exploration aims to rection and speed of a gesture, i.e., a collection of touches; allow for instant access to the data, i.e., without expensive the database system does not have control on the data flow initialization steps, while at the same time allowing the user anymore. We discuss the various benefits that dbTouch sys- to extract knowledge from the data by selectively and inter- tems bring for data analytics as well as the new and unique actively investigating only parts of the data. challenges for database research in combination with touch interfaces. In addition, we provide an initial architecture, Vision: dbTouch. Our vision towards interactive data implementation and evaluation (and demo) of a dbTouch exploration is to bring together core database research and prototype over IOs for IPad. touch-interfaces, i.e., to enable users to touch and manipu- late data in intuitive ways in search for interesting patterns. We capture the new category of such systems and research under the title dbTouch systems. This article is published under a Creative Commons Attribution License We propose to rethink database kernel designs towards ar- (http://creativecommons.org/licenses/by/3.0/), which permits distribu- chitectures tailored for touch-based data exploration. tion and reproduction in any medium as well allowing derivative works, provided that you attribute the original work to the author(s) and CIDR 2013. In a dbTouch system, data is visualized in various shapes 6th Biennial Conference on Innovative Data Systems Research (CIDR ’13) and forms, while users can interactively explore the data January 6-9, 2013, Asilomar, California, USA. 

2 .via touch input. For example, an attribute of a given table The interactive and continuously changing mode in dbTouch may be represented by a column shape. Users are able to is drastically different than what state-of-the-art database apply gestures on this shape to get a feeling of the data systems support; it requires rethinking of core algorithms, stored in the column, i.e., to scan, to run aggregates on part while new concepts arise when it comes to interactive query of the data, or even to run complex queries. processing. In traditional systems, once a query is posed, the database controls the data flow, i.e., it is in full control The fundamental concepts of query, query plan and data regarding which data it processes and in what order, such flow are redefined. The user touch, the gesture evolution, as to compute the result to the user query. In dbTouch, i.e., the speed and the direction of the gesture, determine however, these concepts are blurred. In dbTouch, a query the data to be processed next and the actions that need to is a session of one ore more continuous gestures and the be performed. The system does not try to consume all data; system needs to react to every touch, while the user is now instead, it analyzes only parts of the data at a time, continu- in control of the data flow. ously refining the answers and continuously reacting to user input. Every single user touch on a data object can be seen In addition, other than translating gestures to database al- as a request to run an operator or a collection of operators gorithms, there are numerous optimization issues that ap- over a part of the data. At the same time, as a gesture, i.e., pear in dbTouch. For example, when a user slides a finger a collection of touches, evolves and varies in direction and over a column with a varying slide speed, then we would like speed, users can determine the data they need to analyze, to find a good way and timing to extrapolate the gesture reacting to intermediate results as they appear on screen. movement and to efficiently access, prefetch and precom- The database system does not have control anymore on the pute the anticipated data to avoid stalling once the query data flow. session resumes or when it moves faster. The vision is that through the integration of touch gestures Exploiting dbTouch. A dbTouch system is primarily meant and database kernels we enable new ways for users to have to work as an exploration tool, i.e., to speed up understand- a quick look and feel of their data in a natural and interac- ing of data. For example, a user may choose to load a small tive way. At the same time, new challenges arise for touch- data sample directly on a tablet mobile dbTouch system or oriented database architectures. use the tablet as an interface to a cloud based dbTouch sys- tem over the complete data set. Touch Input. Touch interfaces have already had a tremen- dous impact at mobile computing. They literally trans- Contributions. Our contributions are as follows. formed the industry during the past 5 years, starting with Apple’s IOs in 2008 and following up with Android from Google, Windows 8 from Microsoft and webOS from Palm 1. We introduce the vision of dbTouch systems for inter- (now HP). Although some were skeptic during the initial active touch-based data exploration. stages, the immediate and wide adoption of mobile touch 2. We introduce algorithms and functionalities for several based platforms clearly shows the huge potential. The key basic gestures such as single finger slide to scan or to element is the simplicity and the interactive nature of touch run aggregates, two fingers zoom-in to progressively interfaces which result in two fundamental side-effects; (a) get more detailed samples of data, rotate to switch the more people use and interact with touch interfaces, i.e., peo- physical design from row-store to column-store, etc. ple that are not necessarily very familiar with other forms of computing and (b) new kinds of applications appear. This 3. We identify several optimizations, challenges and op- is exactly the same trend we want to achieve with dbTouch. portunities in dbTouch systems such as storing and ac- Imagine the simplicity of sliding a finger over a rectangle cessing data in several granularities, prefetching data shape, representing a table on a touch tablet, to scan or to and precomputing results during gestures, incremen- run aggregates over the table instead of trying to figure out tally changing the storage layout, etc. the schema and to write SQL queries in text mode. 4. We provide the first implementation, evaluation and From Gestures to Query Processing. Naturally, the demo of an early prototype dbTouch system over IOs dbTouch direction creates new research opportunities both for IPad. in the area of database architectures and in the area of visu- alization. From a database researcher’s point of view there are several fundamental questions to answer. Most critical Outline. The rest of the paper is organized as follows. questions have to do with how we translate touch gestures Section 2 discusses the dbTouch vision in more detail along to database query processing algorithms/operators, i.e., how with descriptions of an initial set of gestures and operators does dbTouch react in terms of storage and access patterns for data exploration as well as optimization issues and prob- when we slide a finger or when we zoom-in with two fingers lems that arise when designing an early dbTouch prototype. over a column or a table? What is the equivalent of a query? Section 3 discusses implementation details and an early eval- Several challenges arise. For example, when sliding a finger uation of a prototype over IOs for IPad. Then, Section 4 to scan or to run an aggregation over a column, users may discusses new opportunities and research directions opened choose to slide faster or slower or change the slide speed nu- by the dbTouch vision. Section 5 discusses related work merous times or even pause for some time, while they are and Section 6 concludes the paper. Finally, Appendix A observing the running results. discusses a demo proposal. 

3 .2. DBTOUCH This section gives more details on the dbTouch vision such Slide single finger Two finger zoom-in over a column to scan. over a column. as what is the desired behavior and functionality. We discuss Results appear as See next level of detail several topics one has to address when designing dbTouch the slide progresses. in sample data. systems such as data and result visualization, mapping of touch to data, query processing via slide gestures, optimiza- tions to enable quick reaction to touch input, data storage Two finger zoom-out and access options and optimizations as well as formulation over a column. See previous level of Rotate table. of complex queries. detail in sample data. Change physical design from column-oriented to row-oriented 2.1 Interactive Exploration One of the main requirements when inspecting data is to get a quick feeling regarding the quality of the data and possible Figure 1: Examples of dbTouch gestures. patterns and properties. Not necessarily all data is required at this stage, while at the same time this is not an exact science; it involves a lot of intuition from the analyst which is why many people claim that (big) data analysis is a kind a height of only a few centimeters may represent an attribute of art [19]. In this way, the key goal of dbTouch is to assist in a table with several millions of tuples. The actual data users with data exploration. become visible only during query processing, i.e., by apply- ing one or more gestures on a data object. As we discuss In order to promote data exploration, a dbTouch system later on, the fact that a small object represents many tuples needs to provide an interactive feeling to the user, i.e., giving has implications on data storage and data access options the illusion that the user is indeed “touching the data” in when designing a dbTouch kernel for data exploration. real time. This increases user satisfaction and ease of using the system. To achieve this goal, dbTouch actions should dbTouch in Action. A snapshot of our dbTouch proto- not be monolithic actions that consume big piles of data type in action is shown in Figure 2. In general, several ob- at a time, resulting in significant delays in response times. jects may be visible at any time, representing data (columns Instead, they should be incremental and adaptive actions and tables) stored in the database. The user has the option that can give quick results back to the user. In turn, users to touch and manipulate whole tables or to visualize and react to those results and adjust their gestures accordingly, work on the columns of a table independently for more fine effectively promoting interactive data exploration through grained access and analysis. In the example of Figure 2, the the continuous interaction of the user with base data and user sees three columns of the same table, each one visual- results produced. ized as a separate rectangle and with a different color. In the right hand-side screen-shot of Figure 2 the user has ap- The above goal of interactive data exploration requires a plied a zoom-in gesture over the blue data object for a more combination of both low level query processing actions and fine grained exploration on this column. visualization techniques for properly visualizing data and intermediate results. Good query processing techniques im- Schema-less Querying. Contrary to traditional database prove the response times of the system when reacting to user systems, in a dbTouch system users do not need to know requests (gestures), while good visualization techniques im- the database schema. The various data objects convey the prove the response time of the user when reacting to results schema information at a high level, giving a glimpse to the produced by the system. user regarding what kind of data is available for exploration; just by glancing at the touch screen, users can immediately 2.2 Front-end know how many tables and columns exist. Applying query We begin our description of dbTouch systems by discussing processing gestures is possible without any further knowl- the front-end part of the system, i.e, what users experience edge. Discovering the schema in more detail is part of the and what they expect when interacting with a dbTouch sys- exploration process. For example, a single tap anywhere on tem. This is drastically different than the standard SQL a column data object reveals a single column value, allowing interfaces and impacts design decisions for the underlying to easily recognize the data type of the column. The exact dbTouch kernel. value that appears depends on the exact location touched (to be discussed later on). Similarly, a single tap anywhere Data Objects. The main interaction of a user with a on a table data object reveals a full tuple, allowing to eas- dbTouch system comes by interacting with data objects. Ob- ily recognize what kind of attributes are contained in this jects appear on the touch screen, while a user can apply table. As we discuss later on, users can break down tables gestures on these objects. For simplicity and ease of pre- into a several single columns or groups of columns, affect- sentation, in the rest of this section, we assume one of the ing the underlying storage. Other important properties such most straightforward visualization options for data objects, as attribute and table names as well as foreign key relation- i.e., data appear in a relational-like way; tables are repre- ships between tables can be visualized on demand or perma- sented as (fat) rectangles and attributes are represented as nently depending on user preference. Overall, contrary to columns. For example, Figure 1 shows several examples of traditional systems, exact schema information in a dbTouch column representations and gestures. Data objects are ab- system is less important to the user; one simply needs to stract representations of the data. For example, in Figure 1 look at the screen for a column or table which might be we see that the actual data is not visible. A single column of interesting and start touching it. 

4 .Figure 2: Screen-shot of dbTouch during an interactive scan via a slide gesture. Before (left side) and after (right side) a zoom-in gesture on the column represented by the blue object. Visualizing Data. Naturally, the kind of visual represen- Query Processing. Contrary to traditional systems, query- tation used can vary. Here, we use a simple, relational-like, ing dbTouch is not a monolithic action; not all data are pro- representation to introduce the dbTouch vision but other cessed in dbTouch, while query processing may stop at any options are definitely worth studying and may better match time. The points touched by the user define the data to be certain data sets depending on the application. This issue processed. Users do not declare a query, then pose it and is discussed more in Section 4. then wait for an answer. Instead, users define the query they wish to run by choosing a few query actions (say an 2.3 Slide to Explore scan or an aggregate for simplicity) and then they start a Having discussed how data is visualized, we now continue slide gesture over a column or a table. to describe how one can start exploring the data via simple gestures. In analogy with traditional database kernels, the slide ges- ture is equivalent to the next operation where an operator Slide. The main query processing gesture in dbTouch is requests the next tuple to process. The difference is that the slide gesture. It brings several opportunities as well as instead of having a predefined plan on how to go through several optimization problems regarding both data storage the data, now the users are the ones who trigger those next and data access decisions when designing a dbTouch sys- actions. They do so at a varying speed and with the op- tem. The upper left part of Figure 1 depicts an example tion to go back and forth over the same data areas or even of the slide gesture; the idea is that a user slides a single pause and begin again from an arbitrary data entry; now finger over a data object to point at data to be processed. users have full control on the data flow of what would be In fact, a slide gesture is a collection of several single touch the equivalent of a query plan in a traditional system. actions. dbTouch reacts to every single touch and processes data continuously as the gesture evolves. There are no re- Slide Example. Figure 2 shows a slide gesture in action strictions on how long a slide gesture lasts or on what is the in our dbTouch prototype. The gesture is applied on the start and the end point of the gesture. In addition, there blue data object in Figure 2 and results appear as the ges- are not restrictions on what is the direction and the speed ture progresses. The screen-shot is taken directly from the of the slide; these are all “query parameters” that the user IPad where we tested our prototype using the screen-shot may vary and adjust on-the-fly. functionality of XCode. Naturally, the actual user finger is not visible in Figure 2; in this case the user slides a finger Scan and Aggregates. The most basic action when hav- starting from the top of the blue object all the way to the ing a first exploratory look at a new set of data is achieved bottom of the object with a single continuous movement. either by having access at the actual data values, i.e., by a plain scan, or by running a few simple aggregations. In both Inspecting Results. A key element is how results are cases, dbTouch accesses base data and either delivers the ac- delivered to the user. Figure 2 depicts an example where tual data as is (in the case of a plain scan) or it computes a results appear as the user touches the data object. Results running aggregate and continuously updates this result (in appear in place, i.e., as if every single result value pops up the case that an aggregation query is chosen). Both queries from the position in the data object where the raw value are realized via a slide gesture over the data object the user responsible for this result lies. In fact, result values are typ- is interested in. The slide speed, the data object size and the ically shifted slightly sideways from the exact touch location exact area touched determine the actual data of the under- such as to avoid being hidden below the user finger. Soon lying base column or table to be processed. More complex after a result value becomes visible, it subsequently fades queries and considerations regarding data access and storage away, making room for more results to be inspected. For are discussed later on. example, in the screen-shot of Figure 2, the result values 

5 .which appear at the upper part of the blue data object are touch location is t, the size of the data object is o and the almost faded out; the effect is most visible to the upper most number of total tuples is n, then the tuple identifier we are data values. This is because the slide gesture in this partic- looking for is id = n ∗ t/o. ular example began from the upper part of the blue object and continued to the bottom part. In this way, the most When a data object refers to a single column, then only recently touched data entry is responsible for the most bold the height dimension is used to determine tuple identifiers; result value visible. With results appearing and disappear- this is both for the touch location and for the view size. ing in place and dynamically as the gesture evolves, dbTouch When a data object refers to a full table or to a collection gives the feeling of interactive exploration, i.e., only data en- of columns of a given table, then often both dimensions are tries which are touched are being processed and only when needed. For example, with a vertical slide over a full ta- touched; this is fully under the control of the user. ble the user would see a similar result as in the example of Figure 2; the difference is that now dbTouch returns tuple Challenges. There are several issues regarding how to de- entries as opposed to single column entries. In this case only sign and optimize a dbTouch system with a strong explo- the height dimension is needed. With a horizontal slide, on ration behavior; How should data be stored and accessed? the other hand, we use both dimensions to slide through the What happens when the slide patterns such as speed and attributes values of a given tuple entry; the tuple identifier directions change? Which data tuples exactly do we process is determined via the height, while the attribute seen is de- with every touch? How to maintain quick response times? termined by the relative width of the touch location within The rest of this section discusses initial ideas for those is- the view. In addition, if a data object is rotated such as sues and brings up open research problems for the efficient it lies horizontally, then a horizontal slide is used to scan design of dbTouch kernels. through the data. However, nothing changes regarding the mapping of touches to tuple identifiers; when we rotate an 2.4 From Touch to Tuple Identifiers object, then we only change its positioning within its master view; thus touches and identifiers calculated relative to the A key step in a dbTouch system is in translating the loca- object view are not affected. tion of a touch over a data object to a tuple identifier of the table or the column represented by the object, i.e., de- termining which data entry corresponds to the touch and 2.5 Data Access and Touch Granularity thus which data entry should be processed next. For ease of We now proceed to discuss in more detail how data is ac- presentation, consider a simplification of the slide gesture, cessed when applying gestures. i.e., a single tap gesture. With a single tap over a data ob- ject, dbTouch accesses a single data entry, i.e., in the case Touch to Explore. The goal of data exploration is not of a plain scan query, a single result value appears and fades a complete view of the data, rather a quick glance at the away (as in Figure 2). A slide gesture can be seen as mul- data and a quick discovery of possible interesting patterns. tiple continuous single taps in successive positions of a data The main idea is to guide users to quickly and easily figure object. out interesting data areas. Thus, running scans and queries over complete columns and tables brings slow response times Object Views. In order to translate the location of a touch which hinder exploration. to a tuple identifier, dbTouch exploits the view concept of modern touch-based operating systems. Views are place- Touching Samples. In this way, a slide gesture in dbTouch holders for visual objects. In turn, each view can be placed results in only a sample of the data being processed even if in a master view, forming hierarchies. Each view has a set a user slides through the whole area of a data object. The of properties associated with it which are readily accessible sample is distributed over the complete data set depending by the touch OS, such as the size of the view, the location on how the slide gesture progresses, i.e., the touch locations of the view within its master view, what kind of gestures registered determine the data to be processed. Every single are allowed over the view, etc. Within each view, visual data object visualized as an object of a few centimeters may objects and gestures can be treated independently to the correspond to data of say several million entries. However, master view. The touch OS allows for exact identification for each possible size of a visual object, there is a limited of the location where a touch appears within a view. amount of touch locations which can be registered and thus there is a limited amount of tuples which can be mapped Mapping a Touch to a RowID. In dbTouch, each data and processed. These limitations are there purely due to object visualized corresponds to a different view. dbTouch physical constraints (e.g., finger and object size). Of course, adds a number of properties to each view, e.g., the number a dbTouch system can give the option to the user to on of data entries in the underlying column or table, the data demand vary the touch granularity, i.e., how many tuples type(s), the data size, etc. In this way, once a touch is correspond to each touch, as well as to change the size of detected in a given view corresponding to a dbTouch data the object. In addition, dbTouch systems need to take into object, dbTouch determines the location of the touch within account the above considerations when deciding how to store the corresponding view. Subsequently, it determines the and how to access data. We discuss these issues and options respective tuple identifier using the knowledge of the current later on. size of the view and the knowledge of the total number of tuples in the actual data object; once we know the relative Exploration Speed. Assuming for simplicity slide ges- location based on the current view size, we can calculate the tures that start from one end of a data object and go with a relative location (i.e., the tuple identifier) within the actual steady speed all the way to the opposite end, then the data data object by applying the Rule of Three. Thus, if the entries processed are equally distributed over the complete 

6 .data set. A faster slide results in fewer tuples processed as point of a slide gesture. Similarly, there is no restriction less touch inputs are registered. On the contrary, a slower regarding how many times a single gesture may go over the slide over the same data object results in more tuples ac- same area of a data object. cessed; this is because more touches are recognized and more successive positions can be mapped to tuple identifiers of the All the parameters above call for highly adaptive methods underlying data. In this way, the slide speed determines the for storing and accessing data in order to be able to cope granularity of the data observed. with the numerous variations in gesture characteristics; any data may be accessed at any time. In addition, there are no restrictions to how a gesture pro- gresses. For example, after starting with a given speed, users Physical Layout. dbTouch does not pose any particu- may pause the gesture, e.g., because an interesting value is lar restrictions on the underlying storage model. It can be observed. Then, they can go back and forth in this data row-store, column-store or a hybrid format. One useful de- area at a much slower speed to observe the data at a more sign decision we use in our current prototype is that fields fine grained granularity. Overall the user has the freedom are fixed-width per attribute. This technique has been pio- to “walk” over the data in any direction and speed. This is neered in modern column-stores and is currently applied to drastically different to how a typical database system pro- hybrid systems as well. Essentially, using fixed-width values cesses data, i.e., one tuple after the other in the order they per attribute allows for a much easier calculation of data are stored in base data. dbTouch systems need to follow locations without having to access metadata information as the user touch which might mean that some data entries are it happens with more traditional slotted pages layouts. In skipped during query processing but there is no guarantee dbTouch, fixed-width fields allow for a faster mapping of that the user will not decide to go back and request those touch locations to tuple identifiers. In this way, the under- entries a few seconds later. This has implications to both lying storage layout used in our current dbTouch is matrixes. how we should store and how we should access data in a Each matrix may contain one or more columns and each col- dbTouch system. This issue is discussed in more detail in umn contains fixed-width fields. The matrixes are dense and the next sections. each matrix is associated with a given data object. Zoom-in/Zoom-out. As we discussed, a given object size Sample-based Storage. As we discussed, query process- restricts the amount of data a user can access. Users may ing in dbTouch via slide gestures is equivalent to processing change the size of an object using the zoom-in and the zoom- a sample of the underlying data. Even when a slide touches out gestures. This allows to increase and to decrease respec- the whole area of the target data object, the size of the ob- tively the granularity of the data processed from a given data ject and the speed of the gesture progression result in a given object, i.e., it can be seen as accessing varying samples of sample factor. In a traditional system, data is stored in a the same data. Figure 1 depicts examples of those gestures. single base column or table. However, in dbTouch, access- With a zoom-in gesture the respective data object becomes ing data at a coarse granularity directly from the base data bigger. As a result, there is more area to touch and thus a may result in loading a significant amount of data which is more fine grained access to the underlying data; with a big- not needed for the current query. As a result performance ger visual size, there is a bigger number of positions to map is hindered and the user does not get all the performance to tuple identifiers. For example, the right hand-side screen- benefits of not touching the whole data set. shot in Figure 2 depicts a slide over the blue column after a zoom-in operation; more data results appear compared to A better approach would be to store separately various dif- the slide in the left hand-side screen-shot in Figure 2. The ferent samples of the base data and depending on the object zoom-out gesture works in exactly the opposite way, result- size and gesture speed feed from the proper copy, minimizing ing to a smaller data object and thus to a more high level the auxiliary data reads. Similar ideas have appeared in Sci- view of the data when applying slide gestures. Zoom-in and borg [40] about storing hierarchies of samples. In dbTouch, zoom-out gestures can be used in combination with slide however, the problem becomes more complex as, given the gestures of a varying speed for significant flexibility when potential continuous variation of the slide parameters, dy- exploring data, allowing the user to drill down on selected namically choosing and switching between various copies of data areas adaptively and on demand. the data becomes a critical issue. 2.6 Storing and Accessing Data Prefetching Data. An interesting optimization is that of prefetching when a slide gesture pauses or slows down. We continue the dbTouch introduction with a discussion on dbTouch can extrapolate the gesture progression (speed and ideas regarding how data should be stored. direction) and fetch the expected entries such that they are readily available if the gesture resumes. Prefetching is more Gesture Evolution. A key element in dbTouch is how important when a slide gesture is used for aggregation op- we scroll through the data. Underlying storage and access erations where more computation is involved or of course if methods need to be able to adjust to gesture patterns and the slide gesture is used for more complex queries involving variations. The goal is to improve the data access time a several operators and data objects (to be discussed later on). dbTouch system needs in order to react to a single touch. The progression of the user gestures defines how fast we go Caching Data. In addition, caching can be exploited such from one value entry to the next; users may change the slide that dbTouch is ready if the user decides to re-examine a speed over time, they may change the direction of the slide or data area already seen. dbTouch needs to observe the ges- they may even pause the gesture temporarily. In addition, ture patterns and adjust the caching policy according to the there are no restrictions regarding the start and the end 

7 .expected progression of the gesture. In addition, caching dbTouch user can take control over performance parameters may be used in order to create a new copy (sample) of the in an intuitive and interactive way. data which will allow dbTouch to answer future queries re- questing data at a similar granularity. A critical parameter is the interactive and adaptive behavior that dbTouch systems should provide. Changing the layout Indexing. Creating and exploiting indices for dbTouch sys- can be done in steps as it is in general an expensive oper- tems is an exciting topic. When querying an indexed column ation, requiring a full copy of the data. Depending on the or sets of columns, then the slide gesture becomes the equiv- size of the current object, dbTouch should choose to create alent of an index scan. Having a hierarchy of samples di- the new format for only a sample of the data, giving back to rectly affects indexing decisions; for example, dbTouch can the user a quick response and new data object(s) to query. maintain a separate index for each sample level, treating When and if the user requests for more detail within the new each copy separately depending on how often index support object, e.g., with a zoom-in gesture, then more data can be is needed for this copy. Similarly, switching between the var- retrieved from the old layout. ious indexes during a single slide of a varying speed becomes a challenging issue. 2.9 Query Plans and Complex Queries Up to now, we mainly discussed about simple scans using 2.7 Interactive Summaries the slide gesture. However, any kind of complex query is A more advanced use of the slide gesture in dbTouch is possible. the exploitation of interactive summaries. The idea is that when sliding through a data object, dbTouch returns a sum- Complex Queries. For example, the slide gesture can be mary of x items as opposed to simply returning a single used in order to run any kind of aggregate over a column data entry which corresponds to the exact touch location. object or to perform selections by posing a where restriction The summary is defined as an aggregate value of several to the scan. In addition, multi-column query plans are also consecutive data entries. When during a slide we register possible. Again it is a matter of enabling the proper ac- position p which corresponds to tuple identifier idp , then tions. For example, we can enable where and select actions dbTouch scans all entries within the tuple identifier range on one or more columns as well as we can enable a join for a [idp − k, idp + k] and calculates a single aggregate value. Pa- pair of columns. Then, with the slide gesture over one of the rameter k can be defined by the users according to their ex- columns used with a where action, a user can go through the ploration requirements as well as by system parameters. For data and drive the query processing steps. The tuple identi- example, when fetching a given data item, we would like to fiers captured in the object where we apply the slide gesture also exploit all items within the same cache line. Similarly, define the data processed. Essentially, the same discussion the kind of aggregation used can be defined by the user. A as the one we did for the slide gesture for scans holds here as good default choice is to perform an average aggregation. well, i.e., regarding slide speed, direction, object sizes, etc; the only difference is that here the system needs to perform Essentially, interactive summaries open two opportunities a more complex computation per data entry as opposed to for data exploration. First, they allow users to “touch” and simply visualizing the touched entry as in the case of a scan. inspect more data with each single touch. Second, they allow for a quick inspection of properties and patterns on Joins. Maintaining the interactive behavior during join small/controlled groups of data, while also observing dif- queries is a challenging topic. The join is primarily a block- ferences in patterns across different data areas of the same ing operator as the hash-join is the typical choice. The same object on demand. is true for hash-based grouping. However, in dbTouch we do not know up front all the data we are going to process. This 2.8 Schema and Storage Layout Gestures is only known as the gesture evolves. Subsequently, we can- Part of the exploration process involves changing the schema not use a hash-join as we do not know which data we should or the layout of the data for organization or for performance use to build the hash table. Of course, we could use the reasons. With the data visualized as objects in a touch whole input but this would result in a significant delay. As screen, users can move data around using pan gestures and such, exploiting non blocking options is a necessary path in group or ungroup specific data objects. For example, one dbTouch. Similarly, caching of hash tables across the various can create a table by drag and drop actions in a table place- sample copies can enhance future queries. holder object where independent columns can be dropped. Optimization. With more complex queries than plain scans More interestingly, dbTouch allows users to vary the layout and aggregates, optimization plays a crucial role. This is of individual tables using the rotate gesture (see Figure 1). for the same reasons as in traditional databases. The or- Rotating a row-oriented table changes its physical layout der of operators and the actual physical operators used can to a column-store structure by projecting all attributes to have a significant impact. However, contrary to traditional individual arrays (and vice versa). The effects of the rota- databases, in a dbTouch system we do not know up front tion gesture are also applied by simply rotating the tablet how much data we are going to process. When a user initi- device itself for an even more interactive experience. Simi- ates a slide gesture for a complex query, only a small part larly, a user can project a specific column out of a fat table of the data may be processed or even all of the data may be by dragging the column out of the table. It can be sent processed. to an individual array or simply to a smaller table allow- ing the user to experience faster response times by going Not knowing which part of the data is going to be pro- only through the needed data. The net result is that the cessed makes optimization decisions challenging as for dif- 

8 . 60 60 a) Vary gesture speed b) Vary object size Recognize Touch # of data entries returned # of data entries returned 50 50 Operating System 40 40 Recognize Gesture 30 30 20 20 Map touch to data 10 10 dbTouch 0 0 Execute 0 0.5 1 1.5 2 2.5 3 3.5 4 0 5 10 15 20 25 Time to complete gesture (secs) Object size (cms) Figure 3: dbTouch system layers. Figure 4: Effect of varying object size and slide ges- ture speed during a slide for interactive summaries. ferent parts of the data in the same table, different prop- where a user continuously gives input to the system and erties may apply. In this way, dbTouch brings an inter- drives query processing actions via touch gestures. To give a esting scenario for adaptive optimization approaches that glimpse on the interaction and exploration properties of our interleave with query execution. dbTouch needs to figure current dbTouch prototype, we provide two experimentation out the proper optimization decisions on-the-fly, while still examples which are characteristic of the exploration process. maintaining good response times. At the same time, as the slide direction and speed evolves dbTouch needs to adapt Varying Gesture Speed. The first experiment observes these decisions to the new data which is processed. Contrary what happens with a varying speed of applying the basic to adaptive approaches for traditional databases, dbTouch slide gesture for an interactive summaries query, using an does not control the data flow and thus it is much harder average aggregation and 10 data entries for each summary. to make reliable decisions regarding when to switch to a The set-up is as follows. A rectangle object in a vertical po- different query plan. sition represents a column of 107 integer values. The height of the object is 10 centimeters. We apply the slide gesture 3. DBTOUCH PROTOTYPE starting from the top end of the object and finishing at the In this section, we briefly discuss the details of our imple- bottom end. We repeat the gesture 3 times. Each time the mentation over IOs for IPad and we provide an early evalu- gesture is completed with a different speed and each time ation. We build on top of IOs SDK 5.1 (9B176) and we test we measure the amount of data entries that appear. Figure on IPad 1, while our development environment is XCode 4(a) shows the results. As we slow down the speed of the 4.3.2 (4E2002). gesture, we are able to observe/process more data. dbTouch captures more touch input and it can map this input to ob- Implementation. Our current dbTouch prototype is es- ject identifiers of the underlying data. In this way, a varying sentially a small prototype database kernel implemented on gesture speed allows drilling down to detail or getting a high top of IOs in objective C. In many ways it resembles a hy- level view of the data. It gives users the power to explore the brid kernel where data is stored in fixed-width dense arrays data and to continuously adjust the exploration properties or matrixes. Similarly to the typical SQL input, parser, in an interactive way as results appear. optimizer, execution flow of modern database systems, the dbTouch prototype goes through a flow that begins with a Varying Object Size. In our second experiment, we test touch input, and continues with gesture recognition as op- what happens as the size of a data object changes. The posed to parsing. Then, depending on the gesture, the loca- set-up is the same as before. This time we apply a zoom-in tion touched, the size of the object touched, etc., the proper gesture to progressively increase the size of the data object. dbTouch execution methods are called. For each size, we perform a slide gesture with the same speed (from top to bottom) and observe the amount of data pro- Figure 3 shows a high level view of the dbTouch stack and cessed. At each step we double the size of the object and we how the various system layers interact. dbTouch feeds from take double the time to complete the slide gesture. Figure the operating system; once a touch is registered by the op- 4(b) shows the results. By adjusting the object size we al- erating system, dbTouch takes action to find which data low for more detail; as the size increases, the same gesture should be processed and what kind of actions should be speed allows the inspection of more data. Similarly to our performed. This flow is not per query as it is in database discussion in the previous paragraph, via adjustments of the systems; instead, dbTouch goes through these steps for ev- object size a user can interactively get a more fine grained ery touch input on a data object. Our current prototype or a more high level view of the data on demand. supports several of the gestures/operators seen in the previ- ous section such as slide or single tap for scan, aggregation Summary. Overall, dbTouch provides a promising play- and interactive summaries as well as zoom-in/zoom-out for ground to promote interactive data exploration; data ana- a more detailed or a more high level exploration. lysts can get a quick feeling of the data on demand, while continuously adjusting the exploration parameters and while Evaluation. Evaluating a dbTouch system is a challenge by using only intuitive touch input as opposed to writing SQL itself mainly due to the interactive nature of the paradigm scripts. 

9 .4. CHALLENGES AND OPPORTUNITIES 5. RELATED WORK The previous sections described the dbTouch vision and dis- This paper takes inspiration from several research areas re- cussed several challenges when designing the individual com- lated to data management. ponents of a dbTouch kernel. Here, we discuss an additional set of more broad challenges and opportunities. Data Exploration. Data exploration has seen significant support during the past decade. Several researchers argue Interactive Behavior. Most prominently, developing com- towards exploration based database kernels and propose sev- plete touch-based database kernels requires in depth study eral directions such as sampling based kernels [3, 31, 40], of optimization and algorithmic choices. The main challenge adaptive indexing [26] and adaptive data loading [24, 4, 5]. is in continuously reacting to user input gestures and prop- Overall, this is a quite promising and largely unexplored re- erly anticipating the next move such as to avoid big stalls. In search area. dbTouch complements ongoing research efforts all cases, the response times to touch events need to be kept by providing a promising alternative when it comes to how low. The whole design of dbTouch kernels should be geared users interact with an exploration based database kernel. towards an interactive and adaptive behavior. There should Ideas such as sampling, adaptive indexing or loading can be always be a maximum possible wait time for a single touch exploited in the dbTouch context with new challenges on regardless of the query and the data sizes. Approximate how to adapt to the dynamic touch patterns in gestures. query processing in combination with dbTouch may be an interesting direction, i.e., results appear within the expected Online Aggregation. Online aggregation [22, 38] is also response time and then they are continuously refined. related to dbTouch. In online aggregation the system con- tinuously returns results as they are created. A confidence Data Visualization. In addition, studying dbTouch across metric is also calculated and reported, allowing the user to various application-specific data visualization formats and terminate query processing when confidence reaches satis- the implications this brings for designing dbTouch kernels is factory levels. Online aggregation techniques can certainly of high importance. The relational-like visualization we used be exploited in dbTouch; dbTouch brings additional chal- to describe dbTouch in this paper is a generic format but lenges as the user drives the speed of requesting more data application-specific formats can enhance the user experience and determines the data to be processed dynamically. as well as the ability to quickly interpret the data. The data visualization community has tremendous results in this area. Visual Analytics. The idea that simple text mode can For example, maps can be used to cluster data based on hurt usability is not new. Polaris is the pioneering system geographical information. Data may be colored to quickly from Stanford University for visual analytics [41, 42]. In Po- determine patterns, outliers, etc. In addition, graphs and laris, there are two distinct features to ease usability and ex- mind-maps may be used to depict trends and correlations. ploration: (a) users can synthesize SQL queries by drag and Regardless of the visualization format, dbTouch needs to drop actions and (b) results appear directly in the proper maintain its adaptive character and the goal for interactive visual format. For example, results can appear directly in a response times. The main challenge is whether we can create bar graph or in other graph formats depending on the kind a generic dbTouch kernel which can be used as a back-end of data. The ideas pioneered in Polaris and later commer- to various visualization formats. cialized in the Tableau system are directly in line with the dbTouch vision. In addition to Tableau, there are more com- Remote Processing. Another interesting direction is the mercial systems exploiting similar ideas; in particular, Data option of remote processing when the touch device is an in- Clarity and VisuaLinks from Visual Analytics Inc. and the terface to a cloud or server facility which does the bulk of Visual Analytics platform by SAS. All these systems have the query processing. For example, the server may store the same high level goal; they try to provide an easy way to the base data and the big samples, while the touch device construct queries graphically and to visualize results using may store only small samples. Then, during query process- the proper format according to the result data. ing dbTouch may use both local and remote data to pro- cess queries; as users request more detail, more requests are In all cases above, the underlying database system is a tra- shipped to the server. Still, though, dbTouch should guar- ditional system; what changes is the input method and the antee low response times. However, sending a new remote visualization of the results. What dbTouch brings is the idea request for every single touch input of a long gesture will of building database kernels to inherently support touch in- lead to extensive administration and communication costs. terfaces and interactive exploration at their core, taking vi- As a result, dbTouch needs to carefully exploit both local sual analytics one major step further by allowing systems to and remote data, i.e., use local data to feed partial answers, increase their interactive and exploratory character. Users while in the mean time more fine-grained answers are pro- in dbTouch do not pose a traditional query by pointing in duced and delivered by the server. an object and then waiting for an answer. Instead, they drive the query processing actions, working on top of data Alternative Interfaces. Finally, studying other forms samples and by continuously defining (touching) the data to of input and its implications in creating interactive data- be processed next; they have full control of the exploration base kernels is another exciting opportunity. Motion input, process. speech recognition as well as combinations of those input methods are some of the options. As in the case of visu- Data3. Data3 is a recent system which exploits motion alization formats, the main challenge here is whether it is sensing [23]. Data3 builds on top of an existing stream en- possible to create a generic adaptive kernel which can be gine and allows users to interact with the stream engine adjusted easily for any input method. using gestures as opposed to using a declarative language. 

10 .Users can define streams and pose continuous queries via processing on raw data. PVLDB, 5(12):1942–1945, gestures. Essentially, Data3 implements an interface to an 2012. existing and traditional system. This is still an exciting and crucial step. However, when it comes to database architec- [6] R. Barber, P. Bendel, M. Czech, O. Draese, F. Ho, tures, nothing changes regarding how data is processed or N. Hrle, S. Idreos, M.-S. Kim, O. Koeth, J.-G. Lee, the ability of the system to adapt to user behavior. T. T. Li, G. M. Lohman, K. Morfonios, R. M¨ uller, K. Murthy, I. Pandis, L. Qiao, V. Raman, R. Sidle, On the contrary, the dbTouch vision is about redesigning K. Stolze, and S. Szabo. Business analytics in (a) systems to exploit the new opportunities that appear with blink. IEEE Data Eng. Bull., 35(1):9–14, 2012. the emerging input methods such as touch and motion sens- ing. In dbTouch, we do not pose traditional queries using [7] P. A. Bernstein, C. W. Reid, and S. Das. Hyder - a a new input method; instead, we envision new ways to pro- transactional record manager for shared flash. In cess data and a new query processing paradigm all together; CIDR, pages 9–20, 2011. users drive the low level query processing actions by pointing [8] P. Boncz, M. Zukowski, and N. Nes. MonetDB/X100: to the data that should be processed in every query process- Hyper-Pipelining Query Execution. In CIDR, 2005. ing step. This changes drastically the way we should design database kernels and brings several opportunities and chal- [9] S. Chaudhuri. What next? a half-dozen data lenges for data exploration. management research goals for big data and cloud. In PODS, 2012. 6. CONCLUSIONS Data exploration has emerged as a critical need in our effort [10] S. Chen, P. B. Gibbons, and S. Nath. Rethinking to handle big data and the new stream of applications that database algorithms for phase change memory. In rely on data management. Data exploration tools are meant CIDR, pages 21–31, 2011. to assist when we are in need to quickly analyze data, not necessarily knowing exactly what we are looking for; the re- [11] P. Cudr´e-Mauroux, E. Wu, and S. Madden. The Case sults of one query inspire the formulation of the next query. for RodentStore: An Adaptive, Declarative Storage At the same time, touch interfaces have proven to be ex- System. In CIDR, 2009. tremely successful mainly by promoting usability. [12] C. Curino, E. P. C. Jones, R. A. Popa, N. Malviya, E. Wu, S. Madden, H. Balakrishnan, and In this paper, we introduce dbTouch, a new research direc- N. Zeldovich. Relational cloud: a database service for tion towards touch-based database kernels, tailored for in- the cloud. In CIDR, pages 235–240, 2011. teractive data exploration in the big data era. We propose to rethink database architectures towards designs which can [13] J. Dittrich and A. Jindal. Towards a one size fits all cope with the different needs posed by a full-blown touch- database architecture. In CIDR, pages 195–198, 2011. based database system. This paper discusses the dbTouch vision and challenges along with several gestures and ac- [14] A. Doan, R. Ramakrishnan, and A. Y. Halevy. companying exploration-based database operators driven by Crowdsourcing systems on the world-wide web. touch patterns. In addition, we present a dbTouch proto- Commun. ACM, 54(4):86–96, 2011. type over IOs for IPad, showcasing the simplicity and intu- itive nature of dbTouch. Overall, dbTouch opens a new and [15] M. J. Franklin, D. Kossmann, T. Kraska, S. Ramesh, completely unexplored territory for database researchers in and R. Xin. Crowddb: answering queries with the path towards big data analytics and insights. crowdsourcing. In SIGMOD, 2011. [16] G. Graefe, F. Halim, S. Idreos, H. Kuno, and 7. REFERENCES S. Manegold. Concurrency control for adaptive [1] A. Abouzeid, K. Bajda-Pawlikowski, D. J. Abadi, indexing. PVLDB, 5(7):656–667, 2012. A. Rasin, and A. Silberschatz. Hadoopdb: An architectural hybrid of mapreduce and dbms [17] M. Grund, P. Cudr´e-Mauroux, J. Kr¨ uger, S. Madden, technologies for analytical workloads. PVLDB, and H. Plattner. An overview of hyrise - a main 2(1):922–933, 2009. memory hybrid storage engine. IEEE Data Eng. Bull., [2] F. N. Afrati, A. D. Sarma, D. Menestrina, A. G. 35(1):52–57, 2012. Parameswaran, and J. D. Ullman. Fuzzy joins using [18] F. Halim, S. Idreos, P. Karras, and R. H. C. Yap. mapreduce. In ICDE, pages 498–509, 2012. Stochastic database cracking: Towards robust [3] S. Agarwal, A. Panda, B. Mozafari, S. Madden, and adaptive indexing in main-memory column-stores. I. Stoica. Blink and it’s done: Interactive queries on PVLDB, 5(6):502–513, 2012. very large data. In PVLDB, 2012. [19] P. Hanrahan. Analytic database technologies for a new [4] I. Alagiannis, R. Borovica, M. Branco, S. Idreos, and kind of user - the data enthusiast. In SIGMOD, 2012. A. Ailamaki. Nodb: efficient query execution on raw data files. In SIGMOD, 2012. [20] N. Hardavellas, I. Pandis, R. Johnson, N. Mancheril, A. Ailamaki, and B. Falsafi. Database servers on chip [5] I. Alagiannis, R. Borovica, M. Branco, S. Idreos, and multiprocessors: Limitations and opportunities. In A. Ailamaki. Nodb in action: Adaptive query CIDR, pages 79–87, 2007. 

11 .[21] S. Harizopoulos, M. A. Shah, J. Meza, and [38] N. Pansare, V. R. Borkar, C. Jermaine, and P. Ranganathan. Energy efficiency: The new holy grail T. Condie. Online aggregation for large mapreduce of data management systems research. In CIDR, 2009. jobs. PVLDB, 4(11):1135–1145, 2011. [22] J. M. Hellerstein, P. J. Haas, and H. J. Wang. Online [39] A. G. Parameswaran, H. Garcia-Molina, H. Park, aggregation. In SIGMOD Conference, pages 171–182, N. Polyzotis, A. Ramesh, and J. Widom. Crowdscreen: 1997. algorithms for filtering data with humans. In SIGMOD Conference, pages 361–372, 2012. [23] S. Hirte, A. Seifert, S. Baumann, D. Klan, and K.-U. [40] L. Sidirourgos, M. L. Kersten, and P. A. Boncz. Sattler. Data3 - a kinect interface for olap using Sciborq: Scientific data management with bounds on complex event processing. In ICDE, pages 1297–1300, runtime and quality. In CIDR, 2011. 2012. [41] C. Stolte, D. Tang, and P. Hanrahan. Polaris: A [24] S. Idreos, I. Alagiannis, R. Johnson, and A. Ailamaki. system for query, analysis, and visualization of Here are my data files. here are my queries. where are multidimensional relational databases. IEEE Trans. my results? In CIDR, pages 57–68, 2011. Vis. Comput. Graph., 8(1):52–65, 2002. [25] S. Idreos, F. Groffen, N. Nes, S. Manegold, K. S. [42] C. Stolte, D. Tang, and P. Hanrahan. Query, analysis, Mullender, and M. L. Kersten. Monetdb: Two decades and visualization of hierarchically structured data of research in column-oriented database architectures. using polaris. In KDD, pages 112–122, 2002. IEEE Data Eng. Bull., 35(1):40–45, 2012. [43] M. Stonebraker, D. Abadi, A. Batkin, X. Chen, [26] S. Idreos, M. Kersten, and S. Manegold. Database M. Cherniack, M. Ferreira, E. Lau, A. Lin, S. Madden, Cracking. In CIDR, 2007. E.O’Neil, P. O’Neil, A. Rasin, N. Tran, and S. Zdonik. C-Store: A column oriented DBMS. In VLDB, 2005. [27] S. Idreos, M. Kersten, and S. Manegold. Updating a [44] P. Triantafillou. Anthropocentric data systems. Cracked Database. In SIGMOD, 2007. PVLDB, 4(12), 2011. [28] S. Idreos, M. Kersten, and S. Manegold. Self-organizing Tuple-reconstruction in Column-stores. APPENDIX In SIGMOD, 2009. A. DBTOUCH DEMO Here, we describe a demo proposal for dbTouch. The main [29] S. Idreos, S. Manegold, H. Kuno, and G. Graefe. goal of dbTouch is to enable data exploration through inter- Merging what’s cracked, cracking what’s merged: active touch-based database kernels. In this way, the demo Adaptive indexing in main-memory column-stores. focuses on exposing the exploration properties and oppor- PVLDB, 4(9):585–597, 2011. tunities of dbTouch to the audience. [30] A. Kemper and T. Neumann. Hyper: A hybrid Set-up and Scenarios. The main idea for the demo is oltp&olap main memory database system based on that the audience will get direct access to the dbTouch pro- virtual memory snapshots. In ICDE, 2011. totype. We will provide our development IOs device for this purpose (IPad 1). Data will be loaded in a tablet device [31] M. L. Kersten, S. Idreos, S. Manegold, and E. Liarou. and the audience will get the chance to use the system and The researcher’s guide to the data deluge: Querying a interact via gestures to query and explore the data. We will scientific database in just a few seconds. PVLDB, provide alternative data sets with a varying set of properties 4(12):1474–1477, 2011. and patterns. The audience attending the demo will have [32] N. Khoussainova, M. Balazinska, and D. Suciu. the task of discovering these properties by interacting with Perfxplain: Debugging mapreduce job performance. dbTouch via gestures. PVLDB, 5(7):598–609, 2012. Exploration Contest: dbTouch Vs. DBMS. In addi- [33] W. Lang and J. M. Patel. Towards eco-friendly tion, the audience attending the demo can participate in an database management systems. In CIDR, 2009. exploration contest. We will provide a laptop installed with the open-source column store DBMS, loaded with the same [34] D. B. Lomet, A. Fekete, G. Weikum, and M. J. data sets as dbTouch. Two audience members will simulta- Zwilling. Unbundling transaction services in the cloud. neously start exploring the data sets; one member will be In CIDR, 2009. using the tablet dbTouch prototype, while the other mem- ber will be using the SQL interface of the DBMS on the [35] A. Marcus, E. Wu, S. Madden, and R. C. Miller. laptop. Both audience members will be free to perform any Crowdsourced databases: Query processing with kind of query processing actions, i.e., to apply any kind of people. In CIDR, pages 211–214, 2011. supported gestures in dbTouch and to fire any kind of SQL [36] R. M¨uller, J. Teubner, and G. Alonso. Data processing queries in the DBMS. The winner is the one who can first on fpgas. PVLDB, 2(1):910–921, 2009. figure out the data properties and patterns. [37] A. Nandi and H. V. Jagadish. Guided interaction: Summary. Overall, the demo will allow users to play with Rethinking the query-result paradigm. PVLDB, dbTouch on an IPad and to directly compare with a DBMS 4(12):1466–1469, 2011. experience for the same tasks.