맛있는 DB, 버클리 데이터베이스를 아시나요? (R)eference 2008. 11. 5. 15:10
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

 

버클리 데이터베이스는 트랜잭션을 관리해 주는 소스가 개방된 라이브러리형 데이터베이스로서 확장성과 성능이 뛰어나다. 다음 그림은 버클리 데이터베이스가 일반적인 관계형 데이터베이스와 어떤 구조적인 차이점이 있는지 잘 설명해 준다.

일반 관계형 데이터베이스는 독립된 프로그램으로 구성되어 애플리케이션과 따로 동작하면서 애플리케이션과 네트워크가 ‘inter process communication’을 통해 자료를 주고받는다. 하지만 버클리 데이터베이스는 컴파일 시 애플리케이션에 링크되어 애플리케이션의 메모리 어드레스를 함께 사용한다. Locking, 로그 관리, 메모리 관리 등과 같은 기본적인 모든 데이터베이스의 작동이 라이브러리 내에서 수행되고, 멀티 프로세스 또는 프로세스에 있는 멀티 쓰레드는 동시에 데이터베이스를 사용할 수 있다.
결과적으로 프로세스 간 통신이 사라지게 되어 시스템의 전체적인 구조가 간단해진다. 당연히 버클리 데이터베이스는 일반적으로 널리 사용되고 있는 언어인 Java, C, C++, Perl, Tcl, Phthon 그리고 PHP의 API를 제공해 준다.

또한 버클리 데이터베이스는 많은 플랫폼을 지원한다. 모든 유닉스와 리눅스 플랫폼, MS-Windows 플랫폼, 32bit, 64bit 플랫폼, 하이엔드 인터넷 서버(High-end Internet Server)나, 데스크톱 시스템, 노트북 등 모든 곳에서 운용이 가능하다고 볼 수 있다.

버클리 데이터베이스는 다음과 같은 기본적인 기능을 수행한다.

 

1. Page cache management
불필요한 I/O를 줄임으로써 빠른 데이터 접근을 지원한다.
2. Transaction and logging
데이터베이스 복구를 보장한다.
3. Locking
여러 사용자에 의한 다중 읽기 및 쓰기(multiple read/write)를 보장한다.

특히, 일반적인 관계형 데이터베이스와 차별화된 내용은 다음과 같다.

1. SQL 개념의 질의문은 지원되지 않는다.
2. 객체 지향적(Object Oriented)으로 설계되어 있지 않다.(버클리 데이터베이스는 C로 짜여졌다).
3. Network 기능이 없다.
4. 데이터베이스 서버가 아니다.

현재 버클리 데이터베이스는 4.2.X가 최신 버전이다. 비록 프리웨어지만, DB라는 이름에 걸맞게 여러 유틸리티 프로그램도 함께 제공한다.

#ls bin
db_archive*
db_checkpoint*
db_deadlock*
db_dump*
db_load*
db_printlog*
db_recover*
db_stat*
db_upgrade*
db_verify*
 

라이브러리의 구조는 다음과 같다.

#ls lib
db.jar
libdb-4.2.a
libdb-4.2.la
libdb-4.2.so*
libdb-4.so@
libdb.a
libdb.so@
libdb_java-4.2.a
libdb_java-4.2.la
libdb_java-4.2.so*
libdb_java-4.2_g.so@
libdb_java-4.so@
libdb_java.so@

해더 파일들은 무척이나 간단하다.

#ls include
db.h
db_cxx.h

 

버클리 데이터베이스는 데이터를 어떻게 관리할까? 먼저 데이터의 구조는 무척이나 간단하다. 데이터 파일에 저장되는 레코드의 구조는 다음과 같다.

SQL의 테이블, 컬럼 구조에 익숙한 개발자라면 위 표에서 Key, Value 구조의 막막함이 느껴질 것이다. 하지만 잘 짜여진 데이터 구조가 바탕에 있다면 Key, Value의 간단, 명료함은 그 가치를 나타낼 것이다.
위의 구조는 Java 객체중 Properties 객체와 유사하다. 이 구조를 바탕으로 데이터베이스는 레코드 삽입, 삭제, 수정, 그리고 찾기 기능을 수행한다.
여기서 알아두어야 할 중요한 사항은 Value 부분에 대해서는 전혀 오퍼레이션을 하지 않는다는 것이다. Value는 Key로 구분되는 데이터일뿐이다. 이는 Value 부분에 대한 찾기 기능이 없다는 뜻으로 특정 Value를 찾고자 한다면 그 Key 값이 무엇인지를 먼저 알아야 한다.

Key와 Value에 대한 특징은 다음과 같다.

1. Byte 형태의 값을 갖는다.
2. 길이는 고정적이거나 가변적이다.
3. Key나 Value에 대한 형태는 프로그래머에 의해 결정된다.
4. 최대크기는 4GB

네 가지 주요 특징 가운데 세 번째 특징은 프로그래머에게는 부담이 될 수도 있다. 버클리 데이터베이스는 Key와 Value를 의미가 없는 단순한 ‘byte string’으로 인식하고 그에 대한 정보를 하나도 갖고 있지 않기 때문이다. 따라서 Key와 Value가 의미를 갖기 위해서는 프로그래머가 미리 구조를 설계한 후 그 구조에 맞게 Key와Value 값을 가공하여 사용해야 한다. Key와 Value 구조를 모른다면 그 데이터베이스는 의미없는 Byte 덩어리일 뿐이다.

C나 C++로 개발하는 프로그래머일 경우에는 Struct 문장을 사용하여 Key와 Value 구조를 정의하여 사용할 수 있다. 개발 언어가 Java일 경우에는 Object Serialization을 통해 손쉽게 객체를 처리할 수 있다.

 

Key와 Value에 대한 정보가 없다는 것은 개발자나 애플리케이션의 측면에서 볼 때 넘어야 할 걸림돌이다. 모든 것을 프로그래머가 책임져야 한다. 하지만 이러한 특징을 역으로 생각한다면 Key 값과 Value 값에는 어떠한 값이든 넣을 수 있다는 또 다른 가능성도 같이 제공해 준다. 그림이나 사운드든 파일이나 문서든 데이터 형태에 구분받지 않고 Key와 Value 값으로 사용할 수 있는 셈이다. 물론 대부분의 관계형 데이터베이스도 이러한 기능을 지원해 준다.
지금까지는 버클리 데이터베이스가 일반 관계형 데이터베이스와 어떻게 다른지 간략하게 살펴보았다. 그럼 이제부터는 프로그래머가 맛있어 하는 소스를 맛보도록 하겠다. 다음 프로그램은 버클리 데이터베이스를 사용한 간단한 레코드 삽입 프로그램이다. 얼핏보면, isam을 이용한 자료 처리 프로그램과 유사하다.

● 레코드 입력 프로그램 <코드 1>

프로그램<코드 1>을 라인별로 간단히 설명해 보겠다.

12 라인 - 버클리 데이터베이스를 참조하기 위한 객체를 생성한다.
13 라인 - 에러 메세지가 출력될 스트림을 설정한다.
14 라인 - 에러 메세지에 출력될 메세지 prefix
15 라인 - 데이터 파일을 생성하거나 이미 존재하면 그것을 사용한다.


여기서 Open 함수 API의 정확한 정의는 다음과 같다.

public void open(DbTxn txnid, String file,
String database, int type, int flags, int mode)
throws DbException, FileNotFoundException

4번째 파라미터인 Db.DB_BTREE에 대해서는 다음 기회로 미루겠다.

17~30 라인 - Dbt라는 객체를 통해 데이터 파일에 있는 Key/Value를 사용할 수 있다. 24(29), 25(30) 라인에서는 각각 Byte 데이터와 크기를 설정했다.
33 라인 - Key 값과 Value 값을 데이터 파일에 저장한다. 이때 사용한 플래그는 Db.DB_NOOVERWRITE이다. 이 플래그가 설정되면 이미 존재하는 키 값을 저장할 경우 에러가 발생하고, Db.DB_ KEYEXIST 에러 값을 리턴한다. 기본적으로 버클리 데이터베이스는 오류가 없으면 0을 반환하게 되어 있다. 만약 에러가 발생한다면 0 이상의 값을 반환한다.
36 라인 - 데이터베이스 사용을 마친다. 만약 close를 입력하지 않는다면 저장한 데이터는 파일에 기록되지 않고 사라지게 된다. 이는 저장된 자료가 파일이 아닌 메모리의 캐시 영역에 저장되고 사용되기 때문이다. 따라서 추후 사용을 위해 반드시 close 함수나, sync() 함수를 호출해야 한다.

저장을 했으니, 이제 조회를 할 차례다.

● 레코드 조회 프로그램 <코드 2>

프로그램<코드 2>에 대해 라인별로 간단히 설명해 보겠다.

22, 23, 24 라인 - 데이터 검색을 위해 Key 값에 대해서만 찾고자 하는 값을 설정했다.
30 라인 - get method를 호출하여 검색을 한다. 해당되는 Key 값을 갖는 자료를 발견하면, Value 객체에 해당되는 값이 들어간다.
33 라인 - Value Dbt 객체에서 데이터를 갖고와 String으로 저장한다.

앞서 예로 든 두개의 프로그램은 버클리 데이터베이스의 저장 및 조회 프로그램의 기본적인 구조를 보여준다. 여기서 소개된 예제 프로그램은 기본에 충실한 간단한 것이다. 하지만 버클리 데이터베이스가 그리 간단하게 돌아가는 것은 아니다. 이번에는 소개를 하지 못했지만, 기본적인 사용법을 벗어난 다음과 같은 고급 기능들도 있다.
고급 기능에 대한 자세한 설명은 다음 기회로 미루고 이번에는 버클리 데이터베이스에 대한 첫 소개의 기회로 삼을까 한다.

1. cursor를 사용한 데이터 처리
2. DBEnv 객체를 이용한 데이터베이스 환경 사용
3. 4가지의 데이터 접근 방법(BTREE, HASH, QUEUE, REC_NO)
4. Object 객체화
5. Join 검색
6. Dbt의 파생 클래스
7. Sleepycat의 새로운 collection API
8. 트랜잭션 처리
9. locking
10. 로깅 관리
11. 데이터베이스 복구

 
,
Tuning the Solaris OS for Streaming Media Applications (R)eference 2008. 11. 5. 14:40
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
By Agnes Jacob and Kelly Kishore, May 2002  

Introduction

Streaming media technology emerged as the web evolved from static to dynamic content. Many companies, educational institutions, and service and content providers have been using the web to broadcast live presentations, movies, concerts, educational programs, news, sports, and advertisements. Streaming technology allows these types of content to be viewed as it is transmitted without having to download the entire content onto client's local storage.

There are two types of streaming:

  • True Streaming uses RTP and RTSP (Real Time Protocol and Real Time Streaming Protocol) as the transport protocols, and there is a dedicated server where the source (multimedia files or live broadcast) is transmitted and viewed by the client.
  • Progressive Download uses HTTP (Hyper-Text Translation Protocol) as the transport protocol, with a regular web server. In this method, a portion of the video is downloaded onto the client's storage and begins playing before it is completely downloaded.

Multimedia files are usually compressed and encoded in certain formats on the server end and then decompressed and decoded by a media player on the client side. The formats that currently can be streamed include RealNetworks (*.rm), Windows Media (*.wmv, *.asf), QuickTime (*.mov), MPEG (*.mpg), audio files (*.mp3), and other video files (*.mp2).

Either type of streaming or multimedia source requires a scalable and efficient server with a fast storage solution and good network bandwidth to address the needs of streaming media applications. This paper describes how to tune servers running on the Solaris Operating Environment to improve performance for streaming media applications. These suggestions are based on observations while working with ISVs (independent software vendors) developing streaming media applications. The things to consider when tuning a server for media applications include network, I/O, and local and remote file systems.

Network Tuning

To take advantage of high-speed networks and thus increase network throughput, the Solaris platform offers tunable parameters for UDP and TCP, which are the underlying protocols for RTSP, RTP, and HTTP. The UDP and TCP tunables that are beneficial to streaming media applications relate to window size, buffer size, and checksumming.

Setting the TCP window size or UDP socket buffer size to the application read or write call size minimizes the fragmentation of the packets in the transport layer. For example, if the application server sends out or writes out 32 Kbyte, and the UDP socket buffer size is set to 8 Kbyte, then the server will break this 32-Kbyte request into 8-Kbyte packets before sending it over the network. By setting the UDP receive and send buffer size or TCP window size, you will reduce the overhead by reducing fragmentation and thus increase performance.

The tunables for UDP that would modify the socket buffer size include:

  • udp_xmit_hiwat - maximum UDP socket datagram in bytes (Default=8192)

  • udp_recv_hiwat - maximum UDP socket receive buffer size in bytes (Default=8192)

  • udp_max_buf - controls how large send and receive buffers (in bytes) can be for a UDP socket. This should be set to a value higher than the previous tunables, otherwise an error will be returned. (Default=256*1024)

The tunables for TCP that modify the window size include:

  • tcp_xmit_hiwat - maximum value of the TCP send window size in bytes (Default=16384)

  • tcp_recv_hiwat - maximum value of the TCP receive window size in bytes (Default=24576)

  • tcp_max_buf - controls how large the send and receive buffers can be (in bytes). This should be set to a value higher than the previous tunables, otherwise an error will be returned. (Default=1048576)

You can use ndd to modify these values. For example:

ndd -set /dev/udp udp_xmit_hiwat <value_in_bytes>

To maintain these settings across reboots, you should put a line for this in the file /etc/rc2.d/S69inet:

  #
  # Set configurable parameters.
  #
  ndd -set /dev/tcp tcp_xmit_hiwat  65536

Another way you could achieve a performance boost is to turn OFF this udp tunable:

  • udp_do_checksum - This enables UDP checksumming to ensure data integrity. (Default=1)

If your network card already has some sort of hardware checksumming, then this feature can be turned off to avoid double checks. Use ndd to turn this off (for example, ndd -set /dev/udp udp_do_checksum 0).

It is important to note that currently UDP is the desired protocol for streaming media because it does not make acknowledgments of packets or retransmissions. Since the audio or video is being listened to or viewed as it is transmitted, retransmission of lost bytes is not necessary. Also, if the stream can be multicasted (sent to one or more clients), UDP is the only protocol that supports this mode.

For Solaris servers that have Sun GigaSwift Ethernet adapter network cards (only supported in the line of servers that run on UltraSPARC III® processors), there are device driver parameters to consider for possible PCI interperformance improvements. The effects on performance vary among different applications, and it would be good to try out different values for these parameters.

The device parameters include:

  • tx_dma_weight - multiplication factor for granting priority to the transmit (TX) side during a weighted round-robin arbitration. The weight values are power of 2. (Default=0)

  • rx_dma_weight - multiplication factor for granting priority to the receive (RX) side during a weighted round-robin arbitration. The weight values are power of 2. (Default=0)

These tunables control the priority access to the PCI. For example, if the tx_dma_weight = 0 and the rx_dma_weight = 3, then the RX traffic will have 8 times greater priority over TX traffic.

Another device driver parameter adjustment that may improve performance is to turn on infinite_burst:

  • infinite_burst - allows the adapter to not free the bus until packets are transferred across the bus (Default=0)

For large packets, turning this parameter ON could be beneficial. Use ndd to set these device parameters or set these values in the ce.conf file. (For example, with ndd -set /dev/ce <parameter> <value>, you need to set the instance number to select the device if multiple devices are active.)

In addition, for good bus performance with Sun GigaSwift Ethernet adapters, use a 66-MHz, 64-bit PCI slot to take advantage of the faster, wider bus. Also, select a slot that does not share bus bandwidth with other slots.

I/O Tuning

Multimedia files can be located local to the server, on a remote server, or on a SAN (storage area network). For streaming media applications, sequential read/write access is the most predominant I/O disk operation since the multimedia files are stored on disk before they are transmitted (except for live broadcast). Thus selection and configuration of the storage device are factors that can affect overall performance. Configuration of your I/O disk devices as stripe or utilizing hardware stripe (RAID 0, RAID 5) would be optimal for sequential access since the data can be spread across several disks and retrieved in parallel. If you choose to configure the disks as stripe, the stripe size should be a multiple of the read/write size to make the access more efficient.

The numerous ways to optimize I/O are beyond the scope of this paper; however, these two books are good references for planning disk layout:

  • Configuration and Capacity Planning for Solaris Servers, Brian Wong, Sun Microsystems Press, 1997 

  • Sun Performance and Tuning, Java and the Internet, 2nd Edition, Adrian Cockcroft and Richard Pettit, Sun Microsystems Press, 1998

File System Tuning

The types of file systems that are supported on the Solaris Operating Environment include UFS, VxFS, QFS, and NFS (for remote files). For each of these file system types, there are tuning considerations that relate to directio and blocksize. Also, for NFS, other NFS tunables and parameters can be set for better NFS throughput.

If your streaming media application accesses very large files and does not redistribute the same file often, mounting the file system with the directio option will increase file access performance. Mounting the file system with the directio option bypasses the kernel buffer cache (paged I/O) when reading and writing to disk. This reduces the CPU overhead considerably since the read/write goes directly to disk instead of copying the data between the kernel buffer and user buffer. For an I/O operation to be performed as direct I/O, it must meet the alignment criteria. The read/write request must be aligned to a sector, block size, or stripe size boundary, or it will buffer the I/O. Use mount with forcedirectio option to mount the file system as directio (for example, in UFS: mount -F ufs -o forcedirectio <device> <mountpt>).

Multimedia files consisting of high bit rate audio and video can be in the gigabyte file size range. Tuning the file system block size or extent size can definitely improve performance for larger files. Currently the maximum block size or extent size supported for UFS and VxFS, respectively, is 8 Kbyte. For larger files, there is an extra layer of indirection to access the rest of the data or an increase in the number of data blocks or extents used per file; this creates extra overhead when accessing large files. QFS, however, supports variable block sizes up to a maximum of 32 Mbyte. For a 64-Mbyte file, it requires only 2 data blocks to represent this file, however, in UFS or VXFS it would require 8000 data blocks or extents to represent this file, and it would require another level of indirection. Thus, consider using the largest possible block sizes when creating the file system. Use the mkfs command with the correct option for each of the file systems to set the block size.

Files on a remote server reside on a network file system (NFS). The overall performance of NFS is affected by the underlying file system type, I/O (disk layout), network bandwidth, and performance of the remote server. However, you can consider NFS (network file system) tunables to improve NFS throughput.

One tunable is:

  • nfs3_max_transfer_size - maximum size of the data portion of an NFS version 3 READ, WRITE, READDIR, or READDIRPLUS request (Default=32KB)

It would be best to tune the maximum transfer size to the size of the data being passed over the network, for example, the read/write I/O request size. However, depending on the configuration of the remote server and network bandwidth, you need to tune this value as closely as you can to the read/write I/O request size without degrading performance on the server. If you modify this parameter, you would also need to modify the parameter nfs3_bsize, otherwise the over-the-wire request size would be limited to the nfs3_bsize.

  • nfs3_bsize - the logical block size used by the NFS version 3 client. This block size represents the amount of data that the client attempts to read from or write to the server when it needs to do an I/O. (Default=32KB)

These NFS tunables need to be applied to both the client and server. For UDP, there is a hard limit of 64 Kbyte per datagram (including headers and data) for the max_transfer_size.

To modify these values, you would need to set them in the /etc/system file, and it would require a reboot for the values to take effect. For example, the contents of /etc/system could be:

nfs:nfs3_max_transfer_size=65536
nfs:nfs3_bsize=65536

Also, increasing the number of NFS threads (nfsd) on a server enables the server to handle more NFS requests in parallel. For streaming media applications that require access to remote files, setting this to a higher value would provide increased NFS throughput. How to set this parameter would depend on the size of the server. A rule of thumb is to take the maximum of the following:

  1. Use 16 to 32 NFS threads for each CPU.
  2. Use 2 NFS threads for each active client.
  3. Use 16 NFS threads for each 10 Mbit of network capacity.

To set the NFS threads, you would need to modify the /etc/init.d/nfs.server to start nfsd with the specified amount of threads.

Summary

As streaming media technology continues to expand and grow, different demands and needs will arise, and system tuning will change to address these needs. This paper focuses on parameters you can tune for streaming media applications on servers running on the Solaris platform. Other tunable parameters may exist for enhancing performance for these applications. However, so far, these are the tuning suggestions that we have found to produce the greatest improvement in performance for streaming media applications on these servers.

References

  • Sun Performance and Tuning, Java and the Internet, 2nd Edition, Adrian Cockcroft and Richard Pettit, Sun Microsystems Press, 1998 

  • Configuration and Capacity Planning for Solaris Servers, Brian Wong, Sun Microsystems Press, 1997 

  • "NFS Server Performance and Tuning Guide for Sun Hardware," Sun Microsystems, 2000 

  • "Platform Notes: Sun GigaSwift Ethernet Device Driver" from Solaris 8 10/01 on Sun Hardware Collection, Sun Microsystems, 2001 

  • "QFS - Technical Overview v3.4/3.5," LSC, Inc. (now Sun Microsystems), March 9, 2000 

  • "Solaris Tunable Parameters Reference Manual" from Solaris 8 10/01 Update Collection, Sun Microsystems, 2001 

  • "VxFS System Administrator's Guide," VERITAS Corporation, 2000 

About the Authors

Agnes Jacob is a staff engineer in Sun Market Development Engineering, working with ISVs to improve performance of their applications on Sun servers by means of tuning and sizing studies. Her experience includes kernel development in the areas of file system, I/O, and network file system, as well as Java technology.

Kelly Kishore has been working with streaming media technologies since 2000. At Sun, he is currently in Market Development Engineering, working with digital media customers.

May 2002
,

티스토리툴바