2012-01-11 13 views
8

Solo quiero entender mejor, en lo que he aprendido durante años es que una solución basada en documentos es lenta y requiere mucha E/S. Por ejemplo, en un proyecto PHP, generalmente se dice que es mucho mejor usar un caché de memoria como Redis, Memecache o APC porque están basados ​​en memoria en lugar de almacenar datos en un ARCHIVO real.¿Cómo es un DB basado en documentos tan rápido?

Ahora han llegado todos estos DB NoSQL y he leído que son mucho más rápidos que MySQl y otros, y están basados ​​en documentos. ¿Alguien puede ayudarme a entender esta teoría? Si cada registro es un Documento (ARCHIVO), entonces, ¿cómo es tan bueno en el rendimiento? Recientemente leí sobre un tipo que estaba usando Redis en un proyecto y dijo que cambió a MongoDB y está teniendo mejores resultados que con Redis (me doy cuenta de que estoy comparando un caché con un DB, pero esa no es la verdadera pregunta, yo ¿Desea saber cómo una solución basada en documentos es más rápida que las soluciones sin documentos?)

Respuesta

4

Basada en documentos no significa necesariamente que estén almacenados por completo en el sistema de archivos. Algunas partes todavía se pueden mantener en la memoria como un índice.

Basada en documentos solo significa que la base de datos almacena datos en paquetes (como hojas de papel donde cada hoja es un conjunto de datos y puede escribir libremente) en lugar de una estructura muy específica como una tabla.

http://en.wikipedia.org/wiki/Document-oriented_database

Ah y por qué puede ser más rápido que Redis:
Digamos que usted necesita para almacenar información no lineal en un conjunto (es decir, no cada conjunto de datos tiene el mismo aspecto y que tiene diferentes tipos de datos En Redis, solo puede almacenar pares de clave-valor, por lo que necesitará vincularlos de nuevo a un conjunto en su propio código/implementación. En una base de datos NoSQL, la base de datos lo maneja en un (probablemente) forma mucho más optimizada :)

+0

Redis no solo almacena pares de clave/valor, puede almacenar muchos más tipos de datos (Ver: http://redis.io/topics/data-types) – Carpetsmoker

0

Lo primero es que no se pueden comparar los DB NoSQL con los DB en memoria . Los DB NoSQL son datos que no caben en la memoria.

Ahora, con respecto a los DB NoSQL, no son solo archivos simples, tienen índices que proporcionan un acceso rápido a las compensaciones en los archivos y ahí es donde realmente está la velocidad.

+4

'NoSQL DBs son ment para datos que no encajar en la memoria'. Eso está completamente mal. ¿Por qué está usted diciendo que? – jgauffin

+0

Ok, me corrijo, * la mayor parte del tiempo * se usan para estructuras que superan el tamaño que cabe en la memoria. También se pueden usar como almacenamiento en memoria y pueden proporcionar un mejor rendimiento que las tablas relacionales en memoria, ya que son más simples en la implementación. Dicho esto, algunas veces puede obtener un rendimiento aún mejor al implementar estructuras de datos en su programa. – thedrs

+1

'la mayor parte del tiempo" sigue siendo incorrecto. Son simplemente una alternativa a RDBMS, pero sin esquemas y con una mejor solución para raíces agregadas. – jgauffin

2

El NoSQL hablar puede ser propenso a malentendidos, ya que algunos de los conceptos usarán nombres, que tienen un significado diferente a la tradicional:

  • de archivos basado no (necesariamente) quiere decir, que la Datastore escribirá cada registro en un archivo; significa que los registros en el almacén de datos no tendrán que ajustarse a un esquema predefinido de campos si se trata de un determinado tipo de datos. Piense en "archivo" como algo como XML, JSON o amigos.
  • Las ganancias de rendimiento de (la mayoría) de las áreas de almacenamiento de datos NoSQL tienen un precio: las promesas de ACID generalmente bien entendidas se negocian con un modelo de coherencia más flexible.
  • El poder de las bases de datos relacionales de SQL se debe en gran parte al hecho de que se puede escribir tan bien como cada consulta en un esquema existente. Esto no siempre es cierto con las áreas de almacenamiento de datos NoSQL: en la versión más extrema, el acceso a un registro solo es posible a través de una identificación de registro.
  • almacenes de datos
  • más NoSQL escalará mucho mejor que una base de datos relacional típica - que son la respuesta a la pregunta "¿Qué tenemos que sacrificar a partir de una base de datos relacional bien entendido" para superar los límites de escala"
0

para tener una idea, considere esto:

  • con MongoDB que diseñaría el esquema de una manera que un solo documento tiene todo lo necesario para representar una página
  • con MySQL (o cualquier otro RDBMS) que. normalizar los datos y dividirlos en muchas tablas. Para renderizar los mismos página, tendría que hacer muchas consultas SQL.

Aunque esa consulta de mongo puede ser más lenta que una consulta de mysql, la comparación de 1 consulta de mongo a 100 consultas de mysql va a ser mucho más rápida.

0

El ingrediente mágico no es necesariamente una base de datos "más rápida", es una base de datos que permite el diseño y la implementación de sistemas "más rápidos". Es por eso que las bases de datos NoSQL se consideran un cambio de juego.

Durante varias décadas, las bases de datos relacionales fueron el único juego en la ciudad. Muchos sistemas basados ​​en SQL pagan un doble impuesto de rendimiento: una vez para el conjunto completo de características ACID (que probablemente no necesitan de todos modos), y luego nuevamente para calzar sus datos de dominio en un modelo de tabla relacional.

Además, un rasgo común de la mayoría de las bases de datos NoSQL es que son más simples debido a que son más especializadas que el enfoque de "caso general" de una base de datos SQL. Eso significa menos lógica/código que necesita ejecutarse en cada operación, estructuras de datos más simples (que pueden requerir menos IO) y en general - menos sobrecarga, mejor rendimiento.

Cuestiones relacionadas