¿Sería incorrecto usar un objeto estático en lugar de una base de datos?

Question

Esto es esencialmente una pregunta de patrones de diseño:

Estaba esperando consultar una base de datos para obtener una lista de acciones (acciones/seguridades) que están más altamente correlacionadas para un stock determinado.

En su lugar, pensé que tal vez debería crear un objeto que tiene un HashMap estático y almacenar mis datos allí. Luego, "consultarlo" cada vez que lo necesite.

¿Habría algo de malo con este enfoque, ya que creo que mejoraría el rendimiento significativamente sobre la consulta de una base de datos para los mismos datos. La cantidad de datos es relativamente pequeña y no crece, por lo que no causará problemas. ¿Podría haber algún problema que me morderá más tarde?

Answer 1

Todavía utilizaría la base de datos por razones de respaldo, pero en el cliente use una aplicación de almacenamiento en caché como oscache para almacenar los datos en el sistema de archivos local para un acceso rápido; luego, si el sistema deja de restaurar la caché de la base de datos y continuar utilizando el caché en su código

Answer 2

No hay nada de malo en este enfoque en general. Solo asegúrate de no acceder directamente a tu clase estática, porque luego creas un "bad singleton". (Como una variable global)

En su lugar introduzca algún tipo de mecanismo de registro para registrar esta clase en todos los objetos que la consultarán. Entonces tendrás un "buen singleton" y no habrá problemas posteriores.

public class MyDataClass { 
    private MyDataClass() { } 
    public static MyDataClass getInstance() { 
     if (instance == null) instance = new MyDataClass(); 
     return instance; 
    } 
    private static MyDataClass instance = null; 
} 

public class MyDataProcessor { 
    public void registerData(MyDataClass data) { 
     this.data = data; 
    } 
    public void process() { 
     assert(data != null); 
     data.getData(...); 
    } 
    private MyDataClass data; 
} 

Por supuesto, este enfoque podría tener algunos problemas después de todo en una capa de arquitectura cuando se trata de la persistencia, robustez, ... Tal vez sería mejor usar una base de datos con una capa de almacenamiento en caché, pero eso depende altamente en las necesidades reales de los usuarios.

Answer 3

El problema con su enfoque es no tener una separación entre el código y los datos.

que da lugar a algunas desventajas:

• no se pueden hacer copias de seguridad
• usted tiene que volver a compilar/volver a implementar la aplicación para cambiar los datos

medida que no parece necesitar una base de datos relacional para eso, le sugiero que use una base de datos de valores-clave incrustada como BerkeleyDB, que también es muy rápida.

Answer 4

Los problemas que obtendrás son si los datos cambian y necesitas actualizar el hash y volver a compilar todo el tiempo.

Habiendo dicho eso, usted conoce los datos, puede decir cuánto le afectarán.

Una opción podría ser mantener los datos en una base de datos, pero luego guardarlos en la memoria caché en un HashMap.

Answer 5

Normalmente, lo que vuelve y pica es la suposición de que algo nunca cambiará. Por lo tanto, si posteriormente obtiene requisitos que implican actualizar los valores, agregar nuevos y tener múltiples clientes accediendo a los datos si ya está utilizando una base de datos, tendrá menos trabajo. En lugar de hacer algo de almacenamiento en caché en el lado del cliente para obtener el impulso de rendimiento. Solo mi 2c.

Answer 6

Almacene los datos en un HashMap si es más fácil.

A continuación, puede serializar una copia de esta utilizando XStream. Esto creará una versión XML del objeto HashMap.

Para que su aplicación pueda escribir esto en el disco según sea necesario, puede editarlo a mano y volver a cargarlo en la aplicación. Esto significa que tiene su HashMap y una representación configurable en el disco que puede cambiar según sea necesario.

Answer 7

El almacenamiento en caché estático puede funcionar.

Tenga en cuenta que si tiene varias aplicaciones que acceden a la misma base de datos que va a necesitar algún tipo de bus de mensajería y una distributed cache

Answer 8

Si una memoria caché de sólo lectura que no se actualiza automáticamente es todo lo que necesita para su aplicación, entonces no hay nada de malo en este enfoque.

Sin embargo, hay una advertencia: si la cantidad de datos (incluida la sobrecarga de los objetos Java y el HashMap) se vuelve demasiado grande para mantenerse en RAM, el rendimiento disminuirá rápida y drásticamente (en un factor de 10.000 o más) Los sistemas de bases de datos están diseñados para un acceso eficiente a los datos en disco; un HashMap no lo es

Answer 9

¿Debería utilizar un caché? Sí, si es mucho más rápido y si nunca desea actualizar los datos, o si no es importante si los datos almacenados en caché no están actualizados con los datos reales.

Debe poner este acceso detrás de una API y ocultar el almacenamiento en caché detrás de la abstracción. Luego puede jugar con diferentes estrategias de almacenamiento en caché, o descartar la idea de almacenar en caché por completo sin tener que volver a escribir el resto de su código cada vez.

Answer 10

Su idea no es tan mala, sin embargo yo personalmente buscaría una solución de almacenamiento en caché.

Ignore a las personas que dicen que necesitaría recompilar/redistribuir cada vez que los datos cambian, ya que no creo que entiendan lo que quiere decir estático. es decir, creen que va a haber codificado los valores en su fuente.

Answer 11

De nuevo, dependiendo de lo que haga, esto podría estar bien. Siempre que tenga algún método para conservar lo que está en HashMap o similar en caso de mantenimiento/apagado del servidor.

Todo lo que necesita es un método de serialización. Vi que XStream fue mencionado anteriormente.

También hay una biblioteca llamada Prevayler. Esto serializa los cambios sobre la marcha, pero le permite mantener todo en la memoria. Por lo tanto, incluso en caso de una falla repentina del suministro eléctrico en la que no tiene tiempo para apagarlo correctamente, esto puede ser de alguna utilidad.

Experimenta con diferentes métodos para ver lo que funciona para ti y extrae los detalles detrás de un DAO.