2010-09-09 17 views
16

Bueno, NoSQL es una palabra de moda en este momento, así que he estado investigando. Todavía tengo que encontrarme con ColumnFamilies y SuperColumns, etc. Pero he estado viendo cómo se mapean los datos.¿Qué hace que Cassandra (y NoSQL en general) sea una mejor solución para un RDBMS?

Después de leer el artículo this, y otros, parece que los datos están mapeados en un formato JSON like.

Users = { 
    1: { 
     username: "dave", 
     password: "blahblah", 
     dateReged: "1/1/1" 
    }, 
    2: { 
     username: "etc", 
     password: "blahblah", 
     dateReged: "2/1/1", 
     comment: "this guy has a comment and dave doesns't" 
    }, 
} 

El formato RDBMS sería:

Table name: "Users" 

id | username | password | dateReged | comment 
---+----------+----------+-----------+-------- 
1 | dave | blahblah | 1/1/1 | 
---+----------+----------+-----------+-------- 
2 | etc  | blahblah | 2/1/1 | this guy has a comment and dave doesn't 

Suponiendo que entiendo esto correctamente y mis ejemplos anteriores son correctas, ¿por qué elegir el diseño RDBMS sobre el diseño NoSQL? Personalmente, preferiría trabajar con la estructura JSON ... ¿Esto significa que debería elegir NoSQL en, digamos, MySQL?

Supongo que lo que estoy preguntando es "¿cuándo debería elegir NoSQL sobre RDBMS?"

En una nota lateral, como he dicho, todavía no entiendo completamente cómo implementar una base de datos de Cassandra. Es decir, ¿cómo puedo crear la tabla de usuarios anterior en una nueva base de datos? Cualquier tutorial, documentación, etc. que pueda señalar sería genial. Mi google'ing no ha aparecido demasiado en términos de 'comenzar desde cero' ...

+6

¡Su sincronización no podría ser mejor! Ver http://bit.ly/bpuno1 – RedFilter

+0

Vi ese enlace el día de hoy. Me aseguraré de verlo cuando llegue a casa;) – dave

+0

posible duplicado de [¿Por qué nosql con cassandra en lugar de mysql?] (Http://stackoverflow.com/questions/3640899/why-nosql-with-cassandra-instead -of-mysql) – Thilo

Respuesta

3

Supongo que lo que estoy preguntando es "¿cuándo debería elegir NoSQL sobre RDBMS?"

[Advertencia: Nunca he leído sobre NoSQL antes]

Según Wikipedia, NoSQL no es bueno en une: lo que implica (para mí) sin la integridad referencial y sin normalización.

+0

Para ser honesto, mi conocimiento de SQL es bastante pobre. Creo que he usado la palabra clave JOIN una vez. Sólo una vez. Perder eso realmente no me afectaría. – dave

+15

"Perder eso realmente no me afectaría". Famosas últimas palabras ... – Thilo

+0

@dave: si no entiende SQL (o, lo que es más importante, sus fundamentos en álgebra relacional), obviamente las soluciones SQL y NoSQL parecerán muy similares. Las diferencias realmente no comienzan a manifestarse hasta que tenga un * lote * de datos (y/o un * lote * de transacciones). –

3

La ventaja de NoSql es que es más simple y si tiene sus intermitentes OO, cumple todas sus necesidades de persistencia.

La ventaja de la base de datos real basada en SQL es que puede reutilizar y extender fácilmente sus datos de formas que no estaban previstas en el diseño original. Además, las bases de datos "Objeto" tienden a funcionar muy mal (incluso si es posíble) cuando desea hacer el equivalente de las consultas agregadas de SQL como COUNT, SUM, AVG.

Google BIGTABLE que es la base de datos más grande de OO en cualquier lugar (y probablemente el período más grande de la base de datos) también es compatible con funciones SQL y sql como indexación y tipeo fuerte.

1

La respuesta más simple que puedo pensar es: cuando sus datos no se ajustan a un modelo relacional.

+4

He visto varias cosas que no encajan en un modelo de OO, nunca he visto nada que no pueda ser modelado en una base de datos relacional. –

+1

@James Anderson [Jerarquías (árboles)] (http://stackoverflow.com/questions/1085287) se puede modelar en una base de datos relacional, pero es un poco difícil/especial hacerlo. – ChrisW

+2

Ciertamente PUEDE modelar casi cualquier cosa en una base de datos relacional, pero en muchos casos realmente tiene que contorsionar sus datos. –

13

La principal ventaja de NoSQL es la escalabilidad horizontal y el almacenamiento distribuido. Eso significa que puede tener una gran cantidad de 'nodos de clúster' y escribirles en paralelo. El clúster garantizará que los cambios se propaguen a los otros nodos del clúster con el tiempo (consistencia eventual).

NoSQL no se trata tanto de SQL (el término significa "no solo SQL"). De hecho, algunos productos NoSQL admiten un subconjunto de SQL. La razón por la cual el formato de datos es diferente (JSON o lista de pares propiedad/valor versus datos tabulares) es: dentro de las bases de datos relacionales, el número de columnas (y nombres de columna) se define en un lugar central, que no funciona bien con horizontal escalabilidad (necesitaría detener todos los nodos del clúster para cambios de esquema).Además, las uniones no se admiten tanto porque eso rompería la escalabilidad horizontal (es posible que sea necesario leer los datos de múltiples nodos del clúster si se distribuyen los datos).

+4

Y Oracle, DB2, SqlServer, Teradata, etc. ¿No admiten clustering? Bueno, no antes de 1992 de todos modos. –

+4

Son compatibles con la agrupación en clúster, pero tampoco admiten la escalabilidad horizontal, ya que intentan admitir todas las propiedades de ACID. Los productos NoSQL no intentan admitir todas las características de ACID. Algunos dicen que NoSQL realmente significa NoACID: http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html –

+0

@Thomas Mueller: ¿Cuál es exactamente la razón por la que tanta gente decir NoSQL es MALO. Y tampoco admite uniones, y con ello fuerza la desnormalización, y con ello crea una redundancia que ("casi" necesariamente) lleva a problemas de consistencia de los datos. Además, la consistencia eventual es mala. Si el servidor falla, debería haber confiado todos los datos en el disco, cuando dijo que sí. Cuando finalmente se compromete la información en el disco (pero dice que se ha comprometido antes), entonces las cosas malas van a suceder ... –

3

RDBMS 'son todo sobre consistencia. Hacen un gran trabajo en datos que se mezclan mucho con las transacciones. Ver también ACID (atomicidad, consistencia, aislamiento, durabilidad). A veces no necesita todo eso, como cuando almacena datos de registros o trabaja en datos que no van a cambiar, simplemente acumule.

bases de datos NoSQL permiten relajar los requisitos para las transacciones y obtener un mejor rendimiento (así como escala para grandes silos de almacenamiento distribuido más fácil).

13

Si usted es Google, entonces usted podría estar en una posición en un NoSQL sería más fácil para usted que un RDBMS. Como no lo es, las muchas ventajas que le ofrece RDBMS probablemente le sirvan de algo. Significativamente, en un solo nodo, NoSQL no ofrece absolutamente ninguna ventaja sobre RDBMS. Sin embargo, RDBMS ofrece muchas ventajas sobre NoSQL. ¿Qué son?

RDBMSes utiliza una magia bastante profunda para comprender los datos que posee, y los datos que está solicitando, de tal manera que pueda devolver esos datos de la manera más eficiente posible. Si no preguntó por alguna columna, la rdbms no pierde el esfuerzo de recuperarla. Si le interesan las filas que tienen campos en común en dos tablas (esta es una unión, por cierto), el RDBMS no tiene que verificar cada par de filas para ver si hay coincidencias, o lo que normalmente hace una base de datos NoSQL es simplemente dar usted todo y hacer que haga la verificación. con un RDBMS, generalmente puede construir consultas que son realmente 'sobre' los datos que está utilizando, como "si la fecha es un martes", y si sus índices lo admiten (si hace esa consulta mucho, entonces agregaría un índice) puede obtener esas filas de manera eficiente.

Hay otra razón por la que los RDBMS son agradables. Las transacciones son fáciles en RDBMS, pero son mucho más difíciles de obtener en bases de datos NoSQL. Supongamos que está implementando un motor de blogs. Supongamos que el título de la publicación (que aparece en la URL) debe ser único en todas las publicaciones. En un RDBMS, puede estar seguro de que no obtendrá este error accidentalmente. Con una base de datos NoSQL, si admite algún tipo de integridad transaccional, por lo general está en el nivel de fragmento, cualquier cosa que pueda requerir ese tipo de integridad debe estar en el mismo fragmento. dado que cualquier par de usuarios podría estar publicando en el mismo momento, entonces la publicación de cada usuario debe estar en el mismo fragmento para obtener el mismo efecto. Bueno, entonces no obtienes ningún beneficio de NoSQL.

+5

'Significativamente, en un solo nodo, NoSQL no ofrece absolutamente ninguna ventaja sobre los RDBMS. Sin embargo, RDBMS ofrece muchas ventajas sobre NoSQL. ¿Qué son?' - erm No. Un ejemplo: los tiempos de escritura en MongoDB son mucho más rápidos que los tiempos de escritura en el servidor MS SQL. Es un poco engañoso estipular que NO HAY ventajas. Puede que no sea el adecuado para ese propósito, pero si buscas velocidad, hay una ventaja allí. –

+2

MongoDB no tiene esquemas, esta es también una gran diferencia en un solo nodo. – TTT

+4

Sí, schemaless es diferente. La pregunta es realmente acerca de por qué sería esto algo bueno? Sospecho un poco de una configuración sin esquema. En teoría, hace los cambios más fáciles. En el nivel de la base de datos, ciertamente lo hace, no tiene que ir a cualquier longitud para agregar o eliminar propiedades en ese nivel. Por otro lado, de ninguna manera hace que las consecuencias semánticas de la migración de la base de datos sean más fáciles. ¿Cuál es el comportamiento correcto al procesar los campos que pueden ser nulos? schemaless no lo alivia en lo más mínimo. – SingleNegationElimination

6

bases de datos NoSQL están muy bien para algunos sitios web donde no necesitas transacción o consistencia donde lo único que está haciendo es presentar algunos datos (pero hasta que llegue muy, muy grande, que no son realmente muy necesario).

Pero si usted necesita para hacer cumplir las normas financieras (u otras reglas de integridad de datos complejos) o controles internos o informes y datos de agregación para la presentación de informes, es necesario un RDBMS. Apostaría que incluso Google usa RDBMS para sus propios recursos humanos y datos financieros, etc.

Para algunas aplicaciones web, es posible que desee una combinación de ambos, la base de datos nosql para algunos tipos de información, la base de datos relacional transaccional para pedidos y otras cosas donde la coherencia transaccional es imprescindible.

Si desarrolla sitios web, creo que es necesario entender a fondo los dos tipos de bases de datos y las necesidades detrás de ellos antes de elegir cómo manejar cualquier funcionalidad nueva.

Me parece que tiene casi ningún conocimiento de las bases de datos relacionales y prefiere hacer lo que es más fácil para usted personalmente de lo que es adecuado para el proyecto. Tal vez no estoy leyendo eso correctamente, pero cualquiera que nunca use las uniones es sospechoso en términos de comprensión de las bases de datos relacionales.

Usted no decide entre estos dos según cuál parece ser más fácil de entender o cuál es la palabra de moda del mes; usted los decide basándose en la funcionalidad que necesitará, no solo para la interfaz de usuario sino también para tareas administrativas , informes, financieros u otros tipos de auditoría de datos, regulación gubernamental, recuperación de datos en caso de falla de hardware, etc.

1

Di una charla en OSCON sobre cuándo NoSQL puede ser la elección correcta, y algunas de las diferentes sub -categorías a tener en cuenta: http://assets.en.oreilly.com/1/event/45/The%20NoSQL%20Ecosystem%20Presentation.pdf

+0

@jbelis: "Las bases de datos relacionales no se escalan", "Las bases de datos relacionales son lentas". Se trata de afirmaciones que podrían aplicarse a determinados productos DBMS. No tienen nada que ver con el modelo relacional. Sería bastante razonable hacer un "RDBMS NOSQL" (es decir, relacional, no SQL) que no tuviera las mismas desventajas percibidas. Como he observado a menudo, los entusiastas de NOSQL a veces parecen demasiado dispuestos a descartar al bebé relacional con el agua de baño SQL :) – sqlvogel

+2

Es extraño que haya bases de datos relacionales con billones de registros, pero la gente aún afirma que no escalan. Solo no escalan cuando eres incompetente en el diseño de la base de datos. – HLGEM

1

Cassandra en sí misma no es mejor que un RDBMS. Es mejor en algunas circunstancias. Un RDBMS es muy superior para el procesamiento de transacciones, gestión de datos maestros, datos de referencia, almacenamiento de datos y (algunas formas de) BI.

Utilice NOSQL si su aplicación requiere un esquema flexible, filas de longitud variable, tipos de columnas variables, integridad eventual, escalabilidad horizontal en servidores básicos y alta disponibilidad lograda mediante una arquitectura distribuida.

NOSQL no hace combinaciones por varias razones: ya se ha unido a los datos antes de cargar el archivo NOSQL, por lo que no es necesario; porque una combinación distribuida en servidores de gran alcance requeriría muchos recursos. La primera razón anterior es simple: ha incorporado todos los datos que necesita en una estructura única. Si no incrusta los datos y tiene que vincularlos, no espere un gran rendimiento. La vinculación es un eufemismo para la unión proporcionada por la aplicación sin el beneficio de consolidar los datos como lo hace una unión. Suponiendo que hash es una clave es el método de distribución de datos, los diferentes registros que tienen la misma clave hash serán colocados. De este modo, si se permitiera la unión, los datos unidos se encontrarían en el mismo servidor.

No es solo blanco y negro.

1

Como muchos libros sobre la mención de NoSQL, no se trata de qué base de datos es mejor que la otra. Es más lo que necesitas.

Como todos dicen en las otras respuestas, muchas bases de datos NoSQL admiten la escalabilidad horizontal y se centran en la alta disponibilidad, pero no siempre son las más adecuadas para sus necesidades.

por ejemplo, Cassandra es ideal para agregar o eliminar nodos de un clúster, lo que permite una gran escalabilidad. Pero cuando compara Cassandra con MySQL en un entorno con un solo nodo (un servidor) y sin arquitectura distribuida, no hay muchas diferencias, ya que las principales ventajas de Cassandra no se utilizan.

Ahora, ¿por qué debería usar SQL? La razón más común es la gestión de transacciones. Actualmente, ninguna base de datos NoSQL popular admite nativamente las transacciones. Puede emularlos, pero no son parte de la funcionalidad nativa como en la mayoría de las bases de datos SQL.

Por Cassandra, hay una formación completa y libre en https://academy.datastax.com

Allí podrá encontrar no sólo entrenamientos para instalar y configurar Cassandra, pero para utilizar sus herramientas. Incluso te da certificados de finalización.

Datastax tiene su propia distribución de Cassandra, pero sigue las mismas pautas que el proyecto Apache; ofrece algunas herramientas adicionales.

3

La respuesta es fácil. Si necesita almacenamiento de datos - use NoSQL, si necesita más funciones y solo almacena datos - use RDBMS.

Cuestiones relacionadas