Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Database engine
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Component of a database management system}} A '''database engine''' (or '''storage engine''') is the underlying software component that a [[database management system]] (DBMS) uses to [[create, read, update and delete]] (CRUD) [[data]] from a [[database]]. Most database management systems include their own [[application programming interface]] (API) that allows the user to interact with their underlying engine without going through the user interface of the DBMS. The term "database engine" is frequently used interchangeably with "[[database server]]" or "database management system". A "database instance" refers to the processes and memory structures of the running database engine. ==Storage engines== {{Seealso|Comparison of MySQL database engines}} Many of the modern DBMS support multiple storage engines within the same database. For example, [[MySQL]] supports [[InnoDB]] as well as [[MyISAM]]. Some storage engines are [[Database transaction|transactional]]. {| class="wikitable" |- ! Name !! License !! Transactional || Compatibility || Notes |- | [[Aria (storage engine)|Aria]] || [[GPL]] || {{No}} || [[MariaDB]] and [[MySQL]] |- | [[Falcon (storage engine)|Falcon]] || GPL || {{Yes}} || MySQL || Discontinued |- | [[InnoDB]] || GPL || {{Yes}} || MySQL and MariaDB || The default for MySQL and MariaDB |- | [[Memory (storage engine)|Memory]] || GPL || {{No}} || MySQL and MariaDB |- | [[MyISAM]] || GPL || {{No}} || MySQL || Was the default for MySQL |- | [[InfiniDB]] || GPL || {{No}} || |- | [[TokuDB]] || GPL || {{Yes}} || MySQL and MariaDB || Uses [[fractal tree index]] |- | [[WiredTiger]] || GPL || {{Yes}} || [[MongoDB]] || Default for MongoDB |- | [[XtraDB]] || GPL || {{Yes}} || MariaDB and [[Percona Server for MySQL]] |- | [[RocksDB]] / [[MyRocks]] || [[GNU_General_Public_License#Version_2|GPL v2]] or [[Apache_License|Apache 2.0]] || {{Yes}} || [[ArangoDB]], [[Apache Cassandra|Cassandra]], MariaDB, MongoDB, MySQL, SurrealDB |} Additional engine types include: * [[Embedded database]] engines * [[In-memory database]] engines ==Design considerations== Information in a database is stored in the form of bits, laid out into [[Data structure|data structures]] on storage hardware. These data structures are designed for efficient reads and writes to and from the storage hardware. Typically the storage hardware itself is designed to meet the requirements of various systems, including databases, that extensively utilize storage. An operating [[Dbms|DBMS]] always utilizes several storage types simultaneously. These different storage types, such as [[flash memory]] and external [[Hard disk drive|disk storage]], each require different data layout methods. In principle, database storage can be viewed as a [[linear address space]] where every bit of data has a unique address. In practice, only a very small percentage of addresses are kept as initial reference points, which also require storage. Most data is accessed instead by [[indirection]] using displacement calculations (distance in bits from the reference points) and data structures which define access paths (using pointers) to all needed data in an effective manner, optimized for the needed data access operations. ===Database storage hierarchy=== A database, while in operation, resides simultaneously in several types of storage, forming a [[storage hierarchy]]. Inside of a contemporary computer hosting a DBMS, most of the "database" part resides, partially replicated, in [[Volatile memory|volatile storage]]. Data that are actively being processed and manipulated reside inside the [[Processor (computing)|processor]], possibly in [[CPU cache|processor's caches]]. These data are read from and written to memory, typically through a computer [[Bus (computing)|bus]], which is usually a volatile storage component. Computer memory communicates data to and from external storage, typically through standard storage interfaces or networks (e.g., [[fibre channel]], [[iSCSI]]). A [[Disk array|storage array]], a common external storage unit, typically has storage hierarchy of its own. A fast cache, typically consisting of volatile and fast [[Dynamic random-access memory|DRAM]], is connected (via standard interfaces) to drives. These drives may have different speeds, like [[USB flash drive|flash drives]] and [[Non-volatile memory|non-volatile]] magnetic [[disk drive]]s. Speed and price are generally correlated. The drives may be connected to [[magnetic tape]]s, on which the least active parts of a large database may reside. This may also be where [[Backup|backups]] are located. ===Data structures=== {{Main|Database storage structures}} A data structure is an abstract construct that embeds data in a well defined manner. An efficient data structure allows manipulation of the data in efficient ways. The data manipulation may include data insertion, deletion, updating and retrieval in various modes. A certain data structure type may be very effective in certain operations, and very ineffective in others. A data structure type is selected upon DBMS development to best meet the operations needed for the types of data it contains. Type of data structure selected for a certain task typically also takes into consideration the type of storage it resides in (e.g., speed of access, minimal size of storage chunk accessed, etc.). In some DBMSs database administrators have the flexibility to select among options of data structures to contain user data for performance reasons. Sometimes the data structures have selectable parameters to tune the database performance. Databases may store data in many data structure types.<ref name="Physical Database Design">{{cite book|last1=Lightstone |first1=S. |first2=T. |last2=Teorey |first3=T. |last3=Nadeau |title=Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more |publisher=Morgan Kaufmann Press |year=2007 |isbn=978-0-12-369389-1 |ref=none}}</ref> Common examples are the following: *ordered/unordered [[flat file database|flat files]] *[[hash table]]s *[[B+ tree]]s *[[ISAM]] *[[heap (data structure)|heaps]] ===Data orientation and clustering=== In contrast to conventional row-orientation, relational databases can also be [[column-oriented DBMS|column-oriented]] or [[correlation database|correlational]] in the way they store data in any particular structure. In general, substantial performance improvement is gained if different types of database objects that are usually utilized together are laid in storage in proximity, being "clustered". This usually allows to retrieve needed related objects from storage in minimum number of input operations (each sometimes substantially time-consuming). Even for in-memory databases clustering provides performance advantage due to common utilization of large caches for input-output operations in memory, with similar resulting behavior. For example, it may be beneficial to cluster a record of an "item" in stock with all its respective "order" records. The decision of whether to cluster certain objects or not depends on the objects' utilization statistics, object sizes, caches sizes, storage types, etc. ===Database indexing=== {{Main|Database index}} Indexing is a technique some storage engines use for improving database performance. The many types of indexes share the common property that they reduce the need to examine every entry when running a query. In large databases, this can reduce query time/cost by orders of magnitude. The simplest form of index is a sorted list of values that can be searched using a [[binary search]] with an adjacent reference to the location of the entry, analogous to the index in the back of a book. The same data can have multiple indexes (an employee database could be indexed by last name and hire date). Indexes affect performance, but not results. Database designers can add or remove indexes without changing application logic, reducing maintenance costs as the database grows and database usage evolves. Indexes can speed up data access, but they consume space in the database, and must be updated each time the data is altered. Indexes therefore can speed data access but slow data maintenance. These two properties determine whether a given index is worth the cost. ==References== {{Reflist}} ==External links== *https://web.archive.org/web/20100330045149/http://dev.mysql.com/tech-resources/articles/storage-engine/part_3.html *[https://books.google.com/books?id=PqZ6QytCemcC&pg=PT287&dq=storage+engines MySQL Administrator's Bible] Chapter 11 "Storage Engines" {{Database}} {{DEFAULTSORT:Database Engine}} [[Category:Data management]] [[Category:Database engines| ]] [[Category:Database management systems]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Cite book
(
edit
)
Template:Database
(
edit
)
Template:Main
(
edit
)
Template:No
(
edit
)
Template:Reflist
(
edit
)
Template:Seealso
(
edit
)
Template:Short description
(
edit
)
Template:Yes
(
edit
)