[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Es mejor un archivo grande o muchos pequeños



----- Original Message ----- From: "Edwin De La Cruz" <edwinspire@gmail.com>
To: <debian-user-spanish@lists.debian.org>
Cc: "Lista Debian" <debian-user-spanish@lists.debian.org>
Sent: Thursday, December 18, 2014 10:39 AM
Subject: Re: [OT] Es mejor un archivo grande o muchos pequeños


El día 17 de diciembre de 2014, 10:37, Camaleón <noelamac@gmail.com> escribió:
El Tue, 16 Dec 2014 12:52:01 -0500, Edwin De La Cruz escribió:

Saludos cordiales.
Antes que nada me disculpo por el OT, pero es que no se donde o como
buscar.

Y por el html... :-P

El asunto es el siguiente:
Estoy haciendo una aplicación que a su vez tiene varios hilos corriendo
a la vez, estos hilos generan cierta informacion que necesito almacenar.
He probado con SQLite, pero tengo problemas ya que algunas (muchas)
veces cuando uno de los hilos de la aplicación necesita insertar
información en la base de datos falla ya que se encuentra bloqueada por
otro hilo.

He subido el timeout pero solo ha mejorado un poco. Tambien tengo algo
de temor ya que he leido que la base de datos podria corromporse si en
un momento dos procesos escriben a la vez en la base de datos.

Actualmente para este fin uso PostgreSQL, sin ningun problema, pero o
que necesito es hacer la aplicacion mas independiente y facil de
instalar,
configurar, etc.

(...)

Es decir, buscas un sistema de bdd autónomo que permita concurrencia en
operaciones de escritura (funcionalidad que sólo suelen incluir las bdd
de esquema cliente/servidor como mysql, postgresql, etc...).

No sé si habrás mirado la biblioteca BerkeleyDB (BDB), quizá te sirva
para tu aplicación.

Estoy analizando esta opcion, aunque no soy muy partidario de Oracle.


He pensado en usar XML para cada registro que la aplicacion genera, de
este modo ya no hay peligro de corrupcion de datos, como podria suceder
en el caso de SQLite.

No creo que SQlite llegue a ese punto (pérdida de datos), entiendo que
debería devolver una respuesta de "ocupado" e impedir la escritura
notificando al proceso que lo haya solicitado de este punto con lo cual
podría programarse una función para reintentar de nuevo la escritura si
se da esta situación.

De hecho cuando la base esta bloqueada por otro proceso e intento
escribirla desde otro me da un error indicando que esta ocupada.
Por programacion vuelvo a intentar la escritura, pero como llegan
varios procesos al mismo tiempo suele demorar un poco en liberarse,
digamos unos 5 a 10 segundos esperando.


La Pregunta es la siguiente: es pesado (lento) para el procesador el
tener que leer o copiar cientos o miles de archivos individuales, lo
pregunto porque me ha pasado que cuando copio alguna carpeta que
contiene ciento de archivos, todos menores a 10K, el proceso es muy muy
lento.

Bueno, una bdd siempre resulta más eficiente cuando se trata de una
cantidad considerable de información que se tiene que manipular en
espacios de tiempo cortos y además evitas depender de las características
del sistema donde se vaya a ejecutar.


Pues con PostgreSQL estoy muy contento, es mas, el 70% del codigo de
la aplicacion está en la base de datos.
Mi busqueda de alguna alternativa como SQLite es que a mis usuarios
les resulta un poco dificil, bajarse postgresql, instalarlo,
configurarlo, etc., tanto en Windows como en Linux.

No has mirador Firebird? También requiere de instalación, pero es Mil veces más sencillo de instalar y no requiere practicamente mantenimiento, además de ser muy rápido y seguro.

Puedes hecharle una mirada en firebirdsql.org también está en el repositorio de debian

Busco que la aplicacion funcione tan solo con copiarla en una carpeta
y correr el ejecutable.
La aplicacion inicialmente usaba Apache, ya que la interface grafica
es web, para evitarme la instalacion y configuracion de apacha, he
desarrollado un micro servidor web embebido que hace justo lo que
necesito sin tener que instalar ni configurar algo adicional, busco
hacer lo mismo con la base de datos.

Saludos,

--
Camaleón

Gracias e igualmente muchos saludos.



Has in

Saludos
========
| ISMAEL |
========



Reply to: