1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Which Storage Solution for DBMS

Discussion in 'Sun Hardware' started by Louis, Aug 27, 2003.

  1. Louis

    Louis Guest

    Hi,

    We have a constantly updated relational database with mostly random writes
    and reads.
    The database size will be 60 GB in total. It will run in a UNIX (IBM or SUN)
    environment.

    We want to splitt up the database in a Read Only (RO) and a Read Write (RW)
    database (probably running on 1 server). Clients will access (query) the RO
    database. The RW and RO databases will be switched every hour. So the RW
    becomes RO and vise versa. The new RO database now contains the newest data.
    The new RW database will be updated with the transaction log (which will be
    fast).

    Now we need to decide on purchasing disk storage.

    1. The RO storage (60 GB) needs maximum read performance. It doesn't need to
    be failsafe,
    if the RO crashes we can switch to the RW or vise versa to service the
    end-users. In the
    meantime we can recover the crashed diskset.
    2. The RW storage (60 GB) needs maximum read/write performance. It doesn't
    need to be fail-safe.
    3. Then we need several fail-safe filesystems to store transaction logs.
    Let's say 2 * 40 GB.
    4. Also we need storage (200 GB) for other things.

    For the RO/RW storage, do we buy 2 fast 60 GB disks or should we consider
    for example RAID 0 with 5 * 20GB disks.
    Or do we buy an integrated storage solution ? Important is that the RO and
    RW storage is as fast as possible.

    Please advise.

    Regards,

    Louis Banens
     
    Louis, Aug 27, 2003
    #1
    1. Advertisements

  2. Your need depends on the number of users and transactions per time unit.

    A single 15000 Rpm disk will give you approx 170 - 200 random accesses
    per second. IIRC the TPC-C benchmark transaction was 27 accesses.
    That should then give you maximum some 6 to 7 transactions per second.
    from a single disk. ( provided it does not do something else as well )

    If you know the number of diskaccess per transaction in your app
    you will ofcourse end up at a different result.

    How large is your user community ?
    How many transactions per hour can they practically produce ?
    Are you doing Batch runs ? (basically producing transactions As Fast as Possible)

    If you are going to use the RO part as a datawarehouse it will be almost impossible
    to size. If you allow someone to type " select *item from whatever "
    and you have to read the complete database to satisfy the query, performance is gone.


    Always buy more disks than you need ! ( You will grow ! )
     
    Lars Tunkrans, Aug 27, 2003
    #2
    1. Advertisements

  3. Louis

    mis Guest

    mis, Sep 7, 2003
    #3
  4. How random is "random"? If it's going to be clustered such that requests
    will typically be "close" to each other, then max out on ram.

    And if you can help queries by having indexes, again max out on ram. The
    aim is to minimise the need to access the disk, so disk speed won't
    matter.

    Cheers,
    Wol
     
    Anthony W. Youngman, Sep 8, 2003
    #4
  5. If it is unrealistic to have 60GB of RAM to cache the data, then it
    will surely be necessary to do _something_ on the disk side of things.

    Things like FibreChannel disk arrays seem highly helpful to this end;
    battery-backed cache on the array can provide _massive_ improvements
    in per-transaction update times, as the array can treat transaction
    updates as "committed" as soon as they are cached, instead of having
    to wait until the disk actually rotates to the appropriate location.

    A few hundred KB of cache on the controller could be very helpful;
    move it to a few hundred MB and it's all the better :).
     
    Christopher Browne, Sep 8, 2003
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.