 Autor
|
Tema: Ideas para diseño de bases de datos flat-file (Leído 8,286 veces)
|
pangea
 Desconectado
Mensajes: 19
|
Hola, como ya comenté en otro hilo, estoy recopilando información, consejos e ideas para conseguir resucitar hardware obsoleto de ese que con tanta facilidad se encuentra al lado de contenedores y usarlo como servidor web. Sin embargo, en el fin de conseguir que todo sea lo más ligero posible no solo interviene el software de servidor sino también la manera en la que están diseñados los sitios hospedados.
Así que de paso voy a diseñar algún que otro CMS muy ligero y muy sencillo pensado específicamente para estar hospedado en estos servidores.
En lo que a almacenamiento de datos se refiere, pienso que en muchas ocasiones puede resultar interesante usar "bases de datos" en archivos planos (flat-file) (en casos en los que la base de datos tenga más uso ya será mejor ir a por sqlite).
El objetivo final es la eficiencia, y una pésima gestión del modelo de datos me la echaría al traste. Me gustaría saber si alguien me podría dar consejos para diseñar todo lo que sería el convenio que podría seguir para almacenar datos en archivos, si me recomendáis que use XML, y sino, como parseo los datos de la forma más ligera posible. Truquillos, ideas y consejos para hacerlo todo más eficiente vamos.
Un saludo y muchas gracias.
|
|
|
|
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
Solo mi humilde opinion que puede ser muy limitada  Siempre he considerado a SQLite como una DB perfecta para aplicaciones de escritorio mas que nada, por el hecho de ser tan portable su API sin necesidad de ir instalando librerias y clientes en otros PC's para ejecutar tu aplicacion. Ahora, hablas de guardar la info de la base de datos en ficheros... pero en la vida real, la mayoria sino es que todas las bases de datos relacionales guardan su info en ficheros fisicos  lo que ocurre es que en el caso de SQLite te guarda todo en 1 solo ficherito, sin embargo otras base de datos mas profesionales te subdividen los archivos en indices, data, etc.. para tener un mejor manejo de los mismos a la hora de realizar una consulta. (Por ejemplo MySQL tiene la facilidad de buscar datos guiandose nada mas del fichero de indices). Sin embargo SQLite como guarda todo en 1 solo fichero fisico (todo es data y indices) puede resultar la situacion que lea mas informacion para llegar al objetivo final porque el ficherito tiene mas info (Aunque esto mismo aplica para MySQL con sus archivos de InnoDB) Tienes que pensar en grande, cual es el objetivo de tu proyecto??? crecera??? se quedara estancando??? Ten pendiente que otra bases de datos te facilitan muchas cosas que a lo mejor SQLite no, como es la distribucion de carga en memoria distribuida en distintos servidores, la posibilidad de tener un maestro y un esclavo, entre otras cosas. Tu lo que debes es perfilarte... mi proyecto crecera???? porque ten en cuenta que si un dia crece y tienes que movilizarte a un hosting decente en linea, no todos los hostings facilitan ni proveen SQLite y al menos que busques uno dedicado y puedes aduenarte entrar he instalar SQLite para que tu proyecto funcione. Radicara mucho en el proposito final de tu proyecto, SQLite es bueno muy bueno para proyectos de no muy amplia escala, pero para proyectos de escala amplias o en crecimiento, si deberias considerar una base de datos mas amplia y con mas funcionalidades... Aunque es solo mi opinion  Un saludito.
|
|
|
|
|
En línea
|
|
|
|
Nakp
casi es
Ex-Staff
Desconectado
Mensajes: 6.336
he vuelto :)
|
seeeh yo tambien soy fan de sqlite xD aun el driver de java es bastante rapido (es el que mas uso, pero de las implementaciones mas lentas) |
|
|
|
|
En línea
|
Ojo por ojo, y el mundo acabará ciego.
|
|
|
pangea
Desconectado
Mensajes: 19
|
La idea es usar hardware obsoleto como servidores web, así que el cuello de botella se encuentra en la potencia de ese hardware. Por lo tanto lo que quiero no es decidir de que manera almaceno los datos en función de como van a crecer los proyectos sinó crear CMS's muy ligeros que se adapten a la poca potencia del hardware para que los proyectos sean los que se adapten. No se si me estoy explicando, jeje. Entonces lo que busco es la manera de diseñar una manera de almacenar datos lo más ligera posible siempre teniendo en cuenta que limitaciones tiene eso (gestión de colisiones, poca escalabilidad, etc). Tal vez me he precipitado mucho al decir que la mejor opción era una flat-file database (concepto que excluye a SQLite, porque me refería a esto). La cosa es que normalmente el hardware nunca es un problema. Si algo es poco eficiente se compra hardware mejor y listos. Se priorizan otras cosas. Por eso no se suele tener en cuenta que MySQL y otras maneras de almacenar datos son bastante pesadas para según que hardware antiguo, y a veces realmente innecesarias. SQLite funciona muy bien en proyectos medianos, y fuera del mundo empresarial casi todos los proyectos son a lo sumo medianos! La pregunta entonces sería: Hasta que punto SQLite es ligero? Es casi tan ligero como usar un triste archivo xml? Porque claro, si es tan ligero tal vez no vale la pena que me complique la vida con las limitadas flat-file database. |
|
|
|
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
Vamos a ver... SQLite es mas un manejador de archivos para mi que una base de datos. Es ligero por el hecho de ser una libreria que llamas, utilizas, creas un archivo binario y ya... por ende un comando no te consume memoria al menos que lo llames cierto?  en cambio otro motor mas profesional como MySQL consume unos KB en memoria puesto que hay un servicio ejecutandose en tu sistema. Ahora bien, en cuanto a consumo quien ocupa menos? obviamente SQLite por lo que te acabo de exponer. Pero.. te intento persuadir otra vez, va a crecer tu proyecto??? Te lo intento repetir porque tienes que considerar varios puntos (No solo cuanto consume o no una aplicacion). Mysql es un servidor robusto, y en parte bastante ligero en consumo de memoria en comparacion con otros motores relacionales populares de gran uso como es Oracle o SQL Server, MySQL puede tener centenas de conexiones al mismo tiempo y es capaz de hacer modificaciones casi simultaneas en fracion de milisegundos. Para usarlo tienes que conectarte a este por tcp/ip. Puedes manejar bases de datos de un extenso tamano que rondan por los terabytes inclusive.... MySQL fue optimizado para eso y es por eso que es tan ampliamente usado en proyectos webs. De hecho las modificaciones realizadas en las tablas de Mysql no llegan a tocar el disco duro sino hasta despues de unos segundos... se quedan en memoria hasta que vea que ya no son necesarios. Ademas, al tener las tablas en distintos archivos puede manejar modificaciones simultaneas sin preocuparse por corromper los datos, tambien te permite distribuir la carga de consultas y esas cosas en distintos servidores.. Sin embargo todo lo anterior no es tan posible en el amigo SQLite. SQLite no deja de ser un manejador de archivos, y el proposito principal de todo proyecto que trabaje con base de datos son las modificaciones de registros simultaneas (Ya que hablas de CMS vas a querer que mas de 1 usuario a la vez este conectado a tu proyecto). Cuando intentan realizar modificaciones simultaneas en SQLite, el primer proceso bloqueara la base de datos, evitando cualquier otra modificacion, y se la libera al siguiente proceso solo hasta al terminar. Ademas, el archivo entero solo puede llegar a medir 2 Gigabytes (o asi era cuando maneje este motor, pero estaras mas informado en su website principal), y si intentas acceder desde otra aplicacion en internet, tendras que dar uso de webservices, o tendras que descargarla completa... Por ende piensa mucho cual es tu proposito final con tu proyecto, no solamente es que me economiza unos ligeros KB en memoria, sino que sera tu proyecto y con que funcionalidad. SQLite esta extremadamente bueno para aplicaciones de escritorio, que necesiten acceso a data local o similar, no para proyectos asi donde habran varios usuarios trabajando algo sobretodo web (que repito no todos los hostings en un caso futuro desees migrar, soportan SQLite). Recuerda que en SQLite se crea 1 archivo binario que guarda todo, indices, datas, vistas, todo... y para acceder a ese archivito nisiquiera requiere alguien contrasena.. o sea cualquiera puede modificarte informacion de alguna tabla porque es de acceso publico y libre. Todas las bases de datos generan archivos binarios, algunas de manera distribuida como te explicaba en las profesionales, y otras 1 solo archivo para todo... pero son binarios. Y es mas rapido para el sistema operativo o el motor, leer datos binarios que leer datos de texto en un archivo plano como sugieres alias excel o XML, que hay que convertir y eso... Piensalo, el servicio MySQL apenas te consume unos pocos KB en memoria, y si optas por Postgresql lo mismo... son unos ligeros KB en memoria, pero manejan la data y protegen la info de una manera que SQLite precae. |
|
|
|
|
En línea
|
|
|
|
pangea
Desconectado
Mensajes: 19
|
Los proyectos "no pueden crecer" porque si pudieran hacerlo ya no los hospedaría en esos servidores y por lo tanto ya no usarían esos CMS.
El caso es que no va a haber cientos de usuarios conectándose a la base de datos simultáneamente, van a ser proyectos de enfoque local en los que mayormente solo la administración modificará el modelo y las consultas simultáneas a este rara vez superarán la docena.
Como puedes ver son cosas pequeñas (como la mayoría de blogs que hay por ahí y usan mysql, dicho sea de paso) así que creo que poner el límite en sqlite no es descabellado. Ya me dirás que opinas.
Es más, lo que yo me preguntaba es si habría una ganancia de rendimiento si, en ocasiones, decidiera usar un modelo de datos flat-file en lugar de sqlite. Quiero saber hasta que punto podría llegar a valer la pena.
Por otro lado, SQLite no usa un archivo de texto plano (flat-file) como me parece entender que sugieres, sino un binario. Prueba a abrir con un editor de textos.
|
|
|
|
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
Por otro lado, SQLite no usa un archivo de texto plano (flat-file) como me parece entender que sugieres, sino un binario. Prueba a abrir con un editor de textos. En eso estamos mas que de acuerdo relee lo que postee mas arriba, cuando comente: SQLite es mas un manejador de archivos para mi que una base de datos. Es ligero por el hecho de ser una libreria que llamas, utilizas, creas un archivo binario Y cuando retorne a repetirlo: Recuerda que en SQLite se crea 1 archivo binario que guarda todo, indices, datas, vistas, todo... Si te sirve, vuelvo y te aclaro los SGDB como Oracle, MySQL me conscierne que tambien crean sus archivos fisicos, no de texto sino binarios aunque lo subdividan acorde a sus necesidades de desempeno El caso es que no va a haber cientos de usuarios conectándose a la base de datos simultáneamente, van a ser proyectos de enfoque local en los que mayormente solo la administración modificará el modelo y las consultas simultáneas a este rara vez superarán la docena. No superaran la docena?? con esto quieres decir que mas de 1 solo usuario estara conectado a la vez en la aplicacion??? Relee cuando te decia: Cuando intentan realizar modificaciones simultaneas en SQLite, el primer proceso bloqueara la base de datos, evitando cualquier otra modificacion, y se la libera al siguiente proceso solo hasta al terminar. Ademas, el archivo entero solo puede llegar a medir 2 Gigabytes (o asi era cuando maneje este motor, pero estaras mas informado en su website principal) Cuando te dije esto, me referia a que SQLite solo permitira 1 solo usuario modificando, actualizando registros de una tabla a la vez, la tabla sera bloqueada para evitar que otro usuario modifique, actualize algo... solo hasta que finaliza el primer proceso se le da paso al segundo... entonces depende la cantidad de usuarios que deseen trabajar a la vez en la informacion de una misma tabla.. suponte que solamente son 2 usuarios que estan conectados y quieren actualizar el campo PAIS de una tabla... hasta que el primer usuario que envio la peticion de actualizacion, hasta que esa actualizacion no finalize... la peticion del segundo usuario quedara en cola y si hablamos de 5 o mas usuarios ya sabes.. una fila india de procesos en espera que termina el primero, para darle seguimiento al segundo, luego al tercero, etc... Es más, lo que yo me preguntaba es si habría una ganancia de rendimiento si, en ocasiones, decidiera usar un modelo de datos flat-file en lugar de sqlite. Quiero saber hasta que punto podría llegar a valer la pena. Ganancias de rendimiento? si lo hay, pero de unos cuantos bytes o KB nada mas, ya que no existe un motor o servicio de SQLite ejecutandose, como ocurre con MySQL. Entonces si consideras ganarte unos bytes minimos en memoria si.... SQLite te los ahorraria. Pero ten pendiente lo anterior, y ten mas pendiente que cualquier usuario podra acceder a tus base de datos sin dar uso de usuario o contrasena (ya que SQLite no maneja este tipo de seguridad). O al menos era asi cuando lo utilize. Un saludo 
|
|
|
|
|
En línea
|
|
|
|
Nakp
casi es
Ex-Staff
Desconectado
Mensajes: 6.336
he vuelto :)
|
La pregunta entonces sería: Hasta que punto SQLite es ligero? Es casi tan ligero como usar un triste archivo xml? Porque claro, si es tan ligero tal vez no vale la pena que me complique la vida con las limitadas flat-file database. Agrego... no solo es tan ligero, sino mucho mas efectivo
|
|
|
|
|
En línea
|
Ojo por ojo, y el mundo acabará ciego.
|
|
|
pangea
Desconectado
Mensajes: 19
|
^TiFa^, no entiendo entonces porque dices que SQLite tiene problemas de seguridad. Es un archivo binario en servidor que tan siquiera es accesible por url. Lo pregunto porque no había oído antes críticas en ese sentido y me dejas preocupadx. Es cierto que habías dicho que era binario, no te había entendido.
Por otro lado, con lo de una docena me refería a personas leyendo el modelo, no escribiendo en él. En la mayoría de esos proyectos, con la notable excepción de las wikis, solo la administración va a escribir en el modelo, así que no hay colisiones. E incluso en el caso de las wikis, las probabilidades de que se creen colas de escritura de más de 2 personas son bajas, más de 3 ínfimas.
Por otro lado, tengo entendido que el consumo de MySQL no es tan bajo, piensa que esta disusión sería tonta si habláramos de ordenadores medianamente actuales, pero te hablo de Pentium I y alguna vez hasta de algo más antiguo que no apetece tirar.
Nakp, no tendrás datos que lo confirmen no? Precisamente me quiero evitar hacer yo mismx el benchmarking, porque me quitaría mucho tiempo.
|
|
|
|
|
En línea
|
|
|
|
^Tifa^
Desconectado
Mensajes: 2.804
|
^TiFa^, no entiendo entonces porque dices que SQLite tiene problemas de seguridad. Es un archivo binario en servidor que tan siquiera es accesible por url. Lo pregunto porque no había oído antes críticas en ese sentido y me dejas preocupadx. Es cierto que habías dicho que era binario, no te había entendido. Tiene problemas de seguridad fisicamente, ya que si alguien tiene acceso a tu PC podria modificar registros de las tablas sin necesidad de autentificarse con un usuario y contraseña. Tambien aunque no te lo confirmo, ya que se maneja esta situacion en SQLite podrian ser mas rapidas y efectivas las inyecciones SQL sobre SQLite, pero no lo confirmo no es mi area ni me dedico a ello. Desconozco porque no se ha expandido criticas negativas en cuanto a seguridad sobre SQLite, puede ser porque los proyectos donde se le ha utilizado no requieran seguridad de este tipo, o son proyectos muy pequenios o algo similar. Particularmente yo solo he visto uso de SQLite en firefox y al nivel de uso no requiere seguridad de ningun tipo ya que lo que guarda es algo personal del usuario que usa firefox en ese PC. Por otro lado, tengo entendido que el consumo de MySQL no es tan bajo Sigue siendo un consumo reducido, mira el consumo de un MySQL en uno de los servidores donde trabajo: [root@cubo-RepDom2 ~]# top -U mysql
top - 16:14:12 up 2 days, 2:21, 1 user, load average: 0.37, 0.32, 0.22
Tasks: 64 total, 1 running, 63 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 25.3%sy, 0.0%ni, 74.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2065920k total, 2013148k used, 52772k free, 10484k buffers
Swap: 2088440k total, 92k used, 2088348k free, 1852600k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2211 mysql 20 0 133m 17m 3640 S 0.0 0.5 0:00.35 mysqld En total el servidor tiene 2GB de ram fisica, donde el motor MySQL y sus subprocesos consume un 0.5% de 2GB de ram. El calculo es: 2000 X 0.5 / 100 = 100KB 100KB de 2GB es el total que consume el motor de MySQL obviamente, el porcentaje incrementaria si hubieran decenas de usuarios conectados haciendo constantes peticiones de I/O al servidor, ya que no solo MySQL abre 1 subproceso por usuario, sino que debe aplicarle a ese usuario toda la funcionalidad y permisos (que consumen ram) que posee ese usuario sobre su esquema. En el caso de SQLite todo lo anterior no aplica, se obvia, porque SQLite no maneja nada de permisos, funcionalidades, distribucion de memoria en buffer cache propio, entre otras cosas... SQLite solo maneja su lectura y escritura sin condiciones sobre su archivo binario SQLite no tiene 1 motor ejecutandose siempre, SQLite no tiene necesidad de evaluar ninguna condiciones como otros motores si hacen. Me parece que aunque quieras evitarlo, si vas a tener que considerar el Benchmarking, sobretodo para tu codigo fuente... y no se si SQLite lo tenga disponible, pero puedes pasarle profiling para ver que consumo tiene este al recibir o hacer una consulta SQL... te puedes ayudar de EXPLAIN si es que existe en SQLite. Entonces te conviene SQLite? si, te conviene si es un proyecto reducido como expones, si el hardware que dispones es el que comentas, y sobretodo por seguridad? averigua mas sobre inyecciones SQL y como evitarlas es lo que mas deberia preocuparte y no darle acceso de ningun tipo fisico a tu PC a nadie.
|
|
|
|
« Última modificación: 16 Marzo 2010, 16:29 pm por ^TiFa^ »
|
En línea
|
|
|
|
|
 |
