2010-07-25 9 views
5

Estoy tratando de diseñar un modelo de datos que puede almacenar una gran cantidad de datos, ¿alguien con experiencia en grandes volúmenes de datos tiene algún comentario sobre esto, es decir:transacciones a través de muy gran grupo de entidades

// example only, not meant to compile 
public class TransactionAccount { 
    private long balance; 
    private List<Transaction> transactions = new ArrayList<Transaction>(); 
    .... 
    public long getBalance() { return balance; } 
} 
private class Transaction { 
    public Date date; 
    public long amount; 
} 

Según lo que he leído, la única forma de obtener integridad transaccional al insertar Transaction y actualizar balance es convertirlo en un grupo de entidades.

Sin embargo, con el tiempo habría millones de transacciones para un determinado TransactionAccount. El número de escrituras en este grupo de entidades sería bajo, pero las lecturas serían mucho más altas.

Sé que podría estar fragmentado, sin embargo, leer el balance es una operación muy frecuente, y la fragmentación haría una de las operaciones más comunes getBalance() la operación más lenta.

+0

Hay una [pregunta de seguimiento] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-of-children-in-an-entity-group) discutiendo [cómo gestionar] (http://stackoverflow.com/questions/3342603/how-do-you-propery-add-manipulate-thousands-of-children-in-an-entity-group) un grupo de entidades con decenas de miles de objetos de niños. – Jacob

Respuesta

3

La disposición que describe debe funcionar bien. Si su grupo de entidades crece excesivamente grande (estamos hablando de cientos de megabytes de transacciones antes de que esto se convierta en un problema), podría escribir un procedimiento para 'enrollar' transacciones antiguas: reemplazar de forma transaccional un conjunto de registros de transacciones antiguos por uno único para la suma de esas transacciones, para mantener la invariante de que el saldo es igual a la suma de todas las transacciones. Si aún necesita almacenar un registro de estas antiguas transacciones 'acumuladas', puede hacer una copia de ellas en un grupo de entidades separado antes de realizar el roll-up.

+1

Esta es una excelente idea; podría, por ejemplo, tener una tarea "cron" que verifique las entidades con más de X registros y luego simplemente mueva, las transacciones X más antiguas a otro grupo de entidades. – corydoras

+0

Simplemente curioso, ¿dónde consigues la cifra "cientos de megabytes" como una guía? ¿No sería demasiado tener un objeto "Transaction" cargado en la memoria que contiene 100Mb de datos? – corydoras

+1

Por cientos de megabytes, me refiero al tamaño del grupo de entidades como un todo, la cuenta y todas sus transacciones, no el tamaño de una sola entidad. Obtengo la guía de cientos de megabytes desde mi propia experiencia como administrador de Bigtable. :) –

2

Tiene razón en que Transaction y TransactionAccount deben estar en el mismo grupo de entidades para realizar la operación de inserción y actualización transaccional.

La razón para Shard es reducir la contención de escritura, pero usted dice que será una entidad de baja escritura, por lo que no es necesario fragmentar.

Para mantener el tamaño de sus grupos de entidades, puede instalar algún tipo de proceso de archivo. Por ejemplo, si esto es para una cuenta bancaria, cuando se genera el resumen mensual, puede archivar las transacciones de ese mes.

+1

Esto está cerca, sin embargo, un límite de un mes puede no ser la mejor manera de hacerlo ... ya que en períodos pico pueden ocurrir muchas cosas en un mes. – corydoras

Cuestiones relacionadas