1 / 15

NFS on a Database: Structure and Performance

NFS on a Database: Structure and Performance. Alan Halverson Babis Samios. Motivation. Goal: NFS Server / Database Backend Why Database? Transactions provide idempotency naturally Graceful backup/recovery Why NFS? Nearly universal client availability

nedaa
Download Presentation

NFS on a Database: Structure and Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NFS on a Database: Structure and Performance Alan Halverson Babis Samios

  2. Motivation • Goal: NFS Server / Database Backend • Why Database? • Transactions provide idempotency naturally • Graceful backup/recovery • Why NFS? • Nearly universal client availability • Transparent access for existing applications • Ease of implementation

  3. Approach • Implement standard UNIX file API • open(), read(), write(), etc. • All routines talk to the database • Modify NFS server to use new API • … • Profit!

  4. Main Results • Efficient Implementation is Possible • Same order of magnitude with native file system for read/write operations • Choice of Database Schema is Important • Server Cache Usage is Critical • Avoids database round-trips

  5. Roadmap • Approach • NFS server choices • Databases choices • Architecture/Design • Experimental Setup & Results • Summary/Conclusions

  6. Database Choices • Many available DBMS’s • We chose PostgreSQL • Free, open source • Inspiration for our work was the Inversion File System – also implemented on top of Postgres • Uses client/server model

  7. NFS Server Choices • Kernel mode • Pros: included in Linux, supports NFS v3 • Cons: difficult to debug • User mode - UNFSD • Pros: Easier to debug, comm. with PostgreSQL possible! • Cons: Only supports NFS v2 • Our choice: User mode

  8. Architecture

  9. Database Schema • meta-data -> file_attributes • dir hierarchy -> naming • data -> Many options • Table/File (used by Inversion FS) • Single Table (avoids table creation overhead) • Intermediate solutions (e.g. table/dir)

  10. Single Table Schema file_attributes 1 1 1 N N N naming all_files

  11. Caching • Old Story: Client Side Caching • Buffer cache • New Story: Server Side Caching • Minimize the number of round-trips to the DB by maintaining three different caches: • Stat cache • Naming cache • Buffer cache (significantly beneficial only in a multi-client environment) Major Contribution

  12. Binary Data • SQL statements issued to PostgreSQL must contain ASCII data only • Provides escaping function • escape(data) ≤ 4 x data • We used base64 encoding • base64(data) = 4/3 x data • Best case raw write performance is 4/3 of native file system write performance

  13. Experimental Setup

  14. Summary/Conclusions • Design and implementation of NFS operating on top of PostgreSQL • Use of 3-tier architecture for maximum flexibility • Performance comparable to native UNIX FS for read/write operations • Factors that affect performance • Caching (both server and client side) • Chunk size and NFS r/w message size • Database Schema

  15. Things we will not do • Asynchronous database writes (for both data and meta-data) • Compare recovery times with both ext2 and ext3 • Test multi-client environment • Add mechanism for querying system meta-data

More Related