MAME: Aquellos maravillosos años (Windows)

¿Quién no se acuerda de la época en que íbamos a los bares a gastarnos la paga en las maquinitas?. ¿No te gustaría recordar aquellos tiempos sin gastar nada más que tu tiempo y unas dosis de adrenalina?

Podemos revivir aquellos maravillosos años gracias a emuladores que nostálgicos como nosotros han creado para traer esas máquinas a nuestro PC. En este primer post abordaremos cómo hacerlo en Windows. Prometo otro post para hacerlo en Linux.

Estos emuladores se denominan MAME (Multiple Arcade Machine Emulator ó Emulador de Múltiples Máquinas Arcade). Engloban la mayor parte de máquinas de juegos que había en su época: Taito, Konami, Sega...

Estos emuladores son gratuitos, y puedes descargarte también miles de juegos que correrán sin problemas en estos emuladores.

Para empezar bajaremos el emulador más conocido y utilizado de todos en la siguiente URL: http://mamedev.org/release.html. Elegiremos, en la sección "Official Windows Binary Packages", la última release (a lo hora de escribir este post era la 0.135b). El archivo es un archivo comprimido ejecutable, el cual, al lanzarlo, nos solicitará en qué directorio descomprimir los archivos. Ojo, indicar una ruta de un directorio dedicado, o si no mezclará los archivos que descomprima con el directorio que se le haya indicado.

El emulador viene sin juegos, es decir, que sólo tendremos las "máquinas" en nuestro ordenador sin ninguna ROM. Las ROM's las puedes encontrar en cientos de páginas en Internet, pero, sin lugar a dudas, la más conocida y completa es la siguiente: http://www.romnation.net/, donde podrás encontrar también emuladores y juegos para otros dispositivos, tales como consolas y ordenadores antiguos.

Las ROM's están ordenadas alfabéticamente, y deberás descargarlas en el directorio "rom". Cuando ejecutes el archivo "mame.exe" detectará qué roms hay en este directorio, y a través de su interfaz tan sólo hay que elegir el juego para empezar a jugar.

Las teclas principales son:
5 - Echar moneda
1 - 1 Jugador
2 - 2 Jugadores
Ctrl - Disparo 1
Espacio - Disparo 2
Esc - Salir
Alt + Enter - Pantalla completa / ventana

El emulador contiene muchas opciones y la posibilidad de configurar también muchas cosas. Lo malo es que tiene una interfaz un poco sosa, y cuando tengas muchos juegos, a lo mejor te puede liar.

Existen varias interfaces que facilitan poder acceder a los juegos, amén de otras opciones, como ver el aspecto del juego (pantalla) antes de seleccionarlo, filtrar por tipo de juego, los que están disponibles, etc. El más conocido y utilizado es MAMEUI32, y podrás encontrarlo en la siguiente URL: http://www.mameui.info/


Esta interfaz incluye por debajo el emulador de MAME. Así pues, los ROM's se almacenan en el directorio "rom", y las teclas de uso son las mismas. Tan sólo es necesario configurar el directorio donde se almacenan las ROM's, mediante el menú "Options" y la opción "Directories..."

Bueno, espero que paséis felices ratos con estos programillas.

Contendientes en bases de datos no relacionales

Tercer y último artículo sobre bases de datos no relacionales, basados en el original de Tony Bain. Al final del artículo me he permitido la licencia de actualizar algunos datos y de añadir otras alternativas (el resto está íntegro).
Artículo 1: ¿Están condenadas las bases de datos relacionales? (http://rafinguer.blogspot.com/2009/12/estan-condenadas-las-bases-de-datos.html)
Artículo 2: La nueva generación (de bases de datos) (http://rafinguer.blogspot.com/2009/12/la-nueva-generacion.html)
Fuente: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php?p=3


CONTENDIENTES EN SERVICIOS DE NUBE

Ya hay un número de vendedores de servicios web que ofrecen en la actualidad bases de datos clave/valor multi-inquilino bajo conceptos de "paga según utilizas". La mayor parte de ellos conocen los criterios discutidos en estos artículos, pero cada uno ofrece características únicas y variaciones respecto a los estándares generales aquí descritos. Echemos un vistazo a bases de datos particulares, tales como SimpleDB, Google AppEngine Datastore y SQL Data Services.


Amazon: SimpleDB
SimpleDB es una base de datos clave/valor orientada a atributos disponible en la plataforma de Amazon Web Services. SimpleDB es todavía una Beta pública. Mientras tanto, los usuarios pueden registrarse para una versión "gratuita" - limitada por uso.

SimpleDB tiene algunas limitaciones. La primera es que una consulta no puede durar más de 5 segundos. La segunda, que no hay más tipos de datos que cadenas de texto. Cada almacenamiento, recuperación o comparación se realiza en formato de cadena de texto (string), por lo que las comparaciones de fechas no funcionan a menos que se éstas se conviertan al formato ISO8601. La tercera, el tamañao máximo de cada cadena de texto es de 1024 caracteres, lo cual limita mucho los textos (como descripciones de productos, etc.) que puedes almacenar un atributo simple. Pero debido a que el esquema es dinámico y flexible, puedes superar esta limitación añadiendo atributos "DescripcionProducto1", "DescripcionProducto2", etc. El límite por cada elemento es de 256 atributos,. Mientras SimpleDB sea Beta, los dominios no pueden ser más grandes de 10GB, y las bases de datos enteras no pueden superar 1TB.

Una característica clave de SimpleDB es que utiliza un modelo de consistencia eventual. Este modelo de consistencia es bueno para la concurrencia, ya que después de haber cambiado un atributo en un elemento, los cambios no serán reflejados en las operaciones de lectura inmediatas a dicho cambio. Esto hay que tenerlo muy en cuenta en casos como, por ejemplo, cuando no quieras vender la última entrada de un concierto en el sistema de reserva para cinco personas debido a que los datos no fueron consistentes en tiempo de venta.


Google AppEngine Datastore
Google AppEngine Datastore está construído con BigTable, el sistema de almacenamiento interno de Google para la manipulación de datos estructurados. En sí mismo, Google AppEngine Datastore no es un mecanismo de acceso directo a BigTable, si no una especie de interfaz simplificada superpuesta a BigTable.

El AppEngine Store soporta muchos más tipos de datos y elementos que SimpleDB, inluyendo tipos de lista, que contiene colecciones dentro de un elemento simple.

Sin embargo, no podrás realizar interfaces con el AppEngine Datastore (o con BigTable) utilizando aplicaciones externas a la plataforma de servicios web de Google.


Microsoft SQL Data Services
SQL Data Services es parte de la plataforma Azure Web Services de Microsoft. El SDS es un servicio que está en versión Beta y es gratuito con algunas limitaciones en el tamaño de las bases de datos. SQL Data Services es en sí misma una aplicación situada en lo alto de muchos servidores SQL, los cuales crean el almacenamiento de datos por debajo de la plataforma SDS. Mientras que el almacenamiento por debajo pueda ser relacional, tú no tienes acceso a éste; SDS es un almacenamiento clave/valor, como otras plataformas discutidas anteriormente.

Microsoft parece estar sóla entre los tres tipos de vendedores en reconocimiento de que mientras el almacenamiento clave/valor es fenomenal para la escalabilidad, acarrea un gran gasto de gestión de datos cuando es comparado con RDBMS. La aproximación de Microsoft parece ser deshacer hasta los huestos pelados para obtener un buen mecanismo de escalación y distribución, y entonces transcurrido el tiempo fortalecerse, añadiendo características que ayuden a puentear los huecos entre el almacenamiento clave/valor y la plataforma de base de datos relacional.


CONTENDIENTES EN SERVICIOS QUE NO SON DE NUBE

Fuera de la nube existen vendedores de software de base de datos que pueden ser instalados "en casa". Casi todos estos productos son todavía jóvenes, todavía en versiones alpha o beta, pero en su mayoría son software libre (open source); pudiendo tener acceso al código, tú puedas quizás ser más consciente de cuestiones potenciales y de las limitaciones que tú podrías tener con vendedores de soluciones cerradas.


CouchDB
CouchDB es una base de datos orientada a documentos, open source y gratuita. Derivada del almacenamiento clave/valor, utiliza JSON para definir el esquema de un elemento. CouchDB está concebida para tender un puente al hueco que existe entre bases de datos relacionales y bases de datos orientadas a documentos gracias a las "vistas", que pueden ser creadas dinámicamente a través de JavaScript. Estas vistas mapean los datos del documento en estructuras similares a tablas que pueden ser indexadas y consultadas.



Proyecto Voldemort
El proyecto Voldemort es una base de datos clave/valor distribuida que tiene previsto escalar horizontalmente a través de un gran número de servidores. Está engendrado a partir del trabajo realizado en LinkedIn y, según se informa, utilizado allí donde muchos sistemas tengan requerimientos de escalabilidad muy altos. El Proyecto Voldemort también utiliza un modelo de consistencia eventual, basado en el de Amazon.


Mongo
Mongo es el sistema de base de datos desarrollada en 10gen por Geir Magnusson y Dwight Merriman (recordemos de DoubleClick). Como CouchDB, Mongo es una base de datos orientada a documentos JSON, salvo que está diseñada para ser una verdadera base de datos de objetos, más que para un almacenamiento de clave/valor puro. Originalmente, 10gen enfocó poner juntos una pila completa de servicios web, aunque sin embargo, más recientemente ha tenido que ser reenfocado principalmente en la base de datos Mongo.



Drizzle
Drizzle puede ser considerado como una contrarrestación-propuesta para los problemas que los almacenamientos clave/valor tienen que resolver. La vida de Drizzle comenzó como un resultado indirecto de la base de datos MySQL (6.0). En los últimos meses, sus desarrolladores han removido las características no centrales (no-core) de un host (incluyendo vistas, triggers, sentencias preparadas, procedimientos almacenados, caché de consultas, ACL, y varios tipos de datos), con el objetivo de crear un sistema de base de datos más ligero, simple y rápido. Drizzle puede todavía almacenar datos relacionales. Como apuntó Brian Aker, de MySQL/Sun, "no hay razón de sacar al bebé del agua del baño". El objetivo es construir una plataforma de base de datos semi-relacional a medida para la web y para aplicaciones basadas en la nube ejecutándose en sistemas con 16 cores o más.



TOMAR UNA DECISION
Ultimamente, existen cuatro razones por las cuales deberías optar por una plataforma de base de datos no relacional clave/valor para tus aplicaciones:
1) Tus datos están fuertemente orientados a documentos, haciéndolos más acordes y naturales con el modelo de datos clave/valor que con el modelo de datos relacional.
2) Tu entorno de desarrollo está fuertemente orientado a objetos, y una base de datos clave/valor podría reducir la necesidad de código "tubería".
3) El almacenamiento de datos es económico y se integra fácilmente con la plataforma de servicios web de tu proveedor.
4) El asunto más importante es que es bajo demanda, con alta escalabilidad final -- esto es, gran escala, escalabilidad distribuida, del tipo que no puede ser conseguida simplemente mediante escalar añadiendo.

Para tomar una decisión hay que recordar las limitaciones de las bases de datos y los riesgos que corres por bifurcación con respecto del plan relacional.

Para el resto de requerimientos, tu mejor opción sea una buena y vieja RDBMS. Así pues, ¿están condenadas las bases de datos relacionales? Claramente, no. Al menos, no todavía.


REFLEXION ADICIONAL
Esta información ha sido incluida al final del artículo, y no forma parte del artículo original.

A lo largo de este y los dos anteriores posts, hemos echado un vistazo a esta filosofía de almacenamiento, sus virtudes, sus defectos y la comparativa con las RDBMS para podernos hacer una imagen más exacta de cuáles pueden ser nuestras mejores opciones a la hora de emprender un proyecto.

Ha surgido un movimiento denominado NOSQL, con carácter rebelde, criticando las RDBMS y ensalzando las virtudes de las nuevas alternativas (recomiendo mi anterior artículo: Movimiento NOSQL: la alternativa a las bases de datos relacionales. No caigamos en el error de la anarquía. Las RDBMS han estado tanto tiempo con nosotros porque funcionan y son necesarias. Recomiendo conocer ambas filosofías, sus pros, sus contras. Recomiendo probar y hacernos una idea más exacta de qué va a ser lo que necesitemos y de que va a ser lo mejor para nuestros proyectos.

Es cierto que algunas grandes compañías que generan su negocio en Internet, utilizan las bases de datos no relacionales, y que incluso ellas mismas han desarrollado su propio sistema, como Google, Microsoft, Amazon o Facebook. Hay que ver que su negocio es la red, y que su filosofía es la nube. Su negocio es inmenso y requieren de miles de servidores repartidos por todo el mundo. Hemos de comprobar si éste es nuestro escenario o si, por el contrario, nuestro escenario se reduce a un simple servidor al modo tradicional, o a unos pocos servidores en cluster localizados en el mismo edificio, para lo cual, otras alternativas RDBMS van a ser las más adecuadas, como Oracle, SQL Server, MySQL o PostgreSQL.

Quisiera terminar este artículo añadiendo otras bases de datos no relacionales, y que no se comentaron en el artículo final. Espero que os haya sido de interés y de utilidad.


Cassandra
Este sistema de base de datos fue desarrollado por Facebook, abandonando el prestigioso MySQL. Este sistema ya forma parte de la incubadora de proyectos de Apache. Cassandra es open source, altamente distribuido, y tiene un modelo de datos similar al de BigTable (Google). Entre sus características cabe destacar la alta disponibilidad, consistencia eventual, escalabilidad incremental, replicación optimista, administración mínima.Posee API para acceder desde lenguajes de programación tales como C++, C#, Java, Perl o PHP (entre otros).

En la actualidad aún está en desarrollo. Es utilizado por Facebook, Digg, Rackspace y otras compañías.

Enlace: http://incubator.apache.org/cassandra/

Recomiendo ver el vídeo y las slides para más información.


HyperTable

Hypertable es una plataforma de base de datos de alto rendimiento para accesos masivos en paralelo, de alta escalabilidad web.

Enlace: http://hypertable.org/

La nueva generación (de bases de datos)

Segunda parte de este interesante artículo sobre el presunto declive de las bases de datos relacionales.
Artículo anterior: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Fuente: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php?p=2


Este nuevo tipo de sistema de gestión de bases de datos es conocido comúnmente como almacenamiento por clave/valor. De hecho, no existe aún un nombre oficial, por lo que puedes obtener referencias tales como "orientado a documento", "orientado a Internet", "orientado a atributos", "base de datos distribuida" (aunque esto puede ser también una base de datos relacional), "colecciones de fragmentos ordenados", "tablas hash distribuidas" y "bases de datos clave/valor". Cada uno de estos nombres apuntan a un rasgo específico en esta nueva propuesta, todas son variaciones en un mismo tema, por lo cual las llamaremos bases de datos clave/valor.

Sea cual sea el nombre con que las llames, este "nuevo" tipo de base de datos ha sido ya usado durante mucho tiempo por aplicaciones especializadas para las cuales las bases de datos relacionales eran deficitariamente adecuadas. Pero sin la escala que las aplicaciones web y la nube han traído éstas habrían permanecido como un subconjunto en su mayor parte no utilizado. En la actualidad, el desafío es reconocer si una base de datos relacional es la mejor opción para una aplicación en particular.

Las bases de datos relacionales y las bases de datos clave/valor son fundamentalmente diferentes y diseñadas para cumplir diferentes necesidades. Una comparación cara a cara nos acerca el entendimiento de estas diferencias:

DEFINICION DE BASE DE DATOS
Base de datos relacional	Base de datos clave/valor
La base de datos contiene tablas, las tablas contienen columnas y filas, y las filas están compuestas de valores de columna. Todas las filas dentro de una tabla tienen el mismo esquema. El modelo de datos está bien definido por adelantado. Un esquema está fuertemente definido y tiene restricciones (constraints) y relaciones que fuerzan la integridad. El modelo de datos está basado en una representación "natural" de los datos que contiene, no en la funcionalidad de la aplicación. El modelo de datos está normalizado para eliminar la duplicación de datos. La normalización establece relaciones de tablas. Las relaciones asocian datos entre tablas.	Los dominios pueden ser inicialmente asociados como tablas, pero a diferencia de las tablas, no se define ningún esquema para un dominio. Un dominio es básicamente un cubo en donde se meten elementos en su interior. Los elementos dentro de un dominio simple pueden tener diferentes esquemas. Los elementos son identificados por claves, y un elemento dado puede tener adjunto un conjunto dinámico de atributos. En algunas implementaciones, todos los atributos son cadenas de texto (string). En otras implementaciones, los atributos tienen tiene tipos simples que reflejan tipos de código, tales como enteros (int), colecciones de cadena de texto y listas. Ninguna relación es definida explícitamente entre dominios ni en el interior de un dominio dado.

Sin entidades unidas
Las bases de datos clave/valor está orientadas a elementos, lo que significa que todos los datos relevantes relacionados con un elemento están almacenados dentro del elemento. Un dominio (en el cual puedes pensar como una tabla) puede contener vastamente elementos diferentes. Por ejemplo, un dominio puede contener elementos de clientes y elementos de pedidos. Esto significa que los datos están comúnmente duplicados entre los elementos de un dominio. Esto es una práctica aceptada debido a que el espacio de disco es relativamente barato. Pero este modelo permite que un elemento simple pueda contener todos los datos relevantes, lo cual mejora y aumenta la escalabilidad eliminando la necesidad de unir (join) datos desde múltiples tablas. Con una base de datos relacional tales datos necesitan ser unidos para ser capaz de reagrupar los atributos relevantes.

Pero mientras la necesidad de las relaciones es reducida enormemente con bases de datos clave/valor, algunas de éstas son certeramente inevitables. Estas relaciones existen normalmente entre entidades centrales o comunes. Por ejemplo, un sistema de pedidos debería tener elementos que contengan datos sobre clientes, productos y pedidos. Tanto si éstos residen en el mismo dominio o en dominios diferentes es irrelevante, pero cuando un cliente realiza un pedido, probablemente no querrías almacenar tanto los atributos de cliente como de producto en el mismo elemento del pedido.

En lugar de ello, los pedidos necesitarían contener las claves relevantes que apunten al cliente y al producto. Mientras que esto es perfectamente factible en una base de datos clave/valor, estas relaciones no están definidas dentro del propio modelo de datos, así que el sistema de gestión de base de datos no puede forzar la integridad de las relaciones. Esto significa que puedes eliminar clientes y productos que han sido utilizados en pedidos. La responsabilidad de asegurar la integridad de datos cae enteramente en la aplicación.

ACCESO A DATOS
Base de datos relacional	Base de datos clave/valor
Los datos son creados, actualizados, borrados y recuperados usando SQL. Las consultas SQL pueden acceder a datos desde una tabla simple o desde múltiples tablas usando uniones de tablas. Las consultas SQL incluyen funciones para agregar y filtros complejos. Normalmente contiene medios de lógica embebida cerrada para almacenamiento de datos, tales como triggers, procedimientos almacenados y funciones.	Los datos son creados, actualizados, borrados y recuperados usando llamadas a métodos de una API. Algunas implementaciones proveen sintaxis básica similar a SQL para definir criterios de filtro. A menudo pueden aplicarse predicados básicos de filtro (tales como =, !=, <, >, >= y <=). Toda la lógica de aplicación y de integridad lógica de datos está contenida en el código de la aplicación.

INTERFAZ DE APLICACION
Base de datos relacional	Base de datos clave/valor
Tiende a tener su propia API específica, o hace uso de una API genérica, tal como OLE-DB o ODBC. Los datos son almacenados en un formato que representa su estructura natural, así que debe estar mapeada entre la estructura de código de la aplicación y la estructura relacional.	Tienden a proveer SOAP y/o REST APIs sobre los cuales pueden ser realizadas las llamadas de acceso a datos. Los datos pueden estar más eficientemente almacenados en código de aplicación que es compatible con su estructura, requiriendo solamente código relacional a modo de "tubería" para el objeto.

Almacenamiento clave/valor: lo bueno
Hay dos claras ventajas de las bases de datos clave/valor con respecto a las bases de datos relacionales.

Idoneidad para nubes
El primer beneficio es que son simples y de este modo para escalar son mucho mejores que las bases de datos relacionales actuales. Si estás juntando un sistema en casa y tienes la intención de lanzar docenas o centenares de servidores detrás para el almacenamiento abasto de tus datos esperando una demanda masiva en escala, entonces considera un almacenamiento clave/valor.

Debido a que las bases de datos clave/valor escalan fácil y dinámicamente, son también las bases de datos que los vendedores eligen para proveer sistemas multi-usuario y plataforma de almacenamiento de datos para servicios web. La base de datos provee una plataforma de almacenamiento de datos relativamente económica con un potencial masivo para escalar. Los usuarios típicamente pagan sólo por aquello que usan, pero su uso puede incrementarse y también sus necesidades. Mientras tanto, el vendedor puede escalar la plataforma dinámicamente basado en el total de la carga del usuario, con pequeñas limitaciones en el tamaño completo de la plataforma.


Más ajuste natural en código
Los modelos de datos relacionales y los Modelos de Objetos de Código de Aplicación se construyen normalmente de forma diferente, lo que lleva a incompatibilidades. Los desarrolladores sobrellevan estas incompatibilidades con código que mapea los modelos relacionales con sus modelos de objeto, un proceso comúnmente referido como "mapeo de objeto a relacional". Este proceso, el cual acumula esencialmente código a modo de "tubería" y que no tiene un claro e inmediato valor, puede tomar un trozo importante del tiempo y del esfuerzo dedicado al desarrollo de la aplicación. Por otro lado, muchas bases de datos clave/valor retienen datos en una estructura que mapea más directamente los objetos de clase usados en el código de la aplicación, lo cual reduce significativamente el tiempo de desarrollo.


Almacenamiento clave/valor: lo malo
Las restricciones inherentes de una base de datos relacional asegura que los datos en el nivel más bajo tengan integridad. Los datos que violan las restricciones de integridad no pueden ser introducidas en la base de datos de forma física. Estas restricciones no existen en una base de datos clave/valor, así que la responsabilidad de asegurar la integridad de los datos cae enteramente en la aplicación. Pero el código de aplicación a menudo acarrea errores. Una base de datos relacional correctamente diseñada no lleva a errores en cuestión de integridad de datos; una base de datos clave/valor, sin embargo, lleva fácilmente a errores en cuestión de integridad de datos.

Otro beneficio clave de una base de datos relacional es que te fuerza a seguir un proceso de modelado de datos. Si está bien hecho, este proceso de modelado crea en la base de datos una estructura lógica que refleja los datos que contiene, en lugar de reflejar la estructura de la aplicación. Entonces los datos se hacen independientes de la aplicación, lo que significa que otras aplicaciones pueden usar los mismos datos y la lógica de la aplicación puede ser cambiada sin perturbar el modelo de datos que hay por debajo. Para facilitar este proceso con una base de datos clave/valor, intenta reemplazar un ejercicio de modelado de datos relacional con un ejercicio de modelado de clase, el cual genere clases genéricas basadas en la estructura natural de los datos.

Y no olvidemos la compatibilidad. A diferencia de las bases de datos relacionales, las bases de datos orientadas a nube tienen poco de estándares compartidos. Mientras que todas ellas comparten conceptos similares, cada una tiene su propia API, interfaces de consulta específicas, y peculiaridades. De esta manera, necesitarás confiar realmente en tu vendedor, porque no serás simplemente capaz de cambiar la línea si no estás satisfecho con el servicio. Y debido a que casi todas las bases de datos clave/valor aún están desarrollándose la confianza es más arriesgada que con una base de datos relacional de la vieja escuela.


Limitaciones en analíticas
En la nube, las bases de datos clave/valor son normalmente multi-inquilino, lo cual significa que muchos usuarios y aplicaciones usarán el mismo sistema. Para prevenir cualquier proceso de sobrecarga del entorno compartido, la mayor parte de los almacenes de datos en nube limitan estrictamente el impacto total que cualquier consulta simple pueda causar. Por ejemplo, con SimpleDB tú no puedes ejecutar una consulta que tome más de 5 segundos. Con Google's AppEngine DataStore, no puedes recuperar más de mil elementos por cada consulta.

Estas limitaciones no son un problema para la lógica de tu aplicación (añadir, actualizar, eliminar y recuperar un número pequeño de elementos). Pero, ¿qué ocurre cuando tu aplicación se convierte en exitosa? Has atraído a muchos usuarios y has pedido muchos datos y ahora quieres crear nuevos valores para tus usuarios o quizá usar los datos para generar nuevos ingresos. Puedes encontrarte a tí mismo limitado en ejecutar consultas sencillas de estilo analítico. Con este tipo de plataforma de base de datos, cosas como rastreo de patrones de uso y recomendaciones de provisión basadas en historias de usuario difíciles en el mejor de los casos, imposibles en el peor.

En este caso, es probable que tengas que implementar una base de datos analítica por separado, en la cual las analíticas puedan ser ejecutadas. ¿Pensar por adelantado de dónde y cómo deberías ser capaz de hacer ésto? ¿Deberías hospedarla en la nube o invertir en una infraestructura on-site? ¿Podría la latencia entre tú y el proveedor del servicio en nube plantear un problema? ¿Tu base de datos clave/valor basada en nube soportar ésto? Si tienes 100 millones de elementos en tu base de datos clave/valor, pero sólo puedes sacar 1000 elementos a un tiempo, ¿cuantas consultas se deberían realizar?

En última instancia, mientras escalar es una consideración, no antepongas tu habilidad de convertir los datos en un activo propio. Todas las escalas en el mundo son inútiles si tus usuarios se han ido a tu competidor porque tiene frescura y tiene más características personalizadas.