Downloaded 21 times
![Query language
SELECT [attributes] FROM [entity]
WHERE [path](=|<|<=|>|>=) [value] AND …
ORDER BY [path] LIMIT [count]
Conjunctive queries with simple predicates and ordering
Higher level queries can be composed by the application](https://image.slidesharecdn.com/sigmod2014presentation-160523135616/85/Automated-Schema-Design-for-NoSQL-Databases-22-320.jpg)
Uploaded byMichael Mior
Automated Schema Design for NoSQL Databases
The document discusses automated schema design for NoSQL databases, particularly focusing on Cassandra, addressing challenges such as storage costs and schema optimization for specific workloads. It outlines the need for a workload-driven approach and details methods for index selection and query planning. Future work includes expanding to other NoSQL databases and improving query plan implementations.
More Related Content
Similar to Automated Schema Design for NoSQL Databases
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
Automated Schema Design for NoSQL Databases
- 1. Automated Schema Designfor NoSQL Databases Michael J. Mior Supervised by Kenneth Salem
- 2. Schema optimization For agiven workload, construct the optimal physical schema to answer queries in the workload for a given storage budget
- 3. What is NoSQL? ●Not SQL? ● NoACID? ● Not only SQL
- 4. Types of NoSQLDatabases ● Document stores ● Key-value stores ● Graph databases ● … ● Wide column stores
- 5.
- 6. Cassandra data model Queriesspecify A set of row keys and either A list of column keys or A prefix of the column keys with a range
- 7. Cassandra schema design Physicalschema POIsWithHotels POI17 Hotel3 “Holiday Inn” … … No single obvious mapping from the conceptual schema Conceptual schema Hotel PointOfInterest Near Hotel8 “Motel 6”
- 8. Cassandra schema design POIsWithHotels POI17 Hotel3 “HolidayInn” … … HotelsWithPOIs Hotel3 POI17 “Liberty Bell” … … ● Multiple choices of logical and physical schema are possible for a given conceptual schema ● Different choices are more suitable for different queries ● Harder to add additional structures in the future
- 9. Cassandra schema design POIs POI17 Name “LibertyBell” … … Hotels Hotel3 Name “Holiday Inn” … … HotelToPOI Hotel3 POI17 (null) … … POIToHotel POI17 Hotel3 (null) … …
- 10. Cassandra schema design POIToHotel POI17 Hotel3 “HolidayInn” … … HotelToPOI Hotel3 POI17 “Liberty Bell” … … HotelToPOI HotelID POIID (null) … … POIToHotel POIID HotelID (null) … …
- 11. Challenges ● Storage costs ●View maintenance ● Transactions ● Data distribution
- 12. Relational schema design ●Commercial database vendors have existing tools ○ Microsoft AutoAdmin for SQL Server ○ DB2 Design Advisor ○ Oracle SQL Tuning Advisor ● These tools don’t solve all the problems for NoSQL databases ● Usually an existing schema is assumed, and tools suggest secondary indices and materialized views
- 13. Relational schema design Conceptualschema Logical schema Physical schema Hotel CREATE TABLE Hotel(…); CREATE TABLE POI(…); CREATE TABLE HotelToPOI(…, FOREIGN KEY (HotelID) REFERENCES Hotel(HotelID) FOREIGN KEY (POOID) REFERENCES POI(POIID) ); CREATE MATERIALIZED VIEW POIsWithHotels AS SELECT POI.*, Hotel.* FROM POI, HotelToPOI, Hotel WHERE HotelToPOI.HotelID = Hotel.HotelID AND HotelToPOI.POIID = POI.POIID; Mapping from conceptual to logical schema is straightforward Near PointOfInterest
- 14. Cassandra schema design Physicalschema POIsWithHotels POI17 Hotel3 “Holiday Inn” … … No single obvious mapping from the conceptual schema Conceptual schema Hotel Near Hotel8 “Motel 6” PointOfInterest
- 15.
- 16. Query paths Get allpoints of interests near hotels a guest has stayed at SELECT Name FROM POI WHERE POI.HotelToPOI .Hotel.Room.Reservation .Guest.GuestID = ? Guest Reservation Room Hotel Point of Interest
- 17. Index paths ● Queriescan “skip” entities on a path using an index ● Indices to the final entity are equivalent to materialized views ● Schema design is now the selection of these indices Guest Reservation Room Hotel Point of Interest
- 18. Problem definition Input: ● ERdiagram with entity counts and cardinalities ● Weighted queries over the diagram ● Storage constraint ● Cost model for target DB Output: ● Suggested index configuration ● Plans for executing each query
- 19. Proposed solution 1. Enumeratepossible useful indices for all queries 2. Determine the benefit of a given index for each query 3. Select the optimal indices for a given space constraint
- 20. Future Work ● Retargetingto other NoSQL DBs ● Automatic implementation of query plans ● Handling workloads which include updates ● Richer query language ● Exploitation of DBMS-specific features
- 21. Summary ● Schema designin NoSQL databases presents unique challenges ● A workload-driven approach is necessary ● Conceptual schemata and queries are viable abstractions for NoSQL schema design tools
- 22. Query language SELECT [attributes]FROM [entity] WHERE [path](=|<|<=|>|>=) [value] AND … ORDER BY [path] LIMIT [count] Conjunctive queries with simple predicates and ordering Higher level queries can be composed by the application
- 23. Solution Index Enumerator Query Planner Index Selection Indexbenefit analysis Query Plans Selected IndicesWorkload Input Output
- 24. Implementation ● Focus onCassandra as target system ● Simple cost model for read-only in-memory workloads ● DBMS-independent index enumerator and query planner ● Index selection ILP implemented with GLPK
- 25. Evaluation - TBD ●Re-implement existing workloads in the target DBMS (e. g. RUBiS, RUBBoS) ● Develop new benchmarks ● Comparison with a human DBA ● Random ER diagrams/queries with realistic properties