Cuánto debo cobrar por mis servicios a2 en el 2017

Hace dos años nos haciamos la misma pregunta y aunque sonaba
descabellado precios como 900 o 1200 Bs. por hora de servicios cumplian
de alguna forma con las espectativas del mercado. Pasado ese tiempo nos
damos cuenta de la dura realidad y de la inflación extrema que estamos
padeciendo.

No odies WordPress: 5 prejuicios comunes

No odies WordPress: 5 prejuicios comunes

En los primeros tiempos, la gente utilizaba WordPress sólo como una herramienta para blogs. Sin embargo, hoy en día WordPress cubre más del 50 por ciento de la cuota de mercado de los CMS, el apoyo a casi 60 millones de sitios web en todo el mundo.


Como una plataforma de uso común para la
construcción de sitios web y otras aplicaciones en línea, los conceptos
erróneos se han extendido como un incendio forestal, manteniendo a la
gente lejos de WordPress.


En este artículo, esbozo y explicar los cinco tabúes y mitos más comunes de WordPress, aclararlos y ofrecer soluciones sobre


cómo superarlos.

La Guía Definitiva a las Bases de Datos NoSQL

No hay duda de que la forma en que las aplicaciones web se ocupan de los datos ha cambiado significativamente en la última década. Se están recopilando más datos y más usuarios acceden a estos datos al mismo tiempo que nunca. Esto significa que la escalabilidad y el rendimiento son más un reto que nunca para las bases de datos relacionales que están basadas en esquemas y, por lo tanto, pueden ser más difíciles de escalar.

La evolución de NoSQL

El problema de escalabilidad de SQL fue reconocido por empresas de Web 2.0 con enormes y crecientes necesidades de datos e infraestructura, como Google, Amazon y Facebook. Ellos surgieron con sus propias soluciones al problema - tecnologías como BigTable , DynamoDB y Cassandra .

Este interés creciente dio lugar a una serie de sistemas de gestión de base de datos NoSQL (DBMS), con un enfoque en el rendimiento, la fiabilidad y la coherencia. Se reutilizaron y mejoraron varias estructuras de indexación existentes con el propósito de mejorar la búsqueda y el rendimiento de lectura.

En primer lugar, había tipos de bases de datos NoSQL de código abierto (fuente cerrada) desarrolladas por grandes empresas para satisfacer sus necesidades específicas, como BigTable de Google, que se cree es el primer sistema NoSQL y DynamoDB de Amazon.

El éxito de estos sistemas patentados inició el desarrollo de una serie de sistemas similares de bases de datos de código abierto y propietarios, siendo los más populares Hypertable, Cassandra, MongoDB, DynamoDB, HBase y Redis.

¿Qué hace que NoSQL sea diferente?

Una diferencia clave entre las bases de datos NoSQL y las bases de datos relacionales tradicionales es el hecho de que NoSQL es una forma de almacenamiento no estructurado .

Esto significa que las bases de datos NoSQL no tienen una estructura de tabla fija como las que se encuentran en las bases de datos relacionales.

Ventajas y desventajas de las bases de datos NoSQL

Ventajas

Las bases de datos NoSQL tienen muchas ventajas en comparación con las bases de datos relacionales tradicionales.

Una de las principales diferencias subyacentes es que las bases de datos NoSQL tienen una estructura simple y flexible. Están libres de esquemas.

A diferencia de las bases de datos relacionales, las bases de datos NoSQL se basan en pares clave-valor.

Algunos tipos de almacén de bases de datos NoSQL incluyen almacén de columnas, almacén de documentos, almacén de valores clave, almacén de gráficos, almacén de objetos, almacén XML y otros modos de almacén de datos.

Normalmente, cada valor en la base de datos tiene una clave. Algunos almacenes de base de datos NoSQL también permiten a los desarrolladores almacenar objetos serializados en la base de datos, no sólo valores de cadena simple.

Las bases de datos NoSQL de código abierto no requieren tarifas de licencia caras y pueden ejecutarse con hardware económico, lo que hace que su implementación sea rentable.

Además, cuando se trabaja con bases de datos NoSQL, sean de código abierto o propietario, la expansión es más fácil y más barata que cuando se trabaja con bases de datos relacionales. Esto se debe a que se realiza escalando horizontalmente y distribuyendo la carga en todos los nodos, en lugar del tipo de escala vertical que se suele hacer con los sistemas de bases de datos relacionales, que está reemplazando al host principal por uno más potente.

Desventajas

Por supuesto, las bases de datos NoSQL no son perfectas, y no siempre son la elección correcta.

En primer lugar, la mayoría de las bases de datos NoSQL no admiten funciones de fiabilidad que sean soportadas nativamente por sistemas de bases de datos relacionales. Estas características de fiabilidad pueden resumirse como atomicidad, consistencia, aislamiento y durabilidad. Esto también significa que las bases de datos NoSQL, que no soportan esas características, consistencia de comercio para el rendimiento y la escalabilidad.

Con el fin de apoyar las características de fiabilidad y coherencia, los desarrolladores deben implementar su propio código propietario, lo que agrega más complejidad al sistema.

Esto podría limitar el número de aplicaciones que pueden confiar en bases de datos NoSQL para transacciones seguras y confiables, como los sistemas bancarios.

Otras formas de complejidad encontradas en la mayoría de las bases de datos NoSQL incluyen la incompatibilidad con consultas SQL. Esto significa que se necesita un lenguaje de consulta manual o propietario, lo que añade aún más tiempo y complejidad.

NoSQL vs. Bases de datos relacionales

Esta tabla ofrece una breve comparación de características entre NoSQL y las bases de datos relacionales:

Cabe señalar que la tabla muestra una comparación en el nivel de la base de datos , no los diversos sistemas de gestión de base de datos que implementan ambos modelos. Estos sistemas proporcionan sus propias técnicas propietarias para superar algunos de los problemas y deficiencias en ambos sistemas, y en algunos casos, mejorar significativamente el rendimiento y la fiabilidad.

Tipos de almacenes de datos NoSQL

Almacén de valores clave

En el tipo de almacén Key Value, se utiliza una tabla hash en la que una clave única apunta a un elemento.

Las llaves se pueden organizar en grupos lógicos de claves, requiriendo solamente claves para ser únicas dentro de su propio grupo. Esto permite tener claves idénticas en diferentes grupos lógicos. La siguiente tabla muestra un ejemplo de un almacén de valores clave, en el que la clave es el nombre de la ciudad y el valor es la dirección de Ulster University en esa ciudad.

Algunas implementaciones del almacén de valor clave proporcionan mecanismos de almacenamiento en caché, lo que mejora en gran medida su rendimiento.

Todo lo que se necesita para hacer frente a los elementos almacenados en la base de datos es la clave. Los datos se almacenan en una forma de una cadena, JSON o BLOB (objeto grande binario).

Uno de los mayores defectos en esta forma de base de datos es la falta de consistencia en el nivel de la base de datos. Esto puede ser agregado por los desarrolladores con su propio código, pero como se mencionó anteriormente, esto agrega más esfuerzo, complejidad y tiempo.

La base de datos NoSQL más famosa que se construye en un almacén de valores clave es DynamoDB de Amazon.

Tienda de documentos

Los almacenes de documentos son similares a los almacenes de valores clave porque no tienen esquema y se basan en un modelo de valor-clave. Ambos, por lo tanto, comparten muchas de las mismas ventajas y desventajas. Ambos carecen de consistencia en el nivel de base de datos, lo que hace posible que las aplicaciones ofrezcan más fiabilidad y características de coherencia.

Sin embargo, hay diferencias clave entre los dos.

En Almacenes de documentos, los valores (documentos) proporcionan codificación para los datos almacenados. Esas codificaciones pueden ser XML, JSON o BSON (JSON codificado binario) .

También, la consulta basada en datos se puede hacer.

La aplicación de base de datos más popular que se basa en un almacén de documentos es MongoDB.

Tienda de columnas

En una base de datos de almacén de columnas, los datos se almacenan en columnas, en lugar de almacenarse en filas, como se hace en la mayoría de los sistemas de gestión de bases de datos relacionales.

Un almacén de columnas está compuesto por una o más familias de columnas que agrupan de forma lógica determinadas columnas en la base de datos. Una clave se utiliza para identificar y señalar a un número de columnas en la base de datos, con un atributo de espacio de teclado que define el ámbito de esta clave. Cada columna contiene tuplas de nombres y valores, ordenados y separados por comas.

Los almacenes de columnas tienen acceso rápido de lectura / escritura a los datos almacenados. En un almacén de columnas, las filas que corresponden a una sola columna se almacenan como una sola entrada de disco. Esto facilita el acceso durante las operaciones de lectura / escritura.

Las bases de datos más populares que usan el almacén de columnas incluyen Google BigTable, HBase y Cassandra.

Base del gráfico

En una base de datos Graph Base NoSQL, se utiliza una estructura de gráfico dirigida para representar los datos. El gráfico está compuesto de bordes y nodos.

Formalmente, un gráfico es una representación de un conjunto de objetos, donde algunos pares de los objetos están conectados por enlaces. Los objetos interconectados están representados por abstracciones matemáticas, llamadas vértices, y los enlaces que conectan algunos pares de vértices se llaman bordes. Un conjunto de vértices y los bordes que los conectan se dice que es un gráfico.

Esto ilustra la estructura de una base de datos de base gráfica que utiliza bordes y nodos para representar y almacenar datos. Estos nodos están organizados por algunas relaciones entre sí, que se representa por los bordes entre los nodos. Tanto los nodos como las relaciones tienen algunas propiedades definidas.

Las bases de datos de gráficos suelen utilizarse en aplicaciones de redes sociales. Las bases de datos de gráficos permiten a los desarrolladores centrarse más en las relaciones entre los objetos que en los propios objetos. En este contexto, de hecho permiten un entorno escalable y fácil de usar.

Actualmente, InfoGrid y InfiniteGraph son las bases de datos gráficas más populares.

Sistemas de gestión de bases de datos NoSQL

Para una breve comparación de las bases de datos, la siguiente tabla ofrece una breve comparación entre diferentes sistemas de gestión de base de datos NoSQL.

MongoDB tiene un almacenamiento de esquema flexible, lo que significa que los objetos almacenados no necesariamente tienen que tener la misma estructura o campos. MongoDB también tiene algunas características de optimización, que distribuye las colecciones de datos a través de, lo que resulta en la mejora del rendimiento general y un sistema más equilibrado.

Otros sistemas de base de datos NoSQL, como Apache CouchDB, también son base de datos de tipo de almacén de documentos y comparten muchas características con MongoDB, con la excepción de que se puede acceder a la base de datos utilizando APIs RESTful.

REST es un estilo arquitectónico que consiste en un conjunto coordinado de restricciones arquitectónicas aplicadas a componentes, conectores y elementos de datos, dentro de la World Wide Web. Se basa en un protocolo de comunicaciones apilables, cliente-servidor, cacheable (por ejemplo, el protocolo HTTP).

Las aplicaciones RESTful utilizan peticiones HTTP para publicar, leer datos y eliminar datos.

En cuanto a bases de datos de bases de columnas, Hypertable es una base de datos NoSQL escrita en C ++ y basada en BigTable de Google.

Hypertable soporta la distribución de almacenes de datos en los nodos para maximizar la escalabilidad, al igual que MongoDB y CouchDB.

Una de las bases de datos NoSQL más utilizadas es Cassandra, desarrollada por Facebook.

Cassandra es una base de datos de almacenes de columnas que incluye muchas características dirigidas a la fiabilidad y tolerancia a fallos.

En lugar de proporcionar una mirada en profundidad a cada SGBD NoSQL, Cassandra y MongoDB, dos de los sistemas de gestión de base de datos NoSQL más ampliamente utilizados, se explorará en las subsecciones siguientes.

Cassandra

Cassandra es un sistema de gestión de bases de datos desarrollado por Facebook.

El objetivo detrás de Cassandra era crear un DBMS que no tenga un único punto de fallo y que proporcione la máxima disponibilidad.

Cassandra es principalmente una base de datos de almacenes de columnas. Algunos estudios se refieren a Cassandra como un sistema híbrido, inspirado en BigTable de Google, que es una base de datos de almacén de columnas, y DynamoDB de Amazon, que es una base de datos de valor clave.

Esto se consigue proporcionando un sistema de valor clave, pero las claves de Cassandra apuntan a un conjunto de familias de columnas, dependiendo del sistema de archivos distribuido BigTable de Google y las características de disponibilidad de Dynamo (tabla hash distribuida).

Cassandra está diseñado para almacenar enormes cantidades de datos distribuidos a través de diferentes nodos. Cassandra es un DBMS diseñado para manejar cantidades masivas de datos, repartidos entre muchos servidores, al mismo tiempo que proporciona un servicio altamente disponible sin ningún punto de fallo, lo cual es esencial para un gran servicio como Facebook.

Las principales características de Cassandra incluyen:

• No hay un solo punto de fracaso. Para que esto se logre, Cassandra debe funcionar en un grupo de nodos, en lugar de una sola máquina. Eso no significa que los datos de cada clúster sean los mismos, pero sí el software de gestión. Cuando ocurre un fallo en uno de los nodos, los datos de ese nodo serán inaccesibles. Sin embargo, otros nodos (y datos) seguirán siendo accesibles.
• Hashing distribuido es un esquema que proporciona la funcionalidad de tabla hash de manera que la adición o eliminación de una ranura no cambia significativamente la asignación de claves a las ranuras. Esto proporciona la capacidad de distribuir la carga a los servidores o nodos según su capacidad y, a su vez, minimizar el tiempo de inactividad.
• Interfaz de cliente relativamente fácil de usar . Cassandra utiliza Apache Thrift para su interfaz de cliente. Apache Thrift proporciona un cliente RPC en varios idiomas, pero la mayoría de los desarrolladores prefieren alternativas de código abierto construidas sobre Apple Thrift, como Hector.
• Otras características de disponibilidad. Una de las características de Cassandra es la replicación de datos. Básicamente, refleja datos a otros nodos del clúster. La replicación puede ser aleatoria o específica para maximizar la protección de datos colocándola en un nodo en un centro de datos diferente, por ejemplo. Otra característica encontrada en Cassandra es la política de partición. La directiva de partición decide dónde en qué nodo colocar la clave. Esto también puede ser aleatorio o en orden. Al utilizar ambos tipos de políticas de particionamiento, Cassandra puede lograr un equilibrio entre el equilibrio de carga y la optimización del rendimiento de las consultas.
• Consistencia. Funciones como la replicación hacen que la consistencia sea un desafío. Esto se debe al hecho de que todos los nodos deben estar actualizados en cualquier punto en el tiempo con los valores más recientes o en el momento en que se activa una operación de lectura. Eventualmente, sin embargo, Cassandra intenta mantener un equilibrio entre las acciones de replicación y las acciones de lectura / escritura proporcionando esta personalización al desarrollador.
• Acciones de lectura / escritura. El cliente envía una solicitud a un solo nodo de Cassandra. El nodo, de acuerdo con la política de replicación, almacena los datos en el clúster. Cada nodo realiza primero el cambio de datos en el registro de confirmación y, a continuación, actualiza la estructura de la tabla con el cambio, ambos hechos de forma sincrónica. La operación de lectura también es muy similar, una petición de lectura se envía a un solo nodo y ese único nodo es el que determina qué nodo contiene los datos, de acuerdo con la política de particionamiento / ubicación.

MongoDB

MongoDB es una base de datos libre de esquemas, orientada a documentos, escrita en C ++. La base de datos está basada en almacén de documentos, lo que significa que almacena valores (denominados documentos) en forma de datos codificados.

La elección del formato codificado en MongoDB es JSON. Esto es potente, porque incluso si los datos están anidados dentro de documentos JSON, seguirá siendo consulta e indexable .

Las subsecciones que siguen describen algunas de las características clave disponibles en MongoDB.

Fragmentos

Sharding es la partición y distribución de datos a través de múltiples máquinas (nodos). Un fragmento es una colección de nodos MongoDB, en contraste con Cassandra donde los nodos están simétricamente distribuidos. El uso de fragmentos también significa la capacidad de escalar horizontalmente a través de múltiples nodos. En el caso de que haya una aplicación que utilice un único servidor de base de datos, puede convertirse en un clúster fragmentado con muy pocos cambios en el código de la aplicación original porque la forma en que Sharding es ejecutada por MongoDB. Oftware está casi completamente desacoplado de las API públicas expuestas al lado del cliente.

Mongo Query Language

Como se mencionó anteriormente, MongoDB utiliza una API RESTful. Para recuperar ciertos documentos de una colección db, se crea un documento de consulta que contiene los campos que deben coincidir con los documentos deseados.

Comportamiento

En MongoDB, hay un grupo de servidores llamados enrutadores. Cada uno actúa como un servidor para uno o más clientes. Del mismo modo, el clúster contiene un grupo de servidores denominados servidores de configuración. Cada uno contiene una copia de los metadatos que indican qué fragmento contiene qué datos. Las acciones de lectura o escritura se envían desde los clientes a uno de los servidores de enrutador del clúster y son encaminadas automáticamente por ese servidor a los fragmentos adecuados que contienen los datos con la ayuda de los servidores de configuración.

Similar a Cassandra, un fragmento en MongoDB tiene un esquema de replicación de datos, que crea un conjunto de réplicas de cada fragmento que contiene exactamente los mismos datos. Hay dos tipos de esquemas de réplica en MongoDB: replicación Maestro-Esclavo y replicación de Réplica-Conjunto. Replica-Set proporciona más automatización y mejor manejo para los fallos, mientras que Master-Slave requiere a veces la intervención del administrador. Independientemente del esquema de replicación, en cualquier punto del tiempo en un conjunto de réplicas, sólo un fragmento actúa como fragmento primario, todos los fragmentos de réplica son fragmentos secundarios. Todas las operaciones de escritura y lectura pasan al fragmento primario y luego se distribuyen de forma uniforme (si es necesario) a los otros fragmentos secundarios del conjunto.

En el gráfico de abajo, vemos la arquitectura de MongoDB explicada anteriormente, mostrando los servidores del enrutador en verde, los servidores de configuración en amarillo y los fragmentos que contienen los nodos MongoDB azules.

Debe tenerse en cuenta que el sharding (o compartir los datos entre fragmentos) en MongoDB es completamente automático, lo que reduce la tasa de fallos y hace MongoDB un sistema de gestión de base de datos altamente escalable.

Estructuras de indexación para bases de datos NoSQL

La indexación es el proceso de asociar una clave con la ubicación de un registro de datos correspondiente en un DBMS. Hay muchas estructuras de datos de indexación utilizadas en las bases de datos NoSQL. Las siguientes secciones discutirán brevemente algunos de los métodos más comunes; A saber, la indexación de los árboles B, la indexación de los árboles T y la indexación de los árboles O2.

Indexación de árboles B

B-Tree es una de las estructuras de índice más comunes en DBMS.

En los árboles B, los nodos internos pueden tener un número variable de nodos secundarios dentro de un rango predefinido.

Una diferencia importante de otras estructuras de árbol, como AVL, es que B-Tree permite que los nodos tengan un número variable de nodos secundarios, lo que significa menos equilibrio de árbol, pero más espacio perdido.

El B + -Tree es una de las variantes más populares de B-Trees. El B + -Tree es una mejora sobre B-Tree que requiere todas las claves para residir en las hojas.

Indexación de árboles en T

La estructura de datos de T-Trees fue diseñada combinando características de AVL-Trees y B-Trees.

AVL-Árboles son un tipo de auto-equilibrio binario árboles de búsqueda, mientras que B-Árboles son desequilibrados, y cada nodo puede tener un número diferente de niños.

En un T-Tree, la estructura es muy similar al AVL-Tree y el B-Tree.

Cada nodo almacena más de una tupla {key-value, pointer}. Además, la búsqueda binaria se utiliza en combinación con los nodos de múltiples tuplas para producir un mejor almacenamiento y rendimiento.

Un T-Tree tiene tres tipos de nodos: Un T-Node que tiene un hijo derecho e izquierdo, un nodo foliar sin hijos y un nodo de media hoja con un solo hijo.

Se cree que los T-Trees tienen un mejor rendimiento general que los AVL-Trees.

Indexación de árboles O2

El O2-Tree es básicamente una mejora sobre los árboles Red-Black, una forma de un árbol de Binary-Search, en el que los nodos hoja contienen el valor {key value, pointer} tuplas.

O2-Tree fue propuesto para mejorar el rendimiento de los actuales métodos de indexación. Un árbol de O2 de orden m (m ≥ 2), donde m es el grado mínimo del árbol, satisface las siguientes propiedades:

• Cada nodo es rojo o negro. La raíz es negra.
• Cada nodo de hoja está coloreado en negro y consiste en un bloque o página que contiene pares de "valor clave, record-pointer".
• Si un nodo es rojo, entonces sus dos hijos son negros.
• Para cada nodo interno, todas las rutas simples desde el nodo hasta los nodos-hoja descendientes contienen el mismo número de nodos negros. Cada nodo interno tiene un único valor de clave.
• Los nodos de hoja son bloques que tienen entre ⌈m / 2⌉ y m pares "key-value, record-pointer".
• Si un árbol tiene un solo nodo, entonces debe ser una hoja, que es la raíz del árbol, y puede tener entre 1 a m elementos de datos clave.
• Los nodos de hoja están dobles en direcciones hacia adelante y hacia atrás.

Aquí vemos una comparación directa de rendimiento entre O2-Tree, T-Tree, B + -Tree, AVL-Tree y Red-Black Tree:

El orden del T-Tree, B + -Tree y el O2-Tree utilizado fue m = 512.

El tiempo se registra para las operaciones de búsqueda, inserción y eliminación con relaciones de actualización que varían entre 0% -100% para un índice de 50M de registros, con las operaciones resultando en la adición de otros 50M registros al índice.

Está claro que con una proporción de actualización de 0-10%, B-Tree y T-Tree tienen mejores resultados que O2-Tree. Sin embargo, con la relación de actualización aumentando, el índice de O2-Árbol realiza significativamente mejor que la mayoría de otras estructuras de datos, con las estructuras B-Tree y Red-Black Tree que sufren más.

¿El caso de NoSQL?

Una rápida introducción a las bases de datos NoSQL, destacando las áreas clave en las que las bases de datos relacionales tradicionales se quedan cortas, conduce al primer takeaway:

"Aunque las bases de datos relacionales ofrecen consistencia, no están optimizadas para un alto rendimiento en aplicaciones en las que se almacenan y procesan datos masivos con frecuencia".

Las bases de datos NoSQL ganaron mucha popularidad debido a su alto rendimiento, alta escalabilidad y facilidad de acceso; Sin embargo, todavía carecen de las características que proporcionan consistencia y confiabilidad.

Afortunadamente, una serie de DBMS NoSQL abordan estos desafíos ofreciendo nuevas características para mejorar la escalabilidad y la fiabilidad.

No todos los sistemas de base de datos NoSQL funcionan mejor que las bases de datos relacionales.

MongoDB y Cassandra tienen un rendimiento similar, y en la mayoría de los casos mejor, que las bases de datos relacionales en operaciones de escritura y eliminación.

No hay correlación directa entre el tipo de tienda y el rendimiento de un DBMS NoSQL. Las implementaciones de NoSQL experimentan cambios, por lo que el rendimiento puede variar.

Por lo tanto, las mediciones de rendimiento a través de tipos de base de datos en diferentes estudios siempre deben actualizarse con las últimas versiones del software de base de datos para que estos números sean exactos.

Aunque no puedo ofrecer un veredicto definitivo sobre el rendimiento, he aquí algunos puntos a tener en cuenta:

• La indexación tradicional de árboles B y árboles T se utiliza comúnmente en bases de datos tradicionales.
• Un estudio ofreció mejoras y mejoras mediante la combinación de las características de múltiples estructuras de indexación para llegar a la O2-Árbol.
• El O2-Tree superó a otras estructuras en la mayoría de las pruebas, especialmente con enormes conjuntos de datos y altas proporciones de actualización.
• La estructura B-Tree presentó el peor desempeño de todas las estructuras de indexación cubiertas en este artículo.

Se puede y debe hacer más trabajo para mejorar la consistencia de los DBMS de NoSQL. La integración de ambos sistemas, NoSQL y bases de datos relacionales, es un área para explorar aún más.

Por último, es importante tener en cuenta que NoSQL es una buena adición a los estándares de base de datos existentes, pero con algunas advertencias importantes. NoSQL comercializa funciones de confiabilidad y consistencia para un gran rendimiento y escalabilidad. Esto lo convierte en una solución especializada, ya que el número de aplicaciones que pueden depender de bases de datos NoSQL sigue siendo limitado.

¿El alza? La especialización puede no ofrecer mucho en el camino de la flexibilidad, pero cuando usted quiere conseguir un trabajo especializado hecho tan rápido y eficientemente como sea posible, usted no necesita una navaja suiza. Necesitas NoSQL.

Por: MOHAMAD ALTARADE - INGENIERO DE SOFTWARE @ TOPTAL

#Database #DBMS #NoSQL #SQL
This article was originally written in English

Artículo original en Ingles: https://www.toptal.com/database/the-definitive-guide-to-nosql-databases