http://muratbuffalo.blogspot.com/2024/08/making-database-systems-usable.html Skip to main content Search This Blog [ ] [Search] Metadata On distributed systems broadly defined and other curiosities. The opinions on this site are my own. Making database systems usable * Get link * Facebook * Twitter * Pinterest * Email * Other Apps - August 19, 2024 C. J. Date's Sigmod 1983 keynote, "Database Usability", was prescient. Usability is the most important thing to the customers. They care less about impressive benchmarks or clever algorithms, and more about whether they can operate and use a database efficiently to query, update, analyze, and persist their data with minimal headache. (BTW, does anyone have a link to the contents of this Sigmod'83 talk? There is no transcript around.) The paper we cover today is from Sigmod 2007. It takes on the database usability problem raised in that 1983 keynote head-on, and calls out that the king is still naked. Let's give some context for the year 2007. Yes, XML format was still popular then. The use-case in the paper is XQuery. The paper does not contain any reference to json. MongoDB would be released in 2009 with the document model; and that seems to be great timing for some of the usability pains mentioned in the paper! Web 2.0 was in full swing, social media was rising. Cloud computing and big data was emerging. NoSQL movement was just starting. Database usability is an important but wicked problem Why is database usability important? "In places where database systems are used extensively, we find an army of database administrators, consultants, and other technical experts all busily helping users get data into and out of a database. For almost all organizations, the indirect cost of maintaining a technical support team far exceeds the direct cost of hardware infrastructure and database product licenses. Not only are support staff expensive, they also interpose themselves between the users and the databases. Users cannot interact with the database directly and are therefore less likely to try less straightforward operations. This hidden opportunity cost may be greater than the visible costs of hardware/ software and technical staff." This is spot on. And the paper follows up on this with flight booking example. You youngins may not remember, but pre-2005 we had to call a travel agent to book our flights and get paper tickets in return. This sucked, we don't have any transparency in to the process, we couldn't explore options (price, convenience, dates, airports) and customize our trip. Having access to flight booking via web was really a great improvement for user experience. For flight booking, slapping a web-search interface to the flight databases solved the problem, but you still needed the database including its querying engine for this solution. But things are not that easy for operationalizing databases. It is all about how you manage expectations when you are serving the customer (as I wrote before). The paper compares the database problem with the web search problem to make this point. Users expect the ability to query the database in a more sophisticated way than text based web-querying. Secondly, users expect more precise and complete answers from database search. Finally, users expect to create and update databases, not just query them in a read-only manner. The big takeaway for me is that database usability is a wicked problem. This is a technical term, look it up. Maybe by defining it well, we can tame this a bit, and downgrade it from the wicked problem to the messy problem category. Case study: MIMI protein interaction database system After the sequencing of the human genome was completed, biologists began focusing their attention on the proteins expressed by these genes, their interactions, and their functions. This team build MIMI to facilitate this, and collaborated with University of Michigan biologists throughout a multi-year project. "Given the XML representation of the data, XQuery was our first choice for accessing the database. Indeed, some users wanted the power of a declarative query language, even if they didn't have the training to write such queries. A majority of users, however, were complete technophobes and preferred forms-based interfaces. (Such interfaces do a good job today for specific applications--quite complex back-end queries can be run, for instance in an airline reservations database, while the user is shielded from this complexity by a simple form-based query interface.) Aside from these were a few users who wanted to download the entire dataset and write Perl scripts to slice and dice it. Our challenge in MiMI was to provide easy-to-use interfaces beyond a few hand- designed forms for some common queries. In fact, MiMI allows users to access data through various interfaces, which are depicted in Figure 1." [Screenshot] This sounds good on paper right? But when you have users, you run into a whole bunch of problems you haven't anticipated. The paper lists some of these anecdotes, and writes: "As we analyze our accomplishments, and more impor- tantly, the many remaining issues described above, we have come to realize that the usability of a database system is much more than skin deep. Our work on query interfaces may contribute towards the usability of a system, but they are far from enough to provide the optimal user experience. In the next section, we enunciate what we believe are the major database usability problems." The title of the next section is "The persistence of pain". The subsection titles are even funnier. Painful relations (this takes the prime spot!), Painful options, Unexpected pain, Unseen pain, and Birthing pain. Painful relations In this subsection, the paper complains about the relational model. "Whereas a single table of data is natural for most peo- ple, joins between multiple tables are not. Unfortunately, normalization is at the center of relational design. Indeed normalization saves space, avoids update anomalies, and is a desirable property from many perspectives. However, the use of joins in a relational model does not retain the integrity of data objects that a user regards as one unit." [Screenshot] The paper gets back to the flight example, but this time from the POV of the backend database in Fig 2. It says that "Such "splattering" of data decreases the usability of the database in terms of schema comprehension, join computation, and query expression." Actually Figure 2 doesn't look that bad, but things devolve from there. "The users will have to stitch the information back together to answer most of the real queries. The fundamental issue is that joins destroy the connections between information pertaining to the same real world entities and are nonintuitive to most normal users. We note that many commercial database systems carefully denormalize their schema to reduce the number of joins required, although the purpose there is to speed up query evaluation. Finally, queries become painful to express across multiple tables. Because joins innately disrupt data cohesion, such queries are problematic for many users. For example, consider a query as simple as "Find all flights from Detroit to Beijing" in our airline database. Even though we are interested only in information about flights, the city names that specify the selection predicate are found only in the airports relation, which must be joined twice with flight info to express our query." The paper mentions that: "The current solution to manage this pain is to hire database administrators (DBAs) and offer them copious amounts of money not to leave once they have learned the company's database schema well." The other pains Painful options: Too many options overwhelms users. While simplicity is crucial for novices, experts require advanced tools. The challenge lies in balancing functionality for diverse user needs without cluttering the interface. Unexpected pains: Systems often produce confusing results without explanation. Users need clear insights into why outcomes differ from their expectations. This requires transparent system behavior, explainability, and intuitive error messaging. Unseen pain: The lack of WYSIWYG (What You See Is What You Get) interfaces makes query formulation difficult. Real-time, predictive capabilities during query construction help users refine searches effectively. This involves instant feedback and suggestions as users type. Birthing pain: Creating and populating databases is complex for ordinary users. They struggle with schema design and data reorganization for existing structures. Simplifying these processes without sacrificing database integrity is crucial. The painless future There is no silver bullet. Of course, you knew this, because database usability is a wicked problem. The paper makes some suggestions, and leaves it at that. Presentation data models: Expand the concept of views beyond tables to support various presentation data models (object, geographic, network, multidimensional, tabular). This flexibility would allow users to interact with data in formats most suitable for their needs. Integrated Provenance: Incorporate data provenance (both "why" and "where") into presentation models. This feature would help users understand the origin and transformations of their data, enhancing transparency and trust in results. Intuitive Interaction: Develop presentation data models capable of direct manipulation through familiar actions like point-and-click and drag-and-drop. This approach would make databases more accessible to non-technical users, reducing the learning curve. Flexible Schema Design: Support "schema-later" and "heterogeneous" database creation, allowing users to start with unstructured data and add structure as needed. This flexibility would enable faster database setup and evolution as requirements change. Discussion Ok, it is 17 years after the publication of this paper. Where are we at in terms of database usability? What were the biggest improvements you can think of? What were the steps taken to reduce the friction? The Designing Data Intensive Applications Book (2017) goes into usability/maintainability discussion a bit in Chapters 1 and 2. It compares relational model and document model. It also talks about Object-relational mapping (ORM) frameworks a bit. But it seems like we are still long way from making databases usable. If nothing else, since we had to make database systems also distributed systems we added to these problems, especially for the operationalization of databases. We opened Pandora's box in terms of partial failures, unexplained performance problems due to geo-distribution, data migration, storage disaggregation, and metastable failures. Well we have our work cut out for us. Well, let's look at this more optimistically and consider recent developments that may be beneficial. How about LLMs? LLMs may help, but if not used intentionally in a principled manner, they make more of a mess. They would be adding to the painful options, unexpected pains. They probably can't do much to address the unseen pain, and maybe do a probabilistic (best effort) job in addressing birthing pain, which may make things worse. But applied in a principled way, I believe LLMs can go a long way to improve database usability. It is someone else's paper to write, and when this is written, I will be interested in learning from it. databases * Get link * Facebook * Twitter * Pinterest * Email * Other Apps Comments [bla] Anonymous said... https://dl.acm.org/doi/10.1145/971695.582194 C.J.Date's paper August 20, 2024 at 8:56 PM [icon_delet] Post a Comment Popular posts from this blog Learning about distributed systems: where to start? - June 10, 2020 This is definitely not a "learn distributed systems in 21 days" post. I recommend a principled, from the foundations-up, studying of distributed systems, which will take a good three months in the first pass, and many more months to build competence after that. If you are practical and coding oriented you may not like my advice much. You may object saying, "Shouldn't I learn distributed systems with coding and hands on? Why can I not get started by deploying a Hadoop cluster, or studying the Raft code." I think that is the wrong way to go about learning distributed systems, because seeing similar code and programming language constructs will make you think this is familiar territory, and will give you a false sense of security. But, nothing can be further from the truth. Distributed systems need radically different software than centralized systems do. --A. Tannenbaum This quotation is literally the first sentence in my distributed systems syllabus. Inst Read more >> Hints for Distributed Systems Design - October 02, 2023 This is with apologies to Butler Lampson, who published the " Hints for computer system design " paper 40 years ago in SOSP'83. I don't claim to match that work of course. I just thought I could draft this post to organize my thinking about designing distributed systems and get feedback from others. I start with the same disclaimer Lampson gave. These hints are not novel, not foolproof recipes, not laws of design, not precisely formulated, and not always appropriate. They are just hints. They are context dependent, and some of them may be controversial. That being said, I have seen these hints successfully applied in distributed systems design throughout my 25 years in the field, starting from the theory of distributed systems (98-01), immersing into the practice of wireless sensor networks (01-11), and working on cloud computing systems both in the academia and industry ever since. These heuristic principles have been applied knowingly or unknowingly and has proven Read more >> Foundational distributed systems papers - February 27, 2021 I talked about the importance of reading foundational papers last week. To followup, here is my compilation of foundational papers in the distributed systems area. (I focused on the core distributed systems area, and did not cover networking, security, distributed ledgers, verification work etc. I even left out distributed transactions, I hope to cover them at a later date.) I classified the papers by subject, and listed them in chronological order. I also listed expository papers and blog posts at the end of each section. Time and State in Distributed Systems Time, Clocks, and the Ordering of Events in a Distributed System. Leslie Lamport, Commn. of the ACM, 1978. Distributed Snapshots: Determining Global States of a Distributed System. K. Mani Chandy Leslie Lamport, ACM Transactions on Computer Systems, 1985. Virtual Time and Global States of Distributed Systems. Mattern, F. 1988. Practical uses of synchronized clocks in distributed systems. B. Liskov, 1991. Expository papers Read more >> Metastable failures in the wild - September 12, 2023 Image This paper appeared in OSDI'22. There is a great summary of the paper by Aleksey (one of the authors and my former PhD student, go Aleksey!). There is also a great conference presentation video from Lexiang. Below I will provide a brief overview of the paper followed by my discussion points. This topic is very interesting and important, so I hope you have fun learning about this. Metastability concept and categories Metastable failure is defined as permanent overload with low throughput even after the fault-trigger is removed. It is an emergent behavior of a system, and it naturally arises from the optimizations for the common case that lead to sustained work amplification. In this paper, the authors are able to capture/ abstract the system behavior of interest in terms of two parameters, the load and capacity. If the load is above capacity, you have work piling up, right? Or if the capacity drops under the sustained load level, the same effect, right? Both of these create a tem Read more >> Advice to the young - July 30, 2024 Image I notice I haven't written any advice posts recently. Here is a collection of my advice posts pre 2020. I've been feeling all this elderly wisdom pent up in me, ready to pour at any moment. So here it goes. Get ready to quench your thirst from my fount of wisdom. No man, think for yourself, only get what works for you. It is called foundations, not theory Foundations of computer science (or rather any field of study) are the most important topics you can learn. These lay down the frame of thinking/perspective for that area of study. Yet, I am saddened to hear these called as "theory", and labeled as "unpractical". This couldn't be farther from the truth. Take a look at how I recommend studying distributed systems . Don't you dare call this "theory" and "unpractical". This lays the bedrock that you build your practice on. Don't skimp on the foundations. Don't build your home on quicksand. Keep your hands dirty, your mind cl Read more >> Linearizability: A Correctness Condition for Concurrent Objects - August 09, 2024 Image This paper is from Herlihy and Wing appeared in ACM Transactions on Programming Languages and Systems 1990. This is the canonical reference for the linearizability definition. I had not read this paper in detail before, so I thought it would be good to go to the source to see if there are additional delightful surprises in the original text. Hence, this post. I will dive into a technical analysis of the paper first, and then discuss some of my takes toward the end. I had written an accessible explanation of linearizability earlier; you may want to read that first. I will assume an understanding of linearizability to keep this review at reasonable length. Introduction I love how the old papers just barge in with the model, without bothered by pleasantries such as motivation of the problem. These are the first two sentences of the introduction. "A concurrent system consists of a collection of sequential processes that communicate through shared typed objects . This model encompass Read more >> Understanding the Performance Implications of Storage-Disaggregated Databases - July 23, 2024 Image Storage-compute disaggregation in databases has emerged as a pivotal architecture in cloud environments, as evidenced by Amazon ( Aurora ), Microsoft ( Socrates ), Google (AlloyDB), Alibaba ( PolarDB ), and Huawei (Taurus). This approach decouples compute from storage, allowing for independent and elastic scaling of compute and storage resources. It provides fault-tolerance at the storage level. You can then share the storage for other services, such as adding read-only replicas for the databases. You can even use the storage level for easier sharding of your database. Finally, you can also use this for exporting a changelog asynchronously to feed into peripheral cloud services, such as analytics. Disaggregated architecture was the topic of Sigmod 23 panel . I think this quote summarizes the industry's thinking on the topic. "Disaggregated architecture is here, and is not going anywhere. In a disaggregated architecture, storage is fungible, and computing scales independently. Read more >> Scalable OLTP in the Cloud: What's the BIG DEAL? - January 17, 2024 Image This paper is from Pat Helland, the apostate philosopher of database systems, overall a superb person, and a good friend of mine. The paper appeared this week at CIDR'24. (Check out the program for other interesting papers). The motivating question behind this work is: " What are the asymptotic limits to scale for cloud OLTP (OnLine Transaction Processing) systems? " Pat says that the CIDR 2023 paper "Is Scalable OLTP in the Cloud a Solved Problem?" prompted this question. The answer to the question? Pat says that the answer lies in the joint responsibility of database and the application. If you know of Pat's work, which I have summarized several in this blog , you would know that Pat has been advocating along these lines before. But this paper provides a very crisp, specific, concrete answer. Read on for my summary of the paper. Disclaimer: This is a wisdom and technical information/detail packed 13-page paper, so I will try my best to summarize the sa Read more >> Always Measure One Level Deeper - June 19, 2024 Image This is a great paper (CACM 2018) by John Ousterhout. Ousterhout is well known for his work on log-structured file system, tcl/tk, Raft, and magic VLSI CAD. His book on Philosophy of Software Design is great, and he has a lot of wisdom about life in general that he shares in his Stanford CS classes. The paper is written very well, so I lift up paragraphs verbatim from it to summarize its main points. There are many war stories in the text. Please do read it, because they are fascinating, and likely you can see how they can apply to your work, and save you from making a mistake. At the end, I chime in with my reflections and link to other relevant work. Key Insights In academic research a thorough performance evaluation is considered essential for many publications to prove the value of a new idea. In industry, performance evaluation is necessary to maintain a high level of performance across the lifetime of a product. A good performance evaluation provides a deep understanding of Read more >> Powered by Blogger Theme images by Michael Elkan Murat Demirbas My photo Murat I am a principal research scientist at MongoDB Research. Ex-AWS. On leave as a computer science and engineering professor at SUNY Buffalo. I work on distributed systems, distributed consensus, and cloud computing. You can follow me on Mastodon or Twitter. Visit profile Pageviews Recent Posts * August6 * July3 * June5 * May2 * April6 * March6 * February9 * January7 * December3 * November4 * October4 * September4 * August4 * July5 * June2 * May3 * April3 * March3 * February5 * January3 * December4 * November4 * October1 * September4 * August5 * July6 * June3 * May3 * April4 * March3 * February3 * January3 * December5 * November3 * October6 * September1 * August4 * July2 * June12 * May1 * April1 * March4 * February4 * January4 * December3 * November7 * October4 * September1 * August3 * July6 * June11 * May9 * April8 * March8 * February7 * January9 * December10 * November14 * October6 * September13 * July3 * June3 * May4 * April6 * March2 * February1 * January3 * December4 * November7 * October2 * September2 * August8 * July2 * June4 * May9 * April6 * March9 * February5 * January13 * December15 * November15 * October5 * September8 * August10 * July3 * June3 * May3 * April4 * February4 * January7 * December7 * November9 * October3 * September1 * July4 * June5 * May1 * April4 * March2 * February2 * January4 * December3 * November2 * October3 * September2 * August3 * June1 * May1 * April6 * March6 * February4 * January3 * November4 * October4 * September6 * August2 * July2 * June3 * March3 * February4 * January1 * December1 * November2 * August2 * July4 * June2 * May5 * April8 * January1 * December1 * November7 * October1 * September2 * August1 * May2 * March1 * February1 * January2 * December3 * September5 * June1 * May5 * April5 * March5 * February9 * January5 * December6 * November9 * October9 * September7 * August1 Show more Show less Topics 2PC1 abstraction3 AI2 analytics2 atomic storage1 auditability5 automated reasoning9 aws3 Azure11 benchmarks4 bestof7 big-data27 Blockchain39 book-review54 calm2 chaos2 cloud computing17 consistency31 Cosmos DB11 CosmosDB12 crdts1 data warehouse1 databases53 datacenter networking1 dataflow8 DDIA3 disaggregation1 distributed consensus46 distributed transactions35 distSQL8 facebook15 failures18 fault-tolerance42 formal methods12 graph-processing1 htap2 humans10 indexing3 isolation levels3 links2 mad-questions42 main-memory1 measuring1 metastability2 microservices2 misc109 mlbegin7 mldl26 mobile2 mongodb8 my advice17 my-paper10 networking1 newsql3 NoSQL2 OLAP2 OLTP6 paper-review149 paxos50 postgres1 presenting4 privacy1 programming6 query-processing1 RDMA2 reading-group23 reconfiguration3 research-advice50 research-question 44 Rust3 scheduling3 security1 seminar9 serializability1 serverless1 smartphones2 snapshot isolation3 sonification1 SQL6 stabilization6 statistics3 stream-processing10 teaching31 tensorflow11 time12 time synchronization3 tla51 tpbook1 transactions26 trip-report29 wpaxos5 writing29 Show more Show less