Advanced topics in database systems (CSC2531), Fall 2011


Course Description

This course is a reading seminar with a focus on the intersection of database engines and modern hardware. Topics include non-traditional database engine designs, cache- and multicore- aware algorithms, hardware acceleration for database operations (e.g. FPGA and GPU), as well as flash and other storage new technologies.

Administrivia

Instructor: Ryan Johnson
Lectures: Tue 9:00-11:00 in BA 2179
Office: BA 5226
TA: Mo Sadoghi (office hours TBD)
Office hours: TBA in BA 5226 (or by appointment)
Instructor telephone: 416 946-7069
Course email: csc2531-f11@cs.utoronto.ca
Course web page: http://www.cs.utoronto.ca/~ryanjohn/teaching/csc2531-f11/

Course structure

This course is a reading seminar, and most of the work consists of reading, summarizing, and discussing research papers (2-3 per week). Participation counts heavily; all students are expected to come to class having read assigned papers for the week. To this end, a concise write-up is due at the beginning of each class, with full marks awarded to those which indicate the student is prepared to contribute to the day's discussions (in other words, don't just hand in an extended summary of the paper). Please be aware that this is meant to be a real discussion. You are allowed, even encouraged, to question assumptions and disagree with others (politely!). Being "wrong" will only cost you participation marks if it is blatantly clear that you didn't read the paper and are making things up as you go.

Each week a pair of students will present to the class a summary and critique of the week's readings, with open discussions to follow. Students presenting papers in the same week are encouraged to select papers which complement or contrast each other. Time permitting, we will dedicate a few minutes of each lecture to feedback on the presentations themselves. In addition to receiving marks for the presentation they deliver, students will receive marks based on the quality of feedback they give to their peers. Positive feedback (identifying things done well) is just as important as the negative feedback we usually give and receive.

Clever algorithms are necessary but usually insufficient to produce a successful systems design. Therefore, in addition to the readings, each student (in groups of two) will complete a programming project which aims to either reproduce or extend the state of the art in a relevant area. The project forms an important, hands-on part of the learning process, hence original research, while always encouraged, is not required. Students are welcome to incorporate their own ongoing research as long as they make clear what work they will accomplish during the course. The project mark will be based on a design document, 1-2 milestones to encourage students to keep on track, the presentation and final report, and the completeness and quality of the deliverables.

There is no final exam; the final project (code and write-up) will be due during finals week, with students giving a brief (~15 minute) presentation of their work during the last last lecture of the semester.

Tentative schedule

Over the twelve week course we will cover ten fixed topics (listed below). Mo and I will lead the first discussion, and the day's write-up will be generated during class.

Several papers are available for each theme; the students presenting at each lecture will choose 2-3 papers with 1-2 weeks notice. During the remaining week we will (re)visit topics of particular interest to the students. Please indicate your preliminary preferences regarding in-class presentations using this Doodle poll. I had to make it a hidden poll for privacy reasons, but we'll discuss the results in class and hammer out a final schedule based on your input.

Breakdown of marks

The course mark will be broken down into the categories listed below, with points assigned as indicated:

WeightItemMinimal markModerate markHigh mark
30%ParticipationPresentTalkativeInsightful comments or questions
20%PresentationsFactually correctDesigned and delivered wellTransmits effectively key points, implications, etc.
15%Written critiquesAccurate summary of paper, or list of facts from itIdentifies important pointsThoughtful analysis/critique that informs the discussion
5%Quality of feedback to peersFocus on nitpicks and minutiaeSuggest incremental improvementsIdentify structural strengths and flaws
30%Final projectUnambitious and/or badly plannedPartially implemented and/or poorly presentedImplemented successfully with key learning points presented

Many of the above criteria are cumulative. For example, there is nothing wrong with pointing out minutiae in a peer's presentation, as long as it does not overlook more important issues.

Project proposals

The project proposal (due 18 Oct) should contain the following information: I'd normally expect the above to occupy 2-4 pages, but word counts are not the priority here.

Announcements and clarifications