DEBIAN PRO

DEBIAN PRO
DEBIAN

sábado, 24 de noviembre de 2012

Escalamiento en rdbms

Casi siempre, aunque hay excepciones, el escalamiento en productos rdbms es vertical. Para simplificar el concepto, eso quiere decir mas cpu, mas ram, mas velocidad en el almacenamiento, mas discos, mas placas de red para dividir las comunicaciones.....

Dije CASI siempre, por hay algunas alternativas un poco horizontales (diagonales ?) dividiendo las tareas de un motor en varios, eso trae otras complicaciones pero es posible, sea dividiendo las lecturas, con replicas, tablas estaticas.... hay varias opciones.

En estos dias estoy evaluando un sistema de particionado horizontal (varios servidores y bases) pero donde la segmentacion se da por el tipo de tabla y el area al que pertenece....

Ej: en una base metemos las tablas relacionadas con clientes, en otra base de datos las tablas de proveedores, en otra las tablas de usuarios, en otra las tablas de facturas y recibos, en otra las tablas de personal de la empresa......
todas bases distintas y servidores distintos.

En este modelo no habria casi FK, porque habria tablas sin relaciones en motores distintos, no habria transacciones internal rdbms porque son bases distintas, quedaria ver como implementar transacciones distribuidas desde el APP.

El sistema de backups no lo tengo claro, porque las bases se copiarian en momentos distintos...

Hoy me parece absurdo, casi como particionar las tablas en diferentes motores por sexo: LAS facturas en motor M y LOS recibos y los clientes en motor H, lAS traducciones en M, los usuarios en H.

Podria particionar las tablas por cantidad de columnas, de menos de 5, entre 6 y 10 en otro motor y para 11 o mas campos en otra base de datos.....

Tambien podria existir una segmentacion de tablas de pocos registros, tablas con miles en otro motor y tablas con MILLONES en otro motor....

O por colores?

O por la cantidad de silabas del objeto? Fac.tu.ras 3.  Tra.duc.cio.nes 4.  Pa.is 2...


Que les parece?
Mientras sigo pensando si tecnicamente tiene sentido particionar tablas por area de influencia de datos.
Puede que hagan falta replicas de algunas tablas que son necesarias en todas las bases de datos.....


Sigo pensando posibles problemas de un escalamiento horizontal "curioso".....

Les recuerdo que esto no tiene que ver con mongodb...

Que opinan?


No hay comentarios:

Publicar un comentario