La interpretación cortés de "NoSQL" se ha convertido en Not Only SQL . Si tiene datos que son realmente relacionales, o si su funcionalidad depende de cosas como uniones y ACIDity, entonces debe almacenar esos datos de forma relacional. En esta publicación, explicaré cómo uso MySQL junto con dos Almacenes de datos NoSQL. El almacenamiento de datos moderno a escala web tiene que ver con comprender cómo elegir las mejores herramientas para el trabajo.
Dicho esto, NoSQL es realmente una reacción al hecho de que el método relacional y la forma de pensar se han aplicado a problemas en los que en realidad no encaja muy bien (normalmente tablas enormes con decenas de millones de filas o más). Una vez que las tablas se vuelven tan grandes, la "mejor práctica" típica de SQL ha sido fragmentar manualmente los datos, es decir, colocar los registros del 1 al 10 000 000 en la tabla A, del 10 000 001 al 20 000 001 en la tabla B, y así sucesivamente. Luego, normalmente en la capa del modelo de aplicación, las búsquedas se realizan de acuerdo con este esquema. Esto es lo que se llama application-aware escalada. Requiere mucho tiempo y es propenso a errores, pero escalar algo mientras se mantiene MySQL para el almacenamiento de tablas largas, se ha convertido en un MO más o menos estándar. NoSQL representa, para mí, el application-unaware alternativa.
Valor-clave
Cuando tuve un prototipo de MySQL que comenzó a crecer demasiado para su propio bien, moví personalmente la mayor cantidad de datos posible a la veloz Membase , que supera a Memcached y agrega persistencia. Membase es un almacén de clave-valor distribuido que escala de manera más o menos lineal (Zynga lo usa para manejar medio millón de operaciones por segundo, por ejemplo) agregando más servidores básicos a un clúster; por lo tanto, es un genial apto para la era de la nube de Amazon EC2 , Joyent , etc.
Es bien sabido que los almacenes de clave-valor distribuidos son la mejor manera de obtener una escala lineal enorme. La debilidad de clave-valor es la capacidad de consulta y la indexación. Pero incluso en el mundo relacional, la mejor práctica para la escalabilidad es descargar tanto esfuerzo en los servidores de aplicaciones como sea posible, haciendo uniones en la memoria en servidores de aplicaciones básicos en lugar de pedirle al clúster RDB central que maneje toda esa lógica. Desde simple select más application logic son realmente la mejor manera de lograr una escala masiva incluso en MySQL, la transición a algo como Membase (o sus competidores como Riak
) no es tan malo.
Tiendas de documentos
A veces, aunque diría que con menos frecuencia de lo que muchos piensan, el diseño de una aplicación requiere inherentemente índices secundarios, capacidad de consulta de rango, etc. El enfoque NoSQL para esto es a través de un document store como MongoDB
. Al igual que Membase, Mongo es muy bueno en algunas áreas donde las bases de datos relacionales son particularmente débiles, como application-unaware escalado, auto-sharding y maintaining flat response times even as dataset size balloons . Es significativamente más lento que Membase y un poco más complicado hacer una escala horizontal pura, pero el beneficio es que es altamente consultable. Puede consultar parámetros y rangos en tiempo real, o puede usar Map/Reduce para realizar operaciones por lotes complejas en conjuntos de datos verdaderamente enormes.
En el mismo proyecto que mencioné anteriormente, que usa Membase para servir toneladas de datos de jugadores en vivo, usamos MongoDB para almacenar datos de análisis/métricas, que es realmente donde MongoDB brilla.
Por qué mantener las cosas en SQL
Mencioné brevemente el hecho de que la información 'verdaderamente relacional' debe permanecer en las bases de datos relacionales. Como señala el comentarista Dan K., me perdí la parte en la que analizo las desventajas de dejar RDBMS, o al menos de dejarlo por completo.
Primero, está el propio SQL. SQL es bien conocido y ha sido un estándar de la industria durante mucho tiempo. Algunas bases de datos "NoSQL" como App Engine
de Google El almacén de datos (construido en Big Table) implementa su propio lenguaje similar a SQL (el de Google se llama, lindamente, GQL por Google Query Language ). MongoDB adopta un nuevo enfoque para el problema de las consultas con sus deliciosos objetos de consulta JSON
. Aún así, SQL en sí es una herramienta poderosa para obtener información de los datos, que a menudo es el punto central de las bases de datos para empezar.
La razón más importante para quedarse con RDBMS es ACID
, o Atomicity, Consistency, Isolation, Durability . No repetiré el estado de Acid-NoSQL, ya que está bien abordado en esta publicación
en lo. Baste decir que hay una razón racional RDBMS de Oracle
tiene un mercado tan grande que no va a ninguna parte:algunos datos necesitan cumplimiento ACID puro . Si sus datos lo hacen (y si lo hacen, probablemente esté al tanto de ese hecho), entonces también lo hará su base de datos. Mantenga ese pH
bajo!
Editar: Consulte la publicación de Aaronaught aquí . Él representa la perspectiva de negocio a negocio mucho mejor que yo, en parte porque he pasado toda mi carrera en el espacio del consumidor.
