on 6/25/02 17:03, Andreas Grosam at agrosam /at/ computerworks .D.O.T ch wrote:
>> I have think about this in next way:
>>
>> in ideal DBMS must test on start or on request the
>>
>> Client characteristics (HDD, RAM)
>> Server characteristics (HDD, RAM)
>> Network between them,
>>
>> Deal is that if network is dialup most probably better keep data on Server,
>> But if this is 1GB Ethrernet, we have network transfer faster than modern
>> HDD read/write, so why not to have for such pair move data to client as
>> default option.
>
> This is a good idea, but IMO it is difficult to determine these
> characteristics. Choosing an approach which automatically leads to the best
> performance and which is independend on certain hardware characterstic is
> probably the better approach:
>
> Caching records in the client space is preferable for better performance, but
> requires more memory in the client - of course.
Agree.
BTW Andreas. I am 100% sure that mySQL do not have Server-based cursors. As
I understand this means that all data of cursor must be transferred to
client and mySQL do not create tmp table on Server never.
> Caching records in the client shall be allways optionally - and hidden to the
> application.
> The client may choose to use a backing store for its cache, thus - having a
> slow connection and restricted amounts of memory, it might choose to purge
> records on disk instead throwing it away and then re-loading it from the
> server if needed.
Agree. In fact this issue point on ability to have 2 types of clients
1) thing client -- small code, only connection to server, may have RAM based
cache
2) fat client -- contain in fact the whole Valentina kernel, so is able
create on local HDD database for caching of data.
Even more, this FAT Client could act as Server itself, then we get
distributes system.
> Settings for the client cache could be made through an application preference.
>
> For instance, having a "scrollable cursor" - that is a cursor with random
> access iterator capability, should store its records on the client side for
> performance reasons - if possible. The client determines how mutch cache it
> has - if it has no cache - then the records can not be saved on the
> valentina-client side - or the client of the "valentina-client" - say the
> application - itself is responsible for allocating the records somewhere
> after fetching it.
>
> (In an embedded dbms, the cache for client and server part is simply shared
> between the to parts.)
>
> Whether there is a slow or fast connection - this is irrelavent to the
> relative performance. An ideal caching algorithm would avoid loading from the
> client and also (on the client side) loading from disk.
>
> The caching algorithm shall be designed by assuming that the load time is in
> that order (faster comes first:)
> client-cache client-chache-backing-store server
>
> The only case where this might lead to suboptimal performance is when a client
> cache is using backing store, the RAM cache is set to zero or minimum and if
> the local disk is slower then the network and the average load time on the
> server side (either from its cache or from its local disk).
>
> For fast networks with typicall low traffic, it is not required to use a
> client-cache backing store. However, it might reduce network traffic.
All this is good.
But again, in dbs exists client-side cursors and server side cursors.
I have not study deeply yet them, but I believe this means that DATA of
cursor are located on Client or Server.
And I know that mySQL do not have Server side cursors, so they simply load
on client all data of query and then do fetch() from client computer.
If this is not true, then I need understand better what means a "server side
cursor"...
> Well, in the case of "sensitive" cursors, that is cursors which might/shall
> see changes made from other transactions to the database, caching records in
> the client side might not be applicable. In order to avoid too complex client
> and server parts (this would essentially mean distributed dbms!), the server
> needs to controll what "value" a record has by tracking it only on the server
> side.
>
> However, for sensitive cursors which shall see changes made from within the
> same transaction - and NOT made from other transactions - records might be
> cached in the client space anyway. (This assumes, that a certain transaction
> is not distributed accross several clients - we are not talking about
> distributed transaction, for now :) - or do we?)
Nope.
--
Best regards,
Ruslan Zasukhin [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan@paradigmasoft.com
web: http://www.paradigmasoft.com
To subscribe to the Valentina mail list
send a letter to valentina-on /at/ lists .D.O.T macserve.net
-------------------------------------------------------------
©2002 Ruslan Zasukhin |
