# scalability of table lookup

Stu Weibel (weibel@oclc.org)
Mon, 7 Jun 93 13:42:26 EDT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Tim Berners-Lee: "Re: Suggest meaning for URN"
- Previous message: Keith Moore: "dereferencing URNs"
- Next in thread: Tim Berners-Lee: "Re: scalability of table lookup"
- Maybe reply: Tim Berners-Lee: "Re: scalability of table lookup"
- Maybe reply: Ed Krol: "Re: scalability of table lookup"
- Maybe reply: Stu Weibel: "Re: scalability of table lookup"
- Maybe reply: Chris Weider: "Re: scalability of table lookup"
- Maybe reply: Ed Krol: "Re: scalability of table lookup"
- Maybe reply: Chris Weider: "Re: scalability of table lookup"

    Date: Mon, 7 Jun 93 13:42:26 EDT

    From: weibel@oclc.org (Stu Weibel)

    Message-Id: <9306071742.AA17037@ora.rsch.oclc.org>

    To: uri@bunyip.com

    Subject: scalability of table lookup

> I have two thoughts and no real conclusions. First consider OPACs. Every
> OPAC stores this much data (and more) for its holdings and does lookups
> for patrons all the time (granted they are sometimes slow). So in this
> model, once you find a server it is relativly easy to symbolically look
> up something and find its location. Note that libraries have not solved
> the problem of "Where in the world do I find this book?". You need to
> pick the server and just try servers until you find one which has what
> you want. What we are trying to do is solve this problem.

In fact, libraries have solved this problem, at least the part of the
problem relevant to this discussion. The OCLC Online Union Catalog
contains roughly 28 million records (including who holds the items)
representing some 500 or 600 million items; this system supports Inter
Library Loan (ILL) for any member library. The aspects of ILL that
don't work so well have to do with physical delivery and lending
agreements which have little to do with our problem.

I don't believe this is really a scaling problem.

> What we don't necessarily have is a fast solution.

How fast is fast? Is there a consensus here as to what constitutes
acceptable performance? 100 or 200 transactions a second is a very
reasonable target for servers of this kind (we routinely achieve 200
transactions per second on our cataloging system). The apparent speed
to the user/application would, of course, be dependent on load.

stu

- Next message: Tim Berners-Lee: "Re: Suggest meaning for URN"
- Previous message: Keith Moore: "dereferencing URNs"
- Next in thread: Tim Berners-Lee: "Re: scalability of table lookup"
- Maybe reply: Tim Berners-Lee: "Re: scalability of table lookup"
- Maybe reply: Ed Krol: "Re: scalability of table lookup"
- Maybe reply: Stu Weibel: "Re: scalability of table lookup"
- Maybe reply: Chris Weider: "Re: scalability of table lookup"
- Maybe reply: Ed Krol: "Re: scalability of table lookup"
- Maybe reply: Chris Weider: "Re: scalability of table lookup"