Estoy trabajando en un proyecto en el que intento decidir entre usar una base de datos relacional SQL estándar o objetos JSON para almacenar datos sobre un evento o actividad.
El proyecto almacenará datos sobre múltiples tipos de eventos, por lo que he decidido describir solo un tipo de evento para esta pregunta.
El evento de música en vivo (descrito en su totalidad usando el esquema JSON al final de esta pregunta) es un objeto que almacena datos como dónde se llevará a cabo el evento, la hora / fecha del evento y el costo del evento. El objeto de evento de música en vivo tiene tanto uno a uno (evento -> nombre, evento -> descripción) como uno a muchos (evento -> lugares, evento -> fechas, evento -> tipos de entradas ) relaciones. Además, el objeto de evento puede contener uno o más ID de intérprete, que enlazan con el objeto de intérprete. El objeto intérprete almacena datos sobre músicos que se presentan en el evento de música en vivo.
Los usuarios consultarán los datos utilizando tanto simples ("Encuéntrame eventos con el nombre 'x'") como complejos ("Encuéntrame eventos con el género musical 'x' y el costo 'y' dentro de un radio de 'z' de mi actual ubicación ") consultas. Los datos serán enviados por los usuarios mediante un formulario web.
Como probablemente pueda deducir del esquema JSON definido, originalmente iba a usar objetos JSON para almacenar estos datos, pero he escuchado de algunas personas que dicen que debido a que mis datos son puramente relacionales, debería seguir los métodos más antiguos.
Agradecería cualquier idea sobre los pros y los contras de cada enfoque dadas mis necesidades. Si necesita algo aclarado, no dude en preguntar.
{
"event": {
"eventID":{
"type":"string"
},
"eventType":{
"type":"array",
"eventTypeItem":{
"type":"string"
}
},
"eventName":{
"type":"string"
},
"eventDescription":{
"type":"string"
},
"eventVenueList":{
"type":"array",
"eventVenueListID":{
"type":"integer"
}
},
"eventURL":{
"type":"string"
},
"eventTwitter":{
"type":"string"
},
"eventFB":{
"type":"string"
},
"eventInstagram":{
"type":"string"
},
"eventEmail":{
"type":"string",
"format":"email"
},
"eventContactPerson":{
"type":"string"
},
"eventDoorTime": {
"type":"string",
"format":"date-time"
},
"eventPerformerIDList":{
"type":"array",
"liveMusicPerformerID":{
"type":"integer"
}
},
"eventSetList":{
"type":"array",
"eventPerformerID":{
"type":"integer"
},
"eventPerformerStartTime":{
"type":"string",
"format":"date-time"
},
"eventPerformerEndTime":{
"type":"string",
"format":"date-time"
}
},
"eventDateList": {
"type":"array",
"eventDateItem": {
"type":"string",
"format":"date-time"
}
},
"eventDateStartTime": {
"type":"string",
"format":"date-time"
},
"eventDateEndTime": {
"type":"string",
"format":"date-time"
},
"eventTicket":{
"type":"array",
"eventTicketType":{
"type":"string"
},
"eventTicketLowPrice":{
"type":"number"
},
"eventTicketHighPrice":{
"type":"number"
},
"eventDatesAdvancePrice": {
"type":"number"
}
}
},
"performer": {
"performerID": {
"type":"integer"
},
"performerType": {
"type":"string"
},
"performerName": {
"type":"string"
},
"performerAlternateName": {
"type":"array",
"performerAlterateNameItem":{
"type":"string"
}
},
"performerGenreList": {
"type":"array",
"performerGenreItem":{
"type":"string"
}
},
"performerURL": {
"type":"string"
}
}
}
Respuestas:
Creo que su pregunta realmente se reduce a: ¿ Cuándo debería usar un enfoque NoSQL versus RDBMS? Te decidiste por JSON temprano (una decisión NoSQL-ish), quizás porque tienes consumidores de Ajax.
La respuesta, por supuesto, a cuándo usar enfoques NoSQL frente a RDBMS es básicamente sobre qué tipo de datos está trabajando y qué consumidores anticipa tener. Si sus datos son esencialmente relacionales (jerarquías bastante planas, no hay tipos de datos extraños como imágenes o audio, relaciones predecibles entre los esquemas que se pueden describir fácilmente en las claves), y se anticipa que sus consumidores eventualmente incluirán personas que deseen realizar consultas de Business Intelligence (consulta ad hoc), entonces un RDBMS es el camino a seguir. Es bastante fácil convertir una consulta en una representación JSON, por lo que no supone una carga significativa para sus consumidores de Ajax: solo agrega una pequeña codificación de transformación en sus puntos finales (REST / SOAP / lo que sea). A la inversa, si sus datos son muy jerárquicos (esquemas profundos), contienen tipos de datos extraños como imágenes, audio, video, etc., existen pocas relaciones entre las entidades y sabe que sus usuarios finales no estarán haciendo BI, entonces NoSQL / almacenamiento JSON puede ser apropiado.
Por supuesto, incluso estas pautas generales no son sólidas. La razón por la que Google desarrolló el Sistema de archivos de Google, MapReduce (trabajo que fue utilizado por Doug Cutting para construir Hadoop en Yahoo) y luego BigQuery (una forma orientada a NoSQL [sin esquemas] de administrar datos a gran escala) fue precisamente porque tenían muchos ad hoc Solicitudes de BI, y no pudieron obtener enfoques relacionales para escalar a las escalas tera / peta / exa / zetta / yotta que estaban tratando de manejar. El único enfoque práctico fue escalar, sacrificando parte de la facilidad de uso de consultas ad-hoc que proporciona un RDBMS, y sustituyendo un algoritmo simple (MapReduce) que podría codificarse con bastante facilidad para cualquier consulta.
Dado su esquema anterior, mi pregunta sería básicamente: ¿Por qué no usaría un RDBMS? No veo muchas razones para no hacerlo. Se supone que nuestra profesión está orientada a la ingeniería, no a la moda, por lo que nuestro instinto debería ser elegir la solución más fácil que funcione, ¿verdad? Es decir, sus puntos finales pueden tener que hacer una pequeña traducción si sus consumidores son Ajaxy, pero sus datos se ven muy planos y parece probable que los usuarios de negocios quieran hacer todo tipo de consultas ad hoc sobre cosas como eventos musicales (que ¿El evento fue más concurrido dentro de 50 millas de nuestra ciudad capital el año pasado?)
'No vayas a los duendes a pedir consejo, porque dirán que no y que sí'. - Frodo
fuente
Creo que hay más consideraciones aquí que quizás no estés buscando. Aquí hay dos preocupaciones generales:
Almacenamiento
Hay muchas opiniones sobre por qué usar no-sql o RDBMS store para sus datos. Uno de los elementos más importantes que pensamos que era útil es que podemos definir y almacenar fácilmente objetos json en el almacenamiento sin tener que preocuparnos por definir su estructura completa o la relación entre los diferentes tipos de objetos. Algunas de las otras razones para usar un NoSql db serían la capacidad de fragmentar automáticamente los datos, las búsquedas basadas en la ubicación y el fácil mantenimiento. Hay muchas buenas bases de datos NoSql, mi preferencia personal es MongoDB. Sin embargo, si no ha utilizado la base de datos NoSql antes, hay una curva de aprendizaje definida a medida que aprende a reconectar su mente. La mayoría de nosotros hemos estado usando RDBMS por un tiempo y se requiere un esfuerzo consciente para salir de ese hábito. Además, se encontrará con ganas de rehacer su modelo de datos a medida que avance junto con sus esfuerzos y tenga una mejor comprensión de los conceptos. Si la capacidad de refactorizar o remodelar no es una opción para su proyecto, le sugiero que se quede con lo que ya conoce mejor.
Buscar
Si tiene la intención de proporcionar cualquier tipo de búsqueda que sea utilizable, le sugiero que utilice un motor de búsqueda de texto dedicado como SOLR para realizar sus búsquedas. Las búsquedas de texto son lentas y, si tiene varios fragmentos, aún más lento. SOLR admite búsquedas rápidas de texto que incluyen parámetros de búsqueda ponderados, búsquedas basadas en la ubicación y mucho más. Sin embargo, SOLR no es adecuado como almacén principal de sus datos. Esto significa que tendrá que crear mecanismos para doble inserción y actualización tanto para su base de datos primaria como para su capa SOLR al agregar o actualizar eventos. Además, tendrá que mantener el SOLR actualizado más adelante eliminando cualquier evento desactualizado / finalizado.
Aunque esto parece mucho trabajo extra, te agradecerás por la previsión de usar un motor de búsqueda de texto completo más adelante. Ninguna de las bases de datos NoSql o RDBMS se acercan al rendimiento y la agilidad de SOLR / Lucene.
fuente
Primero, si está tratando de almacenar datos JSON en cualquier almacenamiento pero no en una base de datos NoSQL , definitivamente lo desaconsejaría que use JSON. La razón es que si almacena sus datos como un archivo JSON, por ejemplo, será extremadamente lento abrirlo, analizarlo, recorrerlo, etc.
Dicho esto, puedo limitar su pregunta a: ¿Cuáles son los pros y los contras de NoSQL y RDBMS ? Y ya ha sido respondido miles de veces en la red.
Al volver a clasificar su proyecto, puede usar NoSQL o RDBMS ; Sin embargo, lo que generalmente puedo recomendarle es que piense fuera de la caja y busque otros factores menos visibles que podrían ayudarlo a decidir entre las dos opciones. ¿Intenta ver qué opción podría acelerar el desarrollo? Cuál es más adecuado para los otros miembros del equipo, si no eres un desarrollador exclusivo. Si está vendiendo esto, ¿cuál es más barato, más fácil y generalmente más adecuado para sus clientes no desarrolladores?
De esta manera, finalmente puede decidir qué camino tomar, de lo contrario será muy difícil decidir en función de la información dada, ya que ambas opciones podrían encajar bastante bien.
fuente
En la mayoría de las aplicaciones hay requisitos para
Para cumplir con los requisitos del Ítem 1, se requiere un método de datos persistentes. Por lo general, si el volumen de datos es muy pequeño y el tipo de datos es simple y no requiere amplias capacidades de búsqueda, se puede utilizar una estructura de archivo simple. A medida que los datos se vuelven más complejos, se puede usar una estructura XML (o incluso JSON) con los datos aún almacenados en archivos. Sin embargo, buscar se vuelve más problemático. A medida que aumenta el volumen de datos y aumenta la complejidad de las búsquedas, normalmente se selecciona una base de datos que proporciona métodos estándar de la industria para la persistencia de datos, consultas, etc. Las bases de datos pueden diseñarse para manejar grandes volúmenes de datos y almacenar, recuperar y buscar los datos de manera rápida y eficiente .
Para cumplir con los requisitos del Artículo 2, existen varios métodos diferentes para permitir el intercambio de datos entre sistemas, incluidos XML, JSON, etc.
Estos métodos permiten que un usuario defina la estructura de datos y son independientes del idioma, lo que permite que un sistema diferente intercambie datos.
En su caso particular, está utilizando correctamente JSON está describiendo un conjunto de eventos musicales. Si bien podría almacenar los datos en formato JSON, la búsqueda de estos datos a medida que aumenta el número de eventos musicales será lenta e ineficiente.
El uso de un enfoque de separación de preocupaciones, entonces un mejor enfoque es recopilar los datos, almacenarlos en una base de datos, realizar su consulta en función de la entrada del usuario en la base de datos y luego devolver los resultados en formato JSON al lado del Cliente para mostrar los datos.
Un problema adicional con el enfoque JSON es una estructura de datos cambiante. Actualmente su estructura es relativamente simple. Puede usar esta estructura durante varios meses y luego se identifica un campo adicional. ¿Qué haces con todos tus objetos JSON existentes? Actualizarlos sería problemático.
Si usó una base de datos, agregar un campo adicional es relativamente simple y solo su código para generar el JSON necesitaría modificarse en un solo lugar, lo que le brindaría todos los nuevos JSON con el nuevo campo.
En resumen, utilice cada pieza de tecnología para lo que fue diseñada para JSON para el intercambio de datos y una base de datos para la persistencia de datos.
fuente
Creo que tendrá más éxito con el uso de NoSQL que SQL para almacenar estos datos, debido a las consultas que debe hacer.
Además, el hecho de que algunos datos sean puramente relacionales ya no significa que deben mantenerse en algunos RDBMS (SQL). Los datos relacionales de la OMI se traducirían mejor en bases de datos de gráficos.
Por supuesto, también puede escribir las consultas en SQL, pero el rendimiento será terrible debido a la cantidad de uniones que necesitará (teniendo en cuenta que sus datos estarán algo normalizados y no todos en una sola tabla de eventos).
Pero en conclusión, tendrá más libertad utilizando NoSQL (por lo tanto, JSON o algún otro formato compatible con la base de datos), ya que puede modificar su esquema en el futuro sin tener en cuenta los datos ya persistentes.
Teniendo en cuenta NoSQL, también podría buscar en bases de datos de gráficos si planea usar consultas muy complejas, ya que estas le darán ventajas para crearlas fácilmente y también para ejecutarlas muy rápido.
fuente
Creo que deberías usar ambos y no lo veo como una decisión 'versus'.
Una base de datos relacional tiene sentido para el almacenamiento y la recuperación rápida y eficiente de datos que tienen propiedades relacionales.
JSON es un excelente formato de datos porque es simple, liviano e ideal para pasar datos sin procesar en un formato muy básico con una sintaxis adecuada para almacenar e intercambiar información de texto. Es ideal para pasar pequeñas cantidades de datos entre un navegador y un servidor. No está en un formato tan fácil de comenzar a usar para consultas de datos de tipo relacional.
Por lo tanto, recomendaría SQL para el almacenamiento de datos y JSON para el formato de transporte de datos.
Es cierto que no hay opciones de valor-clave SQL como Mongo, Redis, etc. Estas tendrían la ventaja de una asignación posiblemente más simple al formato JSON, pero generalmente son un poco más difíciles de usar para consultas. El principal obstáculo con ellos es la falta de familiaridad de la comunidad de TI en general, especialmente en comparación con SQL, que es tan conocido y tiene una amplia gama de recursos y conocimientos disponibles para casi todas las situaciones imaginables.
fuente