Recent Posts
Java | 4 sec ago
C | 6 sec ago
None | 15 sec ago
None | 23 sec ago
None | 30 sec ago
PHP | 30 sec ago
None | 57 sec ago
None | 1 min ago
None | 1 min ago
None | 1 min ago
Sitereport
Find cool info about any domain on the internet?
visit sitereport
Free Subdomains
Want a pastebin.com sub-domain for your community?
learn more...
What is pastebin?
Pastebin is a website that hosts all your text & code on dedicated servers for easy sharing.
learn more...
Learn a little bit about the new Pastebin.com on our help page. hide message
By Janbur on the 9th of Feb 2010 08:16:36 PM Download | Raw | Embed | Report
  1. I am in charge of a DB scalability project that I thought I had under wraps, but just discovered a roadblock in MySQL that prevents my strategy from working. I know it sounds pathetic, but I'm desperate for some guidance on this one. I even paid a DB expert for a day of consulting on this issue and he came up with essentially the same plan that I had. Here is the situation that I have:
  2.  
  3. Consider a library that needs a database to track book checkouts. There is one table currently for all of these, the schema resembles:
  4.  
  5.         section_id, book_id, member_id, checkout_ts, checkin_ts (and a unique constraint is placed across section_id, book_id, member_id, and checkout_ts)
  6.  
  7. A member checks out a book from a particular section at the checkout_ts and when the book is returned, the checkin_ts is populated. Each of these records is held in the library checkout tracking software until the checkin occurs, so all of these fields will always be populated in the database. There are no IDs for these records because of the volume of records there are (potentially 500M+). The original author of this database didn't want the space taken up by the IDs.
  8.  
  9. Because the interface to this database is a web interface, and the usage model is real-time reporting on book checkout statistics, the query time has to be especially low. My plan to tackle this was to partition the table based on the book_id. The benchmarks for this were very positive and this was my plan until about 20 minutes ago. It was then I discovered that there is a partition limit in MySQL of 1024 partitions. There are potentially 10's of thousands of books in the database, so my plan is now shot.
  10.  
  11. I also tried partitioning by the checkin_ts with a range of approximately every 90 days, but the performance wasn't quite there and MySQL complained when I tried to put the unique constraint in place. This constraint is needed because of the risk in library checkout tracking software of messing up and putting duplicate checkouts for a user when a false checkin is entered. Unfortunately, there's not much I can do about that part of it either.
  12.  
  13. So, now I'm left with no ideas whatsoever to address the performance issues on this database. Is there something that I'm missing that is obvious? I'm mediocre at DB design and SQL, but this is beyond my capabilities. Is there a kind soul out there with more knowledge than I that could possibly lend a hand?
Submit a correction or amendment below. Make A New Post
To highlight particular lines, prefix each line with @h@
Syntax highlighting:
Post expiration:
Post exposure:
Name / Title:
Email: