In the early 1990s, most business intelligence vendors felt obliged to describe their product architectures as “client/server”, whether or not this was accurate, simply to sound modern. By the late 1990s, they had all switched to calling their products “Web-enabled” or “thin-client”. Of course, the Web is just another form of client/server, and one that is more complex to implement.
数据挖掘论坛
So, why should applications be client/server? Is there any purpose in it? We would contend that it is only worth the complexity and expense of implementing a true client/server solution if there are real, provable benefits.
There are basically two sets of benefits that should accrue:
数据挖掘论坛
better sharing of data and computer facilities
optimized performance at minimized cost. 数据挖掘实验室
The sharing arises because data and applications on the server can be shared in a managed way, without duplication. Other resources on the server can also be made accessible to multiple users, without having to duplicate them. These system resources could include hardware (printers, fax cards, CD-ROM drives, tape drives, remote communication cards, RAM, disk, CPU cycles) and software (database programs, etc). Sharing software may save costs but has the further advantage that it need not be installed and administered on each client machine.
In general, it is most efficient if a resource on the server is (apparently) simultaneously shared between multiple users. Thus, if several users are accessing the same data in a database, there should be one set of shared data caches in memory, not individual ones for each user. This form of sharing reduces costs (less total RAM required) and improves performance (updated data is immediately available to other users without waiting for a file write and read). In practice, this level of sharing usually requires the server to be multi-threaded, and most modern servers are. However, older products with Unix or VMS roots usually are not, which tends to mean that they use server RAM less effectively in a multi-user environment.
Optimized performance can be delivered by moving as little data across bottlenecks as possible. A complex computer system can be regarded as something like an oil refinery, with data being pumped between many processes, sometimes along long lengths of pipeline. Bottlenecks can arise anywhere in the system, and the entire process will run no faster than the speed of the tightest bottleneck.
数据挖掘交友
Computer hardware designers go to immense lengths to balance the performance of the machine, with memory caches installed wherever a bottleneck is likely. For example, a typical modern PC usually has several memory caches. There is usually a hardware cache on the disk controller, because disk access is one of the slowest processes on a computer, so the most recently changed data is held in a cache so that it can be read again quickly. Some caches also hold data that is to be written to the disk, so that the processor does not have to wait for the drive to place data physically on the disk platters. There will usually also be a software disk cache (of perhaps several megabytes) with a similar function. This is because the bus that links the processor and disk controller is also a bottleneck, so the cache on the disk controller alone is not enough. Then, because even main RAM is slower than the processor itself, so there is usually a separate fast L2 memory cache of at least 512Kb and possibly multiple megabytes. Finally, even within the processor itself, there is always a small very high speed L1 cache. 数据挖掘交友
All of this cleverness can be nullified if a networked application has to move large amounts of data across LAN bottlenecks, because, in most cases, the narrow LAN bandwidth makes it the tightest bottleneck of all. This is even worse if a WAN (wide area network) is used. Worst of all is a dial-up connection to the Internet. We have, therefore, paid close attention to how much data has to pass through the tightest bottlenecks in the networked system.
In The OLAP Report, we are not covering the actual systems technologies involved in implementing client/server applications. OLAP applications use the same standard technologies like HTTP and RPC (remote procedure calls) that are used by other client/server applications, and normal expertise in those areas will be needed in the installation. However, OLAP applications can be more demanding of client/server technologies than normal reporting applications because they manipulate larger amounts of data, so it important not only that the technology be implemented correctly, but that the logical structure of the application across the client and the server be correct.
数据挖掘工具
