motores de almacenamiento de distintos bdms

Upload: perla-lopez

Post on 08-Jan-2016

231 views

Category:

Documents


0 download

DESCRIPTION

Inv

TRANSCRIPT

Motores de almacenamiento de distintos BDMS.

Motores de almacenamiento de distintos BDMS.MySQL.MyISAM.MyISAM es el motor de almacenamiento por defecto. Se basa en el cdigo ISAM (Mtodo de Acceso Secuencial Indexado) pero tiene muchas extensiones tiles. (Tenga en cuenta que MySQL 5.0 no soporta ISAM.)Cada tabla MyISAM se almacena en disco en tres ficheros. Los ficheros tienen nombres que comienzan con el nombre de tabla y tienen una extensin para indicar el tipo de fichero. Un fichero .frm almacena la definicin de tabla. El fichero de datos tiene una extensin .MYD (MYData) . El fichero ndice tiene una extensin .MYI (MYIndex). Todos los datos se almacenan con el byte menor primero. Esto hace que sean independientes de la mquina y el sistema operativo. El nico requerimiento para portabilidad binaria es que la mquina use enteros con signo en complemento a dos y formato en coma flotante IEEE. La nica rea de mquinas que pueden no soportar compatibilidad binaria son sistemas empotrados, que a veces tienen procesadores peculiares. No hay penalizacin de velocidad al almacenar el byte menor primero; los bytes en un registro de tabla normalmente no estn alineados y no es un problema leer un byte no alineado en orden normal o inverso. Adems, el cdigo en el servidor que escoge los valores de las columnas no es crtico respecto a otro cdigo en cuanto a velocidad. Ficheros grandes (hasta longitud de 63 bits) se soportan en sistemas de ficheros y sistemas operativos que soportan ficheros grandes. Registros de tamao dinmico se fragmentan mucho menos cuando se mezclan borrados con actualizaciones e inserciones. Esto se hace combinando automticamente bloques borrados adyacentes y extendiendo bloques si el siguiente bloque se borra. El mximo nmero de ndices por tabla MyISAM enMySQL5.0 es 64. Esto puede cambiarse recompilando. El mximo nmero de columnas por ndice es 16. La longitud mxima de clave es 1000 bytes. Esto puede cambiarse recompilando. En caso de clave mayor a 250 bytes, se usa un tamao de bloque mayor, de 1024 bytes. Las columnas BLOB y TEXT pueden indexarse. Valores NULL se permiten en columnas indexadas. Todos los valores de clave numrica se almacenan con el byte mayor primero para mejor compresin de ndice.

MERGE.El motor de almacenamiento es conocido tambin como MRG_MyISAM . Es una coleccin de tablas MyISAM idnticas que significa que todas las tablas tienen informacin de columna e ndice idntica. No se puede mezclar tablas en que las columnas se listen en orden distinto, no tengan exactamente las mismas columnas, o tengan los ndices en orden distinto. Sin embargo, alguna o todas las tablas se pueden comprimir con myisampack. Cuando se crea una tabla MERGE ,MySQLcrea dos ficheros en disco. Los ficheros tienen nombres que comienzan con el nombre de la tabla y tienen una extensin para indicar el tipo de fichero, Un fichero .frm almacena la definicin de tabla, y un fichero .MRG contiene los nombres de las tablas que deben usarse como una. Las tablas no tienen que estar en la misma base de datos que la tabla MERGE misma. Se puede usar SELECT, DELETE, UPDATE, y INSERT en la coleccin de tablas. Si se realiza un DROP de la tabla MERGE, slo se borra la especificacin de la misma. Las tablas subyacentes no se ven afectadas. Cuando se crea una tabla MERGE , debe especificarse una clusula UNION=(list-of-tables) que indique qu tablas se quieren usar como una. Se puede especificar opcionalmente una opcin INSERT_METHOD si quiere que las inserciones en la tabla MERGE se realicen en la primera o ltima tabla de la lista UNION . Se utiliza un valor de FIRST o LAST para hacer que las inserciones se hagan en la primera o ltima tabla, respectivamente. Si no se especifica una opcin INSERT_METHOD o si se especifica con un valor de NO, los intentos de insertar registros en la tabla MERGE producen un error. DROP la tabla MERGE y recrearla. Usar ALTER TABLE tbl_name UNION=(...) para cambiar la lista de tablas subyacentes. Cambir el fichero .MRG y realizar un comando FLUSH TABLE para la tabla MERGE y todas las tablas subyacentes para forzar al motor de almacenamiento a leer el nuevo fichero de definicin.

InnoDB. Brinda a MySQL un motor de almacenamiento transaccional (conforme a ACID) con capacidades de commit (confirmacin), rollback (cancelacin) y recuperacin de fallas. InnoDB realiza bloqueos a nivel de fila y tambin porporciona funciones de lectura consistente sin bloqueo al estilo Oracle en sentencias SELECT. Estas caractersticas incrementan el rendimiento y la capacidad de gestionar mltiples usuarios simultneos. No se necesita un bloqueo escalado en InnoDB porque los bloqueos a nivel de fila ocupan muy poco espacio. InnoDB tambin soporta restricciones FOREIGN KEY. En consultas SQL, an dentro de la misma consulta, pueden incluirse libremente tablas del tipo InnoDB con tablas de otros tipos. InnoDB se dise para obtener el mximo rendimiento al procesar grandes volmenes de datos. Probablemente ningn otro motor de bases de datos relacionales en disco iguale su eficiencia en el uso de CPU. A pesar de estar totalmente integrado con el servidor MySQL, el motor de almacenamiento InnoDB mantiene su propio pool de almacenamiento intermedio para tener un cach de datos e ndices en la memoria principal. InnoDB almacena sus tablas e ndices en un espacio de tablas, el cual puede consistir de varios ficheros (o particiones disco). Esto difiere por ejemplo, en el motor MyISAM, donde cada tabla se almacena empleando ficheros separados, las tablas InnoDB pueden ser de cualquier tamao, an en sistemas operativos donde el tamao de los ficheros se limita a 2GB. En MySQL 5.0, InnoDB viene incluido por defecto en las distribuciones binarias. El instalador Windows Essentials configura a InnoDB como el tipo de base de datos MySQL por defecto en Windows. InnoDB se utiliza en muchos grandes sitios de bases de datos que necesitan alto rendimiento. El famoso sitio de noticias de Internet Slashdot.org corre sobre InnoDB. Mytrix, Inc. almacena ms de 1TB de datos en InnoDB, y otros sitios manejan una carga promedio de 800 inserciones y actualizaciones por segundo en InnoDB.

ARCHIVEEl motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades de datos sin ndices con una huella relativamente pequea.Para activar este motor, use la opcin --with-archive-storage-engine con configure al compilar MySQL.Cuando crea una tabla ARCHIVE , el servidor crea un fichero de definicin de tabla en el directorio de base de datos. El fichero comienza con el nombre de tabla y tiene una extensin de .ARZ y .ARM. Un fichero .ARN puede aparecer durante operaciones de optimizacin.El motor ARCHIVE soporta slo INSERT y SELECT. Esto significa que no puede ejecutar DELETE, REPLACE, o update . Un SELECT realiza un escaneo de tabla completo. Los registros se comprimen al insertarse. OPTIMIZE TABLE puede usarse para comprimir la tabla.El motor ARCHIVE usa bloqueo a nivel de registro.

NDB. Es una versin de alta disponibilidad, alta redundancia de MySQL adaptada para el entorno de computacin distribuida. Usa el motor de almacenamiento NDB Cluster para permitir la ejecucin de varios servidores MySQL en un cluster. Este motor de almacenamiento est disponible en las distribuciones binarias de MySQL 5.0 y en los RPMs compatibles con las distribuciones Linux ms modernas.MySQL Cluster es una tecnologa que permite clustering de bases de datos en memoria en un entorno de no comparticin. La arquitectura de no comparticin permite que el sistema funcione con hardware barato, y sin ningn requerimiento especial de hardware o software. Tampoco tienen ningn punto nico de fallo porque cada componente tiene su propia memoria y disco.MySQL Cluster integra el servidor MySQL estndar con un motor de almacenamiento clusterizado en memoria llamado NDB. Motor de almacenamiento NDB. Este es un motor de almacenamiento en memoria que ofrece alta disponibilidad y persistencia de datos. Es altamente configurable ofreciendo un gran nmero de opciones para manejar el balanceo de cargas y la tolerancia a fallas. Nodo de administracin (Nodo MGM). Este tipo de nodo cumple con la funcin de manejar, controlar y coordinar los otros nodos dentro del clster. Implementa funciones de configuracin de datos, Iniciar o detener otros nodos dentro del clster, ejecutar respaldos, u otras tareas administrativas. Debido a que controla y configura el resto de los nodos, debe iniciarse antes que cualquier otro tipo de nodos utilizando el comando ndb_mgmd. Nodo de datos. Este tipo de nodo almacena los datos. La cantidad de nodos de este tipo dentro del cluster es igual a a la cantidad de replicas por la cantidad de fragmentos. Es decir, si se manejan 4 replicas de los datos con 2 fragmentos, se necesitaran 8 nodos de datos. No es necesario manejar ms de una rplica. Este tipo de nodo se levanta utilizando el comando ndbd. Nodo SQL (MySQL server). A travs de este tipo de nodos se accede a los datos clusterizados. Bsicamente, consiste en un servidor MySQL Server que utiliza el motor de almacenamiento NDB. Se inicia utilizando el comando ndbcluster, especificando el archivo de configuracin necesario para este servidor . Clientes MySQL. Para conectarse a un cluster MySQL remotamente, se debe utilizar el mismo cliente utilizado para conectarse a un servidor MySQL no clusterizado. El clster es transparente para los clientes. Clientes administrativo. Existen otro tipo de clientes que se comunican con el servidor de administracin y proveen las mismas funcionalidades que un nodo de este tipo. A diferencia de los nodos administrativos, los clientes permiten ejecutar las tareas de administracin remotamente. Algunas tareas que pueden realizarse con estos clientes incluyen iniciar o detener nodos, administrar el seguimiento de mensajes de depuracin, mostrar el estado de otros nodos y sus respectivas versiones, realizar respaldos, etc.

MEMORY (HEAP).El motor de almacenamiento MEMORY crea tablas con contenidos que se almacenan en memoria. stas se conocan prviamente como HEAP . En MySQL 5.0, MEMORY es el trmino preferido, aunque HEAP se soporta para compatibilidad con versiones anteriores.Cada tabla MEMORY est asociada con un fichero de disco. El nombre de fichero comienza con el nombre de la tabla y tiene una exensin de .frm para indicar que almacena la definicin de la tabla.Para especificar explcitamente que quiere una tabla MEMORY, indquelo con una opcin ENGINE :CREATE TABLE t (i INT) ENGINE = MEMORY;Como indica su nombre, las tablas MEMORY se almacenan en memoria y usan ndices hash por defecto. Esto las hace muy rpidas, y muy tiles para crear tablas temporales. Sin embargo, cuando se apaga el servidor, todos los datos almacenados en las tablas MEMORY se pierde. Las tablas por s mismas continan existiendo ya que sus definiciones se almacenan en ficheros .frm en disco, pero estn vacas cuando reinicia el servidor. El espacio para tablasMEMORYse reserva en pequeos bloques. Las tablas usan el 100% del hashing dinmico para insrciones. No se necesita rea de desbordamiento o espacio extra para claves. No se necesita espacio extra para listas libres. Los registros borrados se ponen en una lista encadenada y se resan cuando inserta nuevos datos en la tabla. Las tablasMEMORYno tienen ninguno de los problemas asociados con borrados ms inserciones en tablas hasheadas. Las tablasMEMORYpueden tener hasta 32 ndices por tabla, 16 columnas por ndice y una clave de longitud mxima de 500 bytes. En MySQL 5.0, el motorMEMORYimplementa ndicesHASHyBTREE. Puede espcificar uno u otro para cada ndice aadiendo una clusulaUSING. Puede tener claves no nicas en una tablaMEMORY. (Esta es una caracterstica no comn de implementaciones de ndices hash.) En MySQL 5.0, puede usarINSERT DELAYEDcon tablasMEMORY. Si tiene un ndice hash en una tablaMEMORYque tenga un alto ndice de duplicacin de claves (muchas entradas de ndice con el mismo valor), las actualizaciones a la tabla que afecten valores claves y todos los borrados son significativamente ms lentos. El rango de esta ralentizacin es proporcional al rango de duplicacin (o inversamente proporcional al grado cardinalidad). Pude usar un ndiceBTREEpara evitar este problema. Las tablasMEMORYusan una longitud de registro fija. MEMORYno soporta columnasBLOBoTEXT. MEMORYen MySQL 5.0 incluye soporte para columnasAUTO_INCREMENTe ndices en columnas que contengan valoresNULL. Las tablasMEMORYse comparten entre todos los clientes (como cualquier otra tabla no-TEMPORARY). Los contenidos de las tablasMEMORYse almacenan en memora, lo que es una propiedad que las tablasMEMORYcomparten con las tablas internas que el servidor va creando al procesar consultas. Sin embargo, los dos tipos de tablas difierne en que las tablasMEMORYno estn sujetas a conversin de almacenamiento, mientras que las tablas internas s: Si una tabla interna llega a ser demasiado grande, el servidor la convierte automticamente a una tabla en disco. El lmite de tamao lo determina la variable de sistematmp_table_size. Las tablasMEMORYnunca se convieren en tablas de disco. Para segurar que no comete un error accidentalmente, puede cambiar la variable de sistemamax_heap_table_sizepara que imponga un tamao mximo de tablasMEMORY. Para tablas individuales, puede especificar la opcin de tablaMAX_ROWSen el comandoCREATE TABLE. El servidor necesita suficiente memoria para mantener todas las tablasMEMORYen uso a la vez. Para liberar memoria usada por una tablaMEMORYcuando no se requiere su contenido, debe ejecutarDELETE FROMoTRUNCATE TABLE, o borrar toda la tabla conDROP TABLE. Si quiere rellenar una tablaMEMORYcuando arranca el servidor MySQL, puede usar la opcin--init-file. Por ejemplo, puede usar comandos comoINSERT INTO ... SELECToLOAD DATA INFILEen este fichero para cargar la tabla de una fuente de datos persistente. ConsulteSeccin5.3.1, Opciones del comandomysqldySeccin13.2.5, Sintaxis deLOAD DATA INFILE. Si usa replicacin, las tablasMEMORYdel servidor maestro se vacan cuando se apaga y reinicia. Sin embargo, un esclavo no es consciente que se vacan estas tablas, as que retorna contenido desfasado si selecciona datos del mismo. En MySQL 5.0, cuando se usa una tablaMEMORYen el maestro por primera vez desde que arranc el maestro, se escribe un comandoDELETE FROMen el log binario del maestro automticamente, resincronizando el maestro y el esclavo otra vez. Tenga en cuenta que incluso con esta estrategia, el esclavo tiene datos desfasados en la tabla en el intervalo entre el reinicio del maestro y el primer uso de la tabla. Sin embargo, si usa la opcin--init-filepara rellenar la tablaMEMORYal arrancar el maestro, se asegura que este intervalo sea cero.

BDB (BerkeleyDB).Sleepycat Software ha proporcionado a MySQL el motor de almacenamiento transaccional Berkeley DB. A este motor de almacenamiento se le llama tradicionalmente BDB. Se incluye soporte para BDB en distribuciones fuentes de MySQL y en distribuciones binarias MySQL-Max .Las tablas BDB pueden tener una gran probabilidad de sobrevivir a fallos del sistema y ser capaces de realizar COMMIT y ROLLBACK en transacciones. La distibucin fuente MySQL incluye una distribucin BDB preparada para funcionar con MySQL. No puede usar una versin de BDB no preparada para funcionar con MySQL.En MySQL AB trabajamos codo a codo con Sleepycat para mantener la calidad de la interfaz MySQL/BDB . (Incluso aunque Berkeley DB est muy testeado y es muy fiable, la interfaz MySQL se considera de calidad gamma. Continuamos mejorando y optimizndola.)Cuando hay algn problema con tablas BDB, ayudamos a nuestros usuarios a localizar el problema y reproducir casos de test. Cualquiera de estos casos de test se enva a Sleepycat, que nos ayuda a encontrar y arreglar el problema. Con esta operacin de dos fases, cualquier problema con tablas BDB puede tardar un poco ms en ser resuelto que con nuestros motores de almacenamiento. Sin embargo, no anticipamos dificultades significativas con este procedimiento ya que el cdigo Berkeley DB se usa en muchas aplicaciones distintas a MySQL.CSV.El motor de almacenamiento CSV almacena datos en ficheros de texto usando valores separados por comas.Para activar este motor de almacenamiento, use la opcin --with-csv-storage-engine con configure al compilar MySQL.Cuando crea una tabla CSV , el servidor crea un fichero de definicin de tabla en el directorio de base de datos. El fichero comienza con el nombre de tabla y tienen una extensin .frm. El motor de almacenamiento crea un fichero de datos. Su nombre comienza con el nombre de tabla y tiene extensin .CSV. El fichero de datos es un fichero de texto. Cuando almacena datos en la tabla, el motor la guarda en el fichero de datos en formato CVS.El motor de almacenamiento CSV no soporta indexacin.

EXAMPLE.El motor de almacenamiento EXAMPLE es un motor de pruebas que no hace nada. Su propsito es servir como ejemplo en el cdigo fuente MySQL para ilustrar cmo empezar a escribir nuevos motores de almacenamiento. Como tal, tiene inters principalmente para desarrolladores.Para examinar la fuente del motor EXAMPLE , consulte el directorio sql/examples de distribuciones fuentes MySQL 5.0.Para activar este motor de almacenamiento, use la opcin --with-example-storage-engine con configure al compilar MySQL.Cuando crea una tabla EXAMPLE , el servidor crea un fichero de definicin de tabla en el directorio de base de datos. El fichero comienza con el nombre de tabla y tiene una extensin .frm . No se crean ms ficheros. No puede almacenarse ni recuperarse datos de la tabla.

FEDERATED.El motor FEDERATED est disponible desde MySQL 5.0.3. Es un motor que accede a datos en tablas de bases de datos remotas en lugar de tablas locales.Cuando crea una tabla FEDERATED , el servidor crea un fichero de definicin de tabla en el directorio de base de datos. El fichero comienza con el nombre de tabla y tiene extensin .frm . No se crean ms ficheros, ya que los datos reales estn en la base de datos remota. Esto difiere de cmo funcionan los motores con tablas locales.Para tablas de bases de datos locales, los ficheros de datos son locales. Por ejemplo, si crea una tabla MyISAM llamada users, el handler MyISAM crea un fichero de datos llamado users.MYD. Un handler para tablas locales lee, inserta, borra y actualiza datos en ficheros de datos locales, y los registros se guardan en un formato particular del handler. Para leer registros, el handler debe parsear los datos en columnas. Para escribir registros, los valores de la columna deben convertirse al formato de registro usado por el handler y escribirse en el fichero de datos local.Con el motor MySQL FEDERATED no hay ficheros de datos locales para una tabla (por ejemplo, no hay fichero .MYD ). En su lugar, una base de datos remota almacena los datos que normalmente estaran en la tabla. Esto necesita el uso de la API del cliente MySQL para leer, borrar, actualizar e insertar datos. La recuperacin de datos se inicia via un comando SELECT * FROM tbl_name . Para leer el resultado, los registros se tratan uno a uno usando la funcin de la API C mysql_fetch_row() y luego se convierten desde las columnas del conjunto de resultados SELECT al formato que el handler FEDERATED espera.

Oracle.TABLESPACE.Oracle, a diferencia de otros BDMS no cuenta con motores de almacenamiento como tal, ste tiene su manera de manejar las bases de datos con ayuda de los tablespace.Una base de datos Oracle est formada por una o varias unidades lgicas llamadas tablespaces. Un tablespace es la unidad de almacenamiento lgico. Adems, cada una de estos tablespaces est formada por uno o varios ficheros fsicos que son los datafiles. Un datafile solamente puede pertenecer a un tablespace. Por lo tanto, los datafiles de una base de datos son todos los datafiles que forman parte de todos los tablespaces de la base. Cuando se crea una base de datos, hay que crear al menos un tablespace, por lo que durante el proceso de creacin de la base de datos siempre se indica el tablespace principal de sta, que se llama SYSTEM.

El Tablespace SystemCuando se crea una base de datos es obligatorio crear un tablespace inicial en el que se van a crear los usuarios SYS y SYSTEM automticamente. Estos usuarios son los que tienen la informacin necesaria para que funcione nuestra base de datos y podamos hacer todo tipo de operaciones como, por ejemplo, crear nuevos usuarios o crear nuevos tablespaces y tablas en esos nuevos tablespaces. Este tablespace inicial se llama por defecto SYSTEM. Es una pieza clave para un buen funcionamiento de la base de datos ya que en l residen todos los objetos de los usuarios SYS y SYSTEM. Es muy recomendable crear al menos otro tablespace nuevo distinto al SYSTEM. As, todos los nuevos usuarios que creemos en nuestra base de datos, junto con todas sus tablas e ndices se almacenarn en un tablespace diferente a SYSTEM. Se realiza esta separacin para evitar que se bloquee toda la base de datos si ocurre algo grave en el tablespace SYSTEM. Suele ser habitual que para nuestras aplicaciones creemos usuarios y tablas en las que introducimos informacin y que sin darnos cuenta se llene de informacin el tablespace en el que estn estas tablas. Si no hemos sido previsores, podemos haber llenado el tablespace SYSTEM con lo que es posible que se paralice toda la base de datos.

Tablespaces Online y OfflineUn tablespace puede estar en dos estados: Online y Offline. Que un tablespace est online significa que est disponible para operar en l, mientras que si est offline quiere decir que no se puede utilizar. Cuando creamos un tablespace, se crea en estado online y, por lo tanto, podemos crear en dicho tablespace objetos como ndices, tablas, etc.Para saber el estado de un tablespace existe una vista que nos da informacin sobre los tablespaces de nuestra base de datos. Esta vista es la dba_tablespaces. Consultndola podemos conocer qu tablespaces tenemos en nuestra base de datos y en qu estado se encuentran.select tablespace_name, status from dba_tablespaces;La razn por la que es til poner un tablespace offline es porque no se puede acceder a ningn objeto que se encuentre en l, es decir, que si en el tablespace hay tablas, no se podr hacer consultas ni inserciones ni modificaciones de estas tablas, sin embargo, el resto de los objetos que se encuentran en otros tablespaces de la base de datos si estn accesibles. Por lo tanto, pondremos un tablespace offline en general para realizar tareas administrativas. Para poder hacer una copia de seguridad del tablespace estando completamente seguros de que nadie est modificando los objetos del tablespace y que no quedan transacciones pendientes sin terminar y que pueden modificar estos objetos. Para poder actualizar una aplicacin que se basa en los objetos de este tablespace sin que ningn usuario pueda modificar los datos en medio de la actualizacin.

Tablespaces Read Only.Cuando creamos un tablespace, podemos crear en l todos los objetos que queramos y acceder a ellos y eliminarlos y tambin consultar los datos de las tablas que se encuentren en este tablespace, as como borrar, insertar y modificar estos datos. Existe la posibilidad de poner un tablespace en un estado en el cual, solamente se pueden consultar los datos de los objetos, no se puede ni borrar ni insertar nada en ellos.

Tablespaces Temporales.Un tablespace temporal es aqul en el que solamente puede haber objetos temporales. No se pueden crear en l objetos permanentes como pueden ser los ndices, las tablas o los segmentos de rollback. Estn especialmente preparados para optimizar las operaciones en las que se lleven a cabo ordenaciones. Por lo tanto est muy recomendado tener al menos un tablespace temporal en cada base de datos. Algunas de las operaciones que implican realizar ordenaciones son, las selects que tienen group by, las que tienen order by, la creacin de ndices y analizar ndices para calcularles las estadsticas. En todos estos casos, cuando para realizar la ordenacin el servidor no encuentra espacio suficente libre en la memoria, utiliza el tablespace temporal. Los rendimientos son muy superiores comparndolos con los tiempos que se empleara en realizar las ordenaciones en tablespaces normales. Esto se debe a que el mecanismo que se utiliza para reservar y desreservar el espacio en los tablespaces temporales es muy distinto que en los normales ya que est orientado a objetos que crecen mucho y rpido y que a continuacin disminuyen totalmente su tamao y desaparecen.

Postgres.EL BDMS postgres cuenta nicamente con un motor de almacenamiento, el cual es su Storage System o Storage Manager.El gestor de almacenamiento de Postgres es una coleccin de mdulos que provee manejo de transacciones y acceso a objetos de la base de datos. El diseo de esos mdulos se gua en tres metas.Proveer manejo de transacciones sin la necesidad de escribir una gran cantidad de cdigo especializado en fallos del sistema. ste cdigo es difcil de depurar, difcil de escribir y debe estar libre de errores. Si llegara a fallar en el sistema de algn cliente importante esto traera mucho problemas, por lo que postgres a optado por seguir un sistema de almacenamiento en el cual la informacin nunca es sobre escrita, en lugar es esto todas las actualizaciones son transformadas en inserciones.Acomodar el estado histrico de la base de datos en un disco ptico de una sola escritura (write-onde-read-many WORM) o algn otro medio para archivarlo aparte del estado actual en un disco magntico ordinario. Consecuentemente, contamos con un proceso asncrono diseado, llamado vacuum cleaner el cual mueve los registros archivados en el disco magntico sobre un sistema de almacenamiento archivado.Tomar ventaja de hardware especializado. En particular. Asumimos la existencia de una memoria principal no voltil con alguna cantidad razonable. sta memoria puede ser adquirida a travs de tcnicas de correccin de errores y un esquema de batera de respaldo o algn otro hardware especializado. Sumado a sto, esperamos contar con unas cuantas instrucciones de bajo nivel disponibles para los usos especializados ya mencionados.Tambin asumimos que las arquitecturas de numerosos procesadores se se irn volviendo ms populares. En tal ambiente hay una oportunidad de aplicar procesadores mltiples corriendo el DBMS cuando slo uno es utilizado. Esto requiere cambiar el DBMS Postgres de la monoltica arquitectura de flujo nico de control que prevalecen ahora a uno en el que haya muchos procesos asncronos desempendose en conjunto. Estos procesadores incluyen el Sequent Balance System (SEQU85), el FIREFLY y SPUR (HILL85).

MariaDB.Aria.El motor de almacenamiento Aria permite consultas complejas ms rpido (consultas que normalmente utilizan tablas temporales basada sen disco). El Aria motor de almacenamiento se utiliza para las tablas temporales internas, que debe darle una aceleracin cuando se hace compleja selecciona. Aria es generalmente ms rpido para las tablas temporales en comparacin con MyISAM porque Aria almacena en cach datos de la fila en la memoria y, normalmente, no tiene que escribir las filas temporales en el disco.

XtraDB.Versin mejorada del mecanismo de almacenamiento InnoDB, y mecanismo de almacenamiento por defecto en el clon de MySQL desarrollado por Percona . Tiene mejores prestaciones que InnoDB y mejor escalabilidad en hardware moderno, til en entornos con carga alta. Es compatible con InnoDB, de modo que lo puede reemplazar directamente.Desarrollado por Percona, XtraDB incluye las caractersticas ACID de InnoDB basadas en una arquitectura MVCC avanzada. Se caracteriza por su adaptabilidad, mtricas y escalabilidad. En particular est diseado para escalar mejor que InnoDB en CPU con ncleos mltiples, hacer un ms eficiente uso de memoria y tener ms usabilidad.Este mecanismo no est disponible para descarga independiente, slo se halla incorporado en MariaDB y Percona Server.

PBXT.PrimeBase XT (PBXT) es un mecanismo de almacenamiento transaccional para MySQL. Usa una arquitectura basada en logs y escritura nica que proporciona prestaciones ptimas en un amplio rango de situaciones. El mecanismo es enchufable, que significa que puede ser instalado dinmicamente en tiempo de ejecucin en MySQL versin 5.1 o posterior.

Federated.El mecanismo Federated permite guardar los datos de una tabla en otro servidor MySQL remoto, a travs de la red. Al realizar una consulta los datos se extraen de ese servidor. No se guardan datos en el servidor local, slo el fichero de formato.frm. El mecanismo de almacenamiento usado por el servidor remoto puede ser cualquiera de los que soporte ste.

OQGRAPH.El mecanismo de almacenamiento OQGraph (Open Query GRAPH) permite manejar estructuras jerrquicas -en rbol- y tambin grafos genricos. OQGraph est especialmente indicado para manejar relaciones n:m.

SphinxSE.Existe una base de datos textual llamada Sphinx que funciona como un DBMS independiente. Esta base de datos fue diseada especialmente para integrarse de modo fcil con bases de datos SQL que contuvieran los textos, y poderse emplear con lenguajes de scripting.Los dos componentes principales de sphinx son: Indexer: utilidad para crear ndices de texto completo Searchd: proceso que permite la conexin de programas externosSphinxSE es un mecanismo que conecta sphinx con MySQL u otras bases de datos SQL, y que puede ser incorporado en los servidores MySQL a partir de la versin 5.1 mediante su arquitectura de mdulos enchufables. SphinxSE no almacena datos por s mismo, funciona como un cliente integrado que permite al servidor MySQL comunicarse con el componente de sphinx searchd para realizar bsquedas y obtener los resultados. La bsqueda e indexacin la realiza el cliente Sphinx de SphinxSE para MySQL.

IBMDB2I.IBM proporciona un mecanismo de almacenamiento para IBM serie i (antiguo AS/400). Con ese mecanismo las aplicaciones escritas para MySQL y sus forks pueden correr en la serie i IBM almacenando datos en DB2. Esto permite implementar aplicaciones MySQL transaccionales y en lnea almacenando los datos en un entorno DB2 nico y fcil de gestionar.Cassandra SE.El principal objetivo del mecanismo de almacenamiento Cassandra SE7 es la integracin de datos entre el mundo SQL y el NoSQL al que pertenece la base de datos Cassandra. Permite: Capturar datos de Cassandra desde el frontal web o sentencia SQL. Insertar registros en Cassandra desde una aplicacin.La base de datos Cassandra utiliza el lenguaje CQL, pero en MariaDB 10.0 ser posible interrogarla utilizando SQL. Esto permite que las columnas de Cassandra aparezcan como tablas en las que se pueden realizar INSERT, UPDATE o SELECT. Es posible tambin escribir JOIN incluyendo tablas que usen otros mecanismos de almacenamiento.El mecanismo viene enlazado estticamente en la versin preliminar 5.5.25 de MariaDB y forma parte de la versin MariaDB 10.0.1.

Sequence.Este mecanismo de almacenamiento permite crear secuencias de nmeros ascendentes o descendentes, empezando por uno determinado y con un incremento arbitrario.Sirve para crear tablas virtuales efmeras cuando se necesiten. Nunca se escriben en disco ni se crean ficheros frm. Estas tablas tiene acceso slo lectura, son transaccionales y soportan XA.