Clients and Servers

Download Report

Transcript Clients and Servers

Database scalability eras
Unlimited Users
n-tier Internet Client/Server
Business components, servlets...
3-tier Internet Client/Server
pooling connection
1000s of Users
Mainframe
3-tier Internet Client/Server
single stateless connection per CGI call
100s of Users
2-tier Client/Server
user=process
LAN based
Max users depends upon file-handles
Several Users
Single User
PC based
Single user
Late 1980s
PC based, file-level locking
Single user or Peer-to-Peer
Mid-1990s
Now
Time
File sharing (Local) Databases
•
•
•
•
•
FoxPro, Paradox, Microsoft Access
limited Database Management System
Minimal Setup and Configuration
Low Cost
Some Rely on OS file-level
File sharing: Paradox example
File sharing: Paradox limits
Table and Index Files
127
Tables open per system
64
Record locks on one table (16Bit) per session
255
Record locks on one table (32Bit) per session
255
Records in transactions on a table (32 Bit)
Open physical files
512
(DB, PX, MB, X??, Y??, VAL, TV)
300
Users in one PDOXUSRS.NET file
255
Number of fields per table
255
Size of character fields
2
Billion records in a table
2
Billion bytes in .DB (Table) file
10800
Bytes per record for indexed tables
32750
Bytes per record for non-indexed tables
127
Number of secondary indexes per table
16
Number of fields in an index
255
Concurrent users per table
256
Megabytes of data per BLOB field
100
Passwords per session
15
Password length
63
Passwords per table
159
Fields with validity checks (32 Bit)
63
Fields with validity checks (16 Bit)
http://www.delphifaq.com/fq/q0003.shtml
File sharing weaknesses
• Can’t handle high concurrency
– realistic max concurrent users = 10
• Can’t handle large datasets
– because relying on OS to store the data
• Can’t handle complex joins
– struggles with multiple files open
• Often a single point of failure
– eg: Pdoxusr.net
File sharing weaknesses
• Index corruption frequent
• No commit
– the database IS the data in the file
• No rollback facility
Clients and Servers
• What is a Client?
– Device that request information: application or
files
– PC or workstation which is connected to a
network:
• LAN
• Intranet
• Internet
– Runs against a server which houses the
application, database or files
– Fat (Thick) or Thin
Clients and Servers
• Fat client
– Usually a PC, attached to a server
– The user has the ability to run applications
independently from the server
– Server mainly functions as a file, or data server
– In a traditional 2-tier client/server application
environment , the processing load is split
between client and server.
Clients and Servers
• Database Fat client
– The majority of the logic runs on the
client, which typically send SQL requests
to the server-resident database. This
architecture is called fat client because
most of the application runs on the client
side.
• Example solution: Oracle Forms
Clients and Servers
• Thin client
– performs very little data processing
– Basic keyboard input and screen output
– All application processing is done on the
server
– Does not store anything locally
– Similar to a dumb terminal in a
mainframe environment
Issues with databases clients
Fat Client Applications
Thin Client Applications
File sharing versus C/S Databases
File sharing
Client Server
For small databases
Few concurrent users
Network traffic light
If data is read only
If data isnt transaction in
nature
Small companies with limited
resources
Where skills are in short
supply
One of software purchase so
licensing not an issue
Mediun to Large databases
Unlimmited user base
Heavy traffic
Read-Write data
Transactional data
Finances can be found for IS
projects
DBAs employed
Often licensed per user
Database systems in Tiers
• 3-tier
– In the current incarnation:
• Database Server
• Application Server
• Client
– Advantages:
• separation of business logic
• Scalability
• Robust
Database systems in Tiers
• So how many tiers is a Web enabled
database?
• See Hugh’s session on Webservers
BC4J Alternative (simplified)
Appserver
Browser HTTP
JSP
Runtime
Environment
BC4J Application
Module
DB
server(s)
View Object
<jsp:useBean >
One or more physical servers
How many tiers is right?
• Whatever the architecture the
questions remain:
– where do we best store the data?
– Where do we best manipulate the data?
– How do we best present the data?
Real time databases: Is there a future for
the HDD?
• In-memory databases
– Data is cached in memory
– This reduces CPU intensive disk i/o
– TimesTen claim 1/10 the CPU
instructions for identical operations
– Eliminates the need for buffering by
pointing at records in memory
– Far speedier execution path
calculation
Real time databases: Is there a future for
the HDD?
• MOUNTAIN VIEW, Calif.— December 10,
2001—TimesTen Performance Software today
announced the unprecedented results of a
performance benchmark powered by the new 4.3
release of TimesTen’s in-memory database product
running on a Sun Microsystems, Inc. Sun Fire™
4800 Midframe server with the Solaris™ 8
Operating Environment. The combined products
delivered throughput levels of 10.3 million
records read, 2.53 million records updated, and
1.96 million records inserted per minute.
Real time databases: Is there a future for
the HDD?
• MOUNTAIN VIEW, Calif.— December 10,
2001—TimesTen Performance Software today
announced the unprecedented results of a
performance benchmark powered by the new 4.3
release of TimesTen’s in-memory database product
running on a Sun Microsystems, Inc. Sun Fire™
4800 Midframe server with the Solaris™ 8
Operating Environment. The combined products
delivered throughput levels of 10.3 million
records read, 2.53 million records updated, and
1.96 million records inserted per minute.
http://www.timesten.com/products/wp.html
Real time databases: Is there a future for
the HDD?
•
•
•
•
•
HDD used to store logs and backups
Can look like any c/s SQL database
can connect using ODBC, JDBC etc
available for most current OS
Addressable memory restrictions mean
that on 32-bit OS, the max database is
2GB
• On 64-bit the max is described as “10s”
of GB