¿Qué es un buen DBMS para archivar?

Question

He estado atrapado en un mundo MSSQL/MySQL ahora durante algunos años, y he decidido difundir mis alas un poco más. En este momento estoy investigando qué DBMS es bueno en las cosas necesarias al archivar los datos. P.ej. Muchas escrituras y lecturas bajas.

He visto la cruzada NoSQL, pero tengo una mentalidad muy RDBMS, así que soy un poco escéptico.

¿Alguien tiene alguna sugerencia? O incluso cualquier consejo para donde hay algunos puntos de referencia, etc. para este tipo de cosas.

Gracias :) Thomas

---

editar

Como había una pregunta, intentaré dar un poco más de información sobre lo que estoy pensando

Voy a ejecutar un servicio en varios servidores, que tendrán su base de datos local. Estas bases de datos tendrán una gran cantidad de éxitos (1/1 de lectura/escritura), por lo que estoy tratando de mantenerlas lo más vacías posible para mantener bajo el tiempo de consulta. Mi estimación inicial es que ninguna fila se ubicará en esa base de datos por más de 30 minutos. Ejecutar un archivo DB en cada uno de esos servicios parece un desperdicio de recursos, por lo que una arquitectura de archivo central se ve mejor.

Intentaré ascender una arquitectura de red rápida

     ___________    ___________    ___________
    | service 1 |  | service 2 |  | service 3 |
     -----------    -----------    -----------
          |____________|_______________|
                   ____|____
                  | Archive |
                   ---------

Como sabrán, MSSQL y MySQL solo escala verticalmente cuando se trata de escribir (no estoy seguro de si se trata de RDBMS). Así que estoy buscando obtener el mayor rendimiento de ese archivo DBMS como sea posible.

Answer 1

Si la estructura de los datos que está archivando es relativamente simple, puede considerar archivar directamente a archivos planos. Bueno para escribir, no tan bueno para leer. Hay alguna discusión sobre este tema en esta pregunta: ¿Las bases de datos de archivos planos son buenas?

De lo contrario, me quedaría con MySQL y me aseguraría de que esté ajustado correctamente para un uso de alta escritura/lectura baja.

Answer 2

Así que estoy tratando de mantenerlos lo más vacíos posible para mantener el tiempo de consulta bajo

Primero, la velocidad de consulta no es directamente proporcional al tamaño de la base de datos a menos que solo esté haciendo escaneos de mesa completos. Una búsqueda de índice única es proporcional a la profundidad del índice. Desde el momento en que un bloque de raíz de índice se divide hasta la próxima vez que se divide, podría ser millones de filas adicionales. De hecho, eliminar las filas para mantener la base de datos "lo más vacía posible" puede no hacer que la base de datos sea más pequeña. Hasta que reconstruya el índice, podría tener bloques de rama y hoja muy escasos y hacer que las exploraciones de índice tomen más y más tiempo.

No estoy seguro de cómo MSSQL o MySQL llenan páginas parcialmente vacías, pero es posible que no vea ningún ahorro de espacio desde las eliminaciones.

En Oracle, sugeriría partición y cae sobre las eliminaciones para mantener una base de datos un cierto tamaño.

Pero dije todo eso para alentarlo a difundir sus alas en una base de datos de uso de memoria para el uso de su servidor, en lugar de centrarse en el uso de su archivo. En este caso, no ha dicho nada que me haga pensar que un RDBMS no es la mejor solución para archivar.

Answer 3

Oracle o PostgressQL también son DBMS muy potentes. Pero si ya conoces y usaste MySQL, ¿por qué cambiar? Mysql es gratuito, performance, bien documentado ...

Pero si principalmente tiene operaciones de escritura y no muchas lecturas, y no desea más de los DBMS de uso común, entonces puede considerar un DBMS basado en documentos

Te recomendaría que eches un vistazo existir db y Mongo DB

¡Espero que esto ayude!

Answer 4

Puede ver el resultado de rendimiento de lectura/escritura de una base de datos diferente con esta Software de referencia de base de datos (GNU GPL)Eso es adecuado para encontrar algunas respuestas.