ventajas usar sirve que para normalizar ejemplos datos cuando bases sql database nosql cassandra

usar - ¿Qué hace a Cassandra(y NoSQL en general) una mejor solución para un RDBMS?



para que usar nosql (12)

Supongo que lo que pregunto es "¿cuándo debo elegir NoSQL sobre RDBMS?"

[Advertencia: nunca antes había leído sobre NoSQL]

Según Wikipedia , NoSQL no es bueno en las uniones: lo que implica (para mí) no hay integridad referencial ni normalización.

Bueno, NoSQL es una palabra de moda en este momento, así que lo he estado investigando. Todavía tengo que entender a ColumnFamilies y SuperColumns, etc ... Pero he estado observando cómo se mapean los datos.

Después de leer this artículo y otros, parece que los datos se asignan en un formato similar a JSON.

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 que mis ejemplos anteriores sean correctos, ¿por qué elegiría el diseño RDBMS sobre el diseño NoSQL? Personalmente, preferiría trabajar con la estructura JSON ... ¿Significa esto que debería elegir NoSQL en lugar de MySQL?

Supongo que lo que pregunto es "¿cuándo debo elegir NoSQL sobre RDBMS?"

Como nota adicional, como he dicho, todavía no entiendo completamente cómo implementar una base de datos Cassandra. Es decir, ¿cómo creo 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 mucho en términos de ''comenzar desde cero'' ...

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, la gestión de datos maestros, los datos de referencia, el almacenamiento de datos y (algunas formas de) BI.

Use NOSQL si su aplicación requiere un esquema flexible, filas de longitud variable, tipos variables de columnas, integridad eventual, escalabilidad horizontal en servidores de productos y alta disponibilidad lograda por medio de una arquitectura distribuida.

NOSQL no hace uniones por varias razones: ya se unió a los datos antes de que se cargara el archivo NOSQL, por lo que no es necesario; porque una unió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 única estructura. Si no incrusta los datos y tiene que vincularlos, no espere un gran rendimiento. La vinculación es un eufemismo para las uniones proporcionadas por la aplicación sin la ventaja de consolidar los datos como lo hace una unión. Suponiendo que el hash de una clave es el método de distribución de datos, se colocarán diferentes registros que tengan la misma clave de hash. De este modo, si se permitiera la unión, todos los datos se encontrarán en el mismo servidor.

No es solo blanco y negro.

Como mencionan muchos libros sobre 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 escalabilidad horizontal y están enfocadas en la alta disponibilidad, pero no siempre son las que mejor se adaptan a sus necesidades.

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

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 popular de NoSQL admite de forma nativa las transacciones. Puede emularlos, pero no forman parte de la funcionalidad nativa como en la mayoría de las bases de datos SQL.

Para Cassandra, hay una capacitación completa y gratuita en https://academy.datastax.com

Allí no solo encontrará capacitaciones para instalar y configurar Cassandra, sino también para utilizar sus herramientas. Incluso te da certificados de finalización.

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

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

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

La respuesta es fácil. Si necesita almacenamiento de datos: use NoSQL, si necesita más funciones que simplemente almacenar datos, use RDBMS.

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

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

La ventaja de la base de datos basada en SQL es que puede reutilizar y ampliar fácilmente sus datos de formas que no estaban previstas en el diseño original. Además, las bases de datos de "Objetos" tienden a tener un rendimiento muy malo (incluso si es posible) cuando se quiere hacer el equivalente de consultas agregadas de SQL como COUNT, SUM, AVG.

Googles BIGTABLE, que es la mayor base de datos de OO en cualquier lugar (y probablemente el mayor período de la base de datos), también admite características SQL y SQL, como la indexación y la escritura fuerte.

Las bases de datos de NoSQl están bien para algunos sitios web en los que no necesita transacciones ni coherencia, ya que todo lo que está haciendo es presentar algunos datos (pero hasta que no sean realmente grandes, no son realmente necesarios).

Pero si necesita hacer cumplir las reglas financieras (u otras reglas complejas de integridad de datos) o los controles internos o los informes y la agregación de datos para los informes, necesita un RDBMS. Apuesto a que incluso Google usa RDBMS ''para sus propios recursos humanos y datos financieros, etc.

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

Si desarrolla sitios web, creo que necesita comprender a fondo ambos tipos de bases de datos y las necesidades detrás de ellas antes de elegir cómo manejar cualquier nueva funcionalidad.

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

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

RDBMS ''son todo acerca de la consistencia. Hacen un gran trabajo en los datos que se revuelven 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 se acumulan.

Las bases de datos NoSQL le permiten relajar los requisitos de las transacciones y obtener un mejor rendimiento (así como escalar a grandes silos de almacenamiento distribuidos más fácilmente).

Si eres google, entonces podrías estar en una posición donde un NoSQL sería más fácil para ti que un RDBMS. Como no lo eres, las muchas ventajas que ofrece un RDBMS probablemente te serán de alguna utilidad. Significativamente, en un solo nodo, NoSQL no ofrece absolutamente ninguna ventaja sobre RDBMS. Sin embargo, los RDBMS ofrecen muchas ventajas sobre NoSQL. ¿Qué son?

Los RDBMS utilizan una magia bastante profunda para comprender los datos que posee y los datos que solicita, de tal manera que puedan devolver esos datos de la manera más eficiente posible. Si no ha preguntado sobre alguna columna, rdbms no desperdicia ningún esfuerzo en recuperarla. Si está interesado en filas que tienen campos en común en dos tablas, (esto es una unión, por cierto), el RDBMS no tiene que verificar cada par de filas para encontrar coincidencias, o lo que un db NoSQL generalmente hace es dar Tú todo y hacerte la comprobación. con un RDBMS, por lo general, puede construir consultas que en realidad sean ''acerca'' de 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á tal información). í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 conseguir en las bases de datos NoSQL. Suponiendo 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 se equivocará accidentalmente. Con una base de datos NoSQL, si es compatible con algún tipo de integridad transaccional, por lo general está en el nivel del 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 cada publicación de los usuarios debe estar en el mismo fragmento para obtener el mismo efecto. Bueno, entonces no obtienes ningún beneficio del NoSQL.

Utilice Cassandra si tiene menos de 50 años y valore tener un sistema de almacenamiento consistente, tolerante a fallos, altamente disponible, altamente escalable y eventualmente capaz de escalar infinitamente con su inicio a big data.

Use SQL si tiene más de 50 años, trabado en sus viejas costumbres, no quiere aprender algo nuevo y se acerca a su jubilación. La escalabilidad no importa si no estás allí para verla.