Berkeley DB Reference Guide:
Access Methods

PrevRefNext

Selecting an access method

The Berkeley DB access method implementation unavoidably interacts with each application's data set, locking requirements and data access patterns. For this reason, one access method may result in dramatically better performance for an application than another one. Applications whose data could be stored using more than one access method may want to benchmark their performance using the different candidates.

(¹öŬ¸®µðºñ ¾×¼¼½º ¸Þ¼Òµå ±¸ÇöÀº ¾ÖÇø®ÄÉÀ̼ÇÀÇ µ¥ÀÌŸ¼Â,¶ô ¿ä±¸»çÇ×,µ¥ÀÌŸ Á¢±ÙÆÐÅÏ°ú »óÈ£ÀÛ¿äÇÑ´Ù.ÀÌ°°Àº ÀÌÀ¯·Î ¾ÖÇø®ÄÉÀ̼ǿ¡¼­ ¾î¶² ¾×¼¼½º¸Þ¼Òµå´Â ´Ù¸¥ ¾×¼¼½º¸Þ¼Òµå¿¡ ºñÇØ ±ØÀûÀ¸·Î ¼º´ÉÀÌ Çâ»ó µÉ ¼ö ÀÖ´Ù.)

One of the strengths of Berkeley DB is that it provides multiple access methods with nearly identical interfaces to the different access methods. This means that it is simple to modify an application to use a different access method. Applications can easily benchmark the different Berkeley DB access methods against each other for their particular data set and access pattern.

(¹öŬ¸®µðºñ´Â °ÅÀÇ °°Àº ÀÎÅÍÆäÀ̽º¿¡ ´Ù¸¥ ŸÀÔÀÇ ¾×¼¼½º¸Þ¼Òµå¸¦ È£ÃâÇÒ¼ö Àֱ⠶§¹®¿¡ ¹êÄ¡¸¶Å·ÀÌ ½±´Ù.)

Most applications choose between using the Btree or Hash access methods or between using the Queue and Recno access methods, because each of the two pairs offer similar functionality.

(´ëºÎºÐÀÇ ¾ÖÇø®ÄÉÀ̼ÇÀº Btree ¶Ç´Â Hash ¸¦ ¼±ÅÃÇϰųª Queue ¶Ç´Â Recno ¸¦ ¼±ÅÃÇÑ´Ù.¿Ö³ÄÇÏ¸é °¢ ¾×¼¼½º¸Þ¼Òµå ½ÖÀº ºñ½ÁÇÑ ±â´ÉÀ» Çϱ⠶§¹®ÀÌ´Ù.)

Hash or Btree?

The Hash and Btree access methods should be used when logical record numbers are not the primary key used for data access. (If logical record numbers are a secondary key used for data access, the Btree access method is a possible choice, as it supports simultaneous access by a key and a record number.)

(hash,btree´Â ³í¸®ÀûÀÎ ·¹ÄÚµå¹øÈ£°¡ ÇÁ¶óÀ̸Ӹ® Å°°¡ ¾Æ´Ò¶§ »ç¿ëµÈ´Ù.¸¸¾à ³í¸®ÀûÀÎ ·¹ÄÚµå¹øÈ£°¡ ¼¼ÄÁ´õ¸® Å°·Î »ç¿ëµÈ´Ù¸é Btree¸¦ »ç¿ëÇÒ ¼ö ÀÖ°í ÀÌ Btree´Â Å°¿Í ·¹ÄÚµå¹øÈ£·Î µ¿½Ã¿¡ Á¢±Ù°¡´ÉÇÏ´Ù.)

¡¡

Keys in Btrees are stored in sorted order and the relationship between them is defined by that sort order. For this reason, the Btree access method should be used when there is any locality of reference among keys. Locality of reference means that accessing one particular key in the Btree implies that the application is more likely to access keys near to the key being accessed, where "near" is defined by the sort order. For example, if keys are timestamps, and it is likely that a request for an 8AM timestamp will be followed by a request for a 9AM timestamp, the Btree access method is generally the right choice. Or, for example, if the keys are names, and the application will want to review all entries with the same last name, the Btree access method is again a good choice.

(BtreeÀÇ Å°´Â Á¤·ÄµÇ¾î ÀúÀåµÇ°í Å°°£ÀÇ °ü°è´Â Á¤·Ä¼ø¼­·Î Á¤ÀǵȴÙ.ÀÌ°°Àº ÀÌÀ¯·Î Btree´Â Å°µé°£ÀÇ Áö¿ªÀû ÂüÁ¶°¡ ÀÖÀ»¶§ »ç¿ëµÈ´Ù.Áö¿ªÀûÂüÁ¶°¡ ÀǹÌÇϴ°ÍÀº Btree¿¡¼­ ƯÁ¤ÇÑ Å°¸¦ Á¢±ÙÇÏ´Â °ÍÀº ¾ÖÇø®ÄÉÀ̼ÇÀÌ Á¢±ÙµÇ°í ÀÖ´Â Å°¿Í Á¤·Ä¼ø¼­¿¡¼­ ±ÙÁ¢ÇÑ ´Ù¸¥Å°¸¦ Á¢±ÙÇÏ´Â °æÇâÀÌ ÀÖÀ½À» ¸»ÇÑ´Ù.¿¹¸¦µé¾î Å°µéÀÌ Å¸ÀÓ½ºÅÆÇÁ¶ó¸é 8AMŸÀÓ½ºÅÛÇÁ¸¦ ¿ä±¸ÇÑ ÈÄ¿¡´Â 9AM ŸÀÓ½ºÅÛÇÁ·Ñ ¿ä±¸ÇÒ °ÍÀÌ´Ù.ÀÌ·±°æ¿ì Btree°¡ ¿Ã¹Ù¸¥ ¼±ÅÃÀÌ´Ù.¶Ç´Ù¸¥ ¿¹·Î Å°°¡ À̸§ÀÌ¸é ¾ÖÇø®ÄÉÀ̼ÇÀº °°Àº ¼ºÀ» °¡Áø ¸ðµç ¾ØÆ®¸®¸¦ º¸°í ½Í¾îÇÒ°ÍÀÌ°í ÀÌ°æ¿ìµµ Btree°¡ ÁÁÀº ¼±ÅÃÀÌ´Ù.)

¡¡

There is little difference in performance between the Hash and Btree access methods on small data sets, where all, or most of, the data set fits into the cache. However, when a data set is large enough that significant numbers of data pages no longer fit into the cache, then the Btree locality of reference described previously becomes important for performance reasons. For example, there is no locality of reference for the Hash access method, and so key "AAAAA" is as likely to be stored on the same database page with key "ZZZZZ" as with key "AAAAB". In the Btree access method, because items are sorted, key "AAAAA" is far more likely to be near key "AAAAB" than key "ZZZZZ". So, if the application exhibits locality of reference in its data requests, then the Btree page read into the cache to satisfy a request for key "AAAAA" is much more likely to be useful to satisfy subsequent requests from the application than the Hash page read into the cache to satisfy the same request. This means that for applications with locality of reference, the cache is generally much more effective for the Btree access method than the Hash access method, and the Btree access method will make many fewer I/O calls.

(ÀÛÀº µ¥ÀÌŸ¼Â(ij½Ã¿¡ ¸ðµç ¿£Æ®¸®°¡ À§Ä¡µÉ¼ö ÀÖÀ» Á¤µµÀÇ Å©±â)¿¡ ´ëÇÑ Btree¿Í Hash»çÀÌ¿¡´Â ¾à°£ ¼º´ÉÂ÷°¡ ÀÖ´Ù.±×·¯³ª µ¥ÀÌŸ¼ÂÀÌ ±²ÀåÈ÷ Ä¿¼­ ij½Ã¿¡ µ¥ÀÌŸÆäÀÌÁö°¡µé¾î°¥¼ö ¾ø°ÔµÇ¸é BtreeÀÇ Áö¿ªÀû ÂüÁ¶´Â ¼º´ÉÀÇ Áß¿äÇÑ ¿ä¼Ò°¡ µÈ´Ù.¿¹¸¦µé¾î Çؽ¬´Â Áö¿ªÀûÂüÁ¶°¡ ¾ø¾î¼­ Å° "AAAAA"´Â "ZZZZZ"Å°¿Í °°Àº ÆäÀÌÁö¿¡ ÀúÀåµÈ´Ù.BtreeÀÇ °æ¿ì "ZZZZZ"Å°º¸´Ù´Â "AAAAB"Å°¿¡ ±ÙÁ¢ÇÑ°÷¿¡ ÀúÀåµÈ´Ù.±×·¡¼­ ¸¸¾à ¾ÖÇø®ÄÉÀ̼ÇÀÌ Áö¿ªÂüÁ¶À¸·Î µ¥ÀÌŸ¿äûÀ» ÇÏ°Ô µÇ¸é Å°¿¡´ëÇÑ ¿äû󸮸¦ À§ÇØ  ij½Ã¿¡ ·ÎµùµÇ´Â BtreeÆäÀÌÁö´Â ¾ÖÇÃÀÇ ÀÌÈÄ ¿äû¿¡ Çؽ¬¹æ½Äº¸´Ù ÈξÀ È¿À²ÀûÀÌ´Ù.ÀÌ°ÍÀÌ ÀǹÌÇÏ´Â °ÍÀº Áö¿ªÂüÁ¶¼ºÀÌ ÀÖ´Â ¾ÖÇÿ¡ ´ëÇؼ­´Â Çؽ¬¸Þ¼Òµåº¸´Ù Btre¸Þ¼Òµå°¡ ij½Ã¸¦ ÈξÀ À¯¿ëÇÏ°Ô »ç¿ëÇÏ°Ô µÇ°í Btree¾×¼¼½º¸Þ¼Òµå´Â ÈξÀ ÀûÀº I/O È£ÃâÀ» ÇÏ°Ô µÈ´Ù.)

However, when a data set becomes even larger, the Hash access method can outperform the Btree access method. The reason for this is that Btrees contain more metadata pages than Hash databases. The data set can grow so large that metadata pages begin to dominate the cache for the Btree access method. If this happens, the Btree can be forced to do an I/O for each data request because the probability that any particular data page is already in the cache becomes quite small. Because the Hash access method has fewer metadata pages, its cache stays "hotter" longer in the presence of large data sets. In addition, once the data set is so large that both the Btree and Hash access methods are almost certainly doing an I/O for each random data request, the fact that Hash does not have to walk several internal pages as part of a key search becomes a performance advantage for the Hash access method as well.

(±×·¯³ª µ¥ÀÌŸ¼ÂÀÌ ¸Å¿ìÄ¿Áú¶§ Çؽþ׼¼½º¸Þ¼Òµå´Â Btree¾×¼¼½º¸Þ¼ÒµåÀÇ ¼º´ÉÀ» ´É°¡ÇÑ´Ù.ÀÌ·¯ÇÑ ÀÌÀ¯´Â Btree´Â Çؽ¬µðºñº¸´Ù ´õ¸¹Àº ¸ÞŸÆäÀÌÁö¸¦ °¡Áö°í Àֱ⠶§¹®ÀÌ´Ù.µ¥ÀÌŸ ¼ÂÀÌ Å©°ÔµÇ¸é ¸ÞŸÆäÀÌÁö´Â BtreeÀÇ Ä³½¬¸¦ ³Ñ¾î¼­°Ô µÈ´Ù.ÀÌ°ÍÀÌ ¹ß»ýÇϸé Btree´Â ij½Ã¿¡ ÀÖ´Â µ¥ÀÌŸÆäÀÌÁö°¡ ±ØÈ÷ ÀÛÀ» °¡´É¼ºÀÌ Àֱ⶧¹®¿¡ °¢ µ¥ÀÌŸ¿äû¿¡ ´ëÇØ I/OÀ» °­Á¦·Î ¹ß»ý½Ãų ¼öµµ ÀְԵȴÙ.Çؽ¬¾×¼¼½º¸Þ¼Òµå´Â ¸ÞŸÆäÀÌÁö°¡ Àû±â¶§¹®¿¡ ij½Ã¿¡´Â ¸¹Àº µ¥ÀÌŸ¼ÂÀÌ ÀְԵȴÙ.Ãß°¡ÀûÀ¸·Î µ¥ÀÌŸ¼ÂÀÌ ¾ÆÁÖÅ©¸é Btree,hash´Â °ÅÀÇ ·£´ý µ¥ÀÌŸ¿äû¿¡´ëÇØ ÇϳªÀÇ I/OÀ» ¹ß»ý½ÃŲ´Ù.Çؽ¬°¡ Å°°Ë»ö¶§ ¿©·¯ ÆäÀÌÁö ¼øȸ¸¦ ÇÊ¿ä·Î ÇÏÁö ¾Ê±â ¶§¹®¿¡ À̰ͶÇÇÑ Çؽ¬ÀÇ ÀåÁ¡ÀÌ´Ù.)

Application data access patterns strongly affect all of these behaviors, for example, accessing the data by walking a cursor through the database will greatly mitigate the large data set behavior describe above because each I/O into the cache will satisfy a fairly large number of subsequent data requests.

(¾ÖÇø®ÄÉÀ̼ÇÀÇ µ¥ÀÌŸÁ¢±ÙÆÐÅÏÀº ÀÌ·¯ÇÑ ¸ðµç ÇàÀ§¿¡ ¿µÇâÀ» ¹ÌÄ£´Ù.¿¹¸¦µé¾î Ä¿¼­¸¦ »ç¿ëÇÏ¿© µðºñ µ¥ÀÌŸ¸¦ »ç¿ëÇϴ°ÍÀº Å«µ¥ÀÌŸ¼Â¿¡ ´ëÇÑ À§¿¡¼­ ¼³¸íµÈ ÇàÀ§µéÀ» ¾ÈÈ­½ÃŲ´Ù.¿Ö³ÄÇϸé ij½Ã¿¡ µé¾î°¡´Â °¢ I/OÀº ÀÌÈĹ߻ýÇÏ´Â ¸¹Àº µ¥ÀÌŸ¿äûÀ» ¸¸Á·½ÃŲ´Ù.(¿ªÀÚÁÖ:Áï Ä¿¼­¸¦ »ç¿ëÇϸé ÇѹøÀÇ I/OÀ¸·Î ¸¹Àº µ¥ÀÌŸ¼ÂÀÌ Äɽÿ¡ ÀְԵȴÙ.Ä¿¼­´Â ÆÄÀÏÀÇ Æ¯Á¤·¹Äڵ带 °¡¸£Å°´Â °´Ã¼))

In the absence of information on application data and data access patterns, for small data sets either the Btree or Hash access methods will suffice. For data sets larger than the cache, we normally recommend using the Btree access method. If you have truly large data, then the Hash access method may be a better choice. The db_stat utility is a useful tool for monitoring how well your cache is performing.

(µ¥ÀÌŸÁ¢±ÙÆÐÅÏ°ú ¾ÖÇø®ÄÉÀ̼ǵ¥ÀÌŸ¿¡ ´ëÇÑ Á¤º¸°¡ ¾øÀ»¶§ÀÇ °í·Á»çÇ×Àº ´ÙÀ½°ú °°´Ù. ÀÛÀºµ¥ÀÌŸ¼Â¿¡ ´ëÇؼ­´Â Btree,hash ¾î¶²°Íµµ ÃæºÐÇÏ´Ù.ij½Ãº¸´Ù µ¥ÀÌŸ¼ÂµéÀÌ Å¬°æ¿ì´Â ÀϹÝÀûÀ¸·Î Btree¸¦ ÃßõÇÑ´Ù.¸¸¾à ±²ÀåÈ÷ Å« µ¥ÀÌŸ¸¦ °¡Áö°í ÀÖ´Ù¸é À̶§´Â Çؽð¡ ÁÁÀº ¹æ¹ýÀÌ´Ù.ij½Ã ÆÛÆ÷¸Õ½º´Â db_stat À¯Æ¿À» »ç¿ëÇÏ¿© ¸ð´ÏÅ͸µµÉ¼ö ÀÖ´Ù.)

Queue or Recno?

The Queue or Recno access methods should be used when logical record numbers are the primary key used for data access. The advantage of the Queue access method is that it performs record level locking and for this reason supports significantly higher levels of concurrency than the Recno access method. The advantage of the Recno access method is that it supports a number of additional features beyond those supported by the Queue access method, such as variable-length records and support for backing flat-text files.

(Queue or Recno ´Â ³í¸®ÀûÀÎ ·¹ÄÚµå¹øÈ£°¡ µðºñÁ¢±ÙÀÇ primaryÅ°·Î »ç¿ëµÉ¶§ »ç¿ëµÈ´Ù.QueueÀÇ ÀåÁ¡Àº ·¹Äڵ巹º§ ¶ôÀ» ½ÇÇàÇÑ´Ù´Â Á¡ÀÌ´Ù. ÀÌ·¯ÇÑ ÀÌÀ¯·Î Recnoº¸´Ù µ¿½Ã¼ºÀÌ ¿ùµîÈ÷ ÁÁ´Ù.RecnoÀÇ ÀåÁ¡Àº Queue °¡ Á¦°øÇÏ´Â ±â´É¿¡ µ¡ºÙ¿© ¿©·¯ ±â´ÉÀ» Á¦°øÇÑ´Ù.¿¹¸¦µé¾î °¡º¯±æÀÌ ·¹ÄÚµå ¿Í backing flat-textÆÄÀÏ Áö¿øµî..)

Logical record numbers can be mutable or fixed: mutable, where logical record numbers can change as records are deleted or inserted, and fixed, where record numbers never change regardless of the database operation. It is possible to store and retrieve records based on logical record numbers in the Btree access method. However, those record numbers are always mutable, and as records are deleted or inserted, the logical record number for other records in the database will change. The Queue access method always runs in fixed mode, and logical record numbers never change regardless of the database operation. The Recno access method can be configured to run in either mutable or fixed mode.

(³í¸®ÀûÀÎ ·¹ÄÚµå¹øÈ£´Â º¯°æ(·¹ÄÚµå Ãß°¡,»èÁ¦½Ã ·¹ÄÚµå¹øÈ£µéÀÌ º¯°æ)µÇ°Å³ª °íÁ¤(¾î¶² µðºñ ¿ÀÆÛ·¹À̼ǿ¡µµ º¯°æµÇÁö ¾ÊÀ½)µÉ¼ö ÀÖ´Ù.Btree¿¡¼­ ³í¸®ÀûÀÎ ·¹ÄÚµå ¹øÈ£·Î µ¥ÀÌŸ¸¦ ÀÐÀ» ¼ö ÀÖ´Ù.±×·¯³ª ÀÌ ·¹ÄÚµå¹øÈ£´Â Ç×»ó º¯°æ(·¹ÄÚµåÀÇ »ðÀÔ,»èÁ¦½Ã)µÈ´Ù.Queue´Â Ç×»ó °íÁ¤¸ðµå°í µ¿ÀÛÇÏ°í ³í¸®ÀûÀÎ ·¹ÄÚµå¹øÈ£´Â µðºñ ¿ÀÆÛ·¹À̼ǽà º¯°æµÇÁö ¾Ê´À´Ù.Recno´Â º¯°æ,°íÁ¤¸ðµåÁßÀÇ Çϳª·Î ¼³Á¤µÉ¼ö ÀÖ´Ù.)

In addition, the Recno access method provides support for databases whose permanent storage is a flat text file and the database is used as a fast, temporary storage area while the data is being read or modified.

(Ãß°¡ÀûÀ¸·Î Recno´Â ¿µ±¸ÀúÀå¼Ò°¡ flat-text fileÀÎ µðºñ¸¦ Áö¿øÇÏ°í ÀÌ µðºñ´Â µ¥ÀÌŸ°¡ Àаųª ¼öÁ¤µÉ¶§ ºü¸¥ Àӽà ÀúÀå¼Ò·Î »ç¿ëµÈ´Ù.)


PrevRefNext

Copyright (c) 1996-2003 Sleepycat Software, Inc. - All rights reserved.