Posted By: Hacker¿Alguien sabe como hacer este tipo de diseño de manera eficiente o conoce algún tipo de artículo o libro sobre manejar grandes cantidades de datos con php sin base de datos?

Bueno, no conozco libros o artículos que hablen de esto, pero está bastante extendido en las aplicaciones empresariales.

La organización suele depender del autor, pero siguiendo unas reglas básicas de bases de datos se puede escribir de forma eficiente. Ten en cuenta que tanto MySQL como Oracle o cualquier NoSQL, al fin y al cabo se almacenan en ficheros y de lo que se encargan es de gesti0onar eses accesos para que no colapsen las consultas.

En un caso como blogia separaría por directorios cada blog y almacenaría en cada directorio todo referente a ese blog (como en su día hacía blogger) teniendo siempre en cuenta principalmente los diferentes accesos de escritura a los ficheros.

Por ejemplo:
/blog1
/blog2
...
/blog_n/
- configuracion.txt
- indice_posts.txt
- /posts/
--- post_1.txt
--- post_2.txt
--- ...
--- post_n.txt
- /comentarios/
--- comment_1.txt
--- ...
--- comment_n.txt
- /imagenes/

Con esta estructura, el acceso de escritura a cada fichero lo tendría solamente una persona (si no me he equivocado), lo que facilita la escritura sin interrupciones, bloqueando el fichero cuando se edita, y desbloqueandolo cuando se ha guardado.

Dentro de cada fichero se pueden almacenar los datos de la forma que quieras, por ejemplo en formato json (tan de moda últimamente) o en xml, por ejemplo.

Por poner un ejemplo: post_x.txt podría tener este formato.
fecha: [fecha]
titulo: [titulo]
contenido: [base_64(contenido)]
crc: md5(contenido) // Para verificar que no está corrupto.

A este fichero solo accede como escritura el autor, así que no habría peligro de corromperlo.

Un ejemplo claro de uso de ficheros de texto para bases de datos con muchas peticiones, son las dnss en un servidor, que se almacenan en ficheros de texto, cada dominio/subdominio/wild en uno diferente y no suele corromperse, al menos no más que una MySQL.

Por último, tener claros los permisos de acceso a la carpeta y a ser posible tenerlos fuera de la vista web.

Espero que te pueda al menos orientar en algo

Mis cosas: Intercambio de enlaces | Tienda de setas

Impresionante Antonio, se nota que el foro tiene un nivel grandísimo.

Posted By: Hacker¿No es ineficiente esa cantidad de archivos en un sistema de archivos? Hace años, estudiando sistemas operativos recuerdo que un kernel antiguo de linux que fue el que estudiamos tenía límite de archivos por carpeta, 16mil o algo así si no recuerdo mal.

Ciertamente, en la mayoría de los SO, debido a la estructura del FS, están limitados el número de archivos, como por ejemplo en el Minix de Tannenbaum (Este fue el que estudié yo ;)) y los actuales no son menos, y dependiendo de si es ext2, 3, 4, FAT, FAT32, NFS, NTFS, etc varía, pero todos están limitados.
Cuando uno tiene que almacenar mucha cantidad de ficheros, para solucionarlo está la forma append para añadir información a ficheros, y por ejemplo, al almacenar los comentarios de un post, pueden incluirse todos en el mismo fichero puesto que son elementos que no se suelen modificar después. Incluso los post de un solo blog pueden incluirse en un solo fichero suponiendo que el editor sea únicamente uno.
Otra solución es un sistema de pila (incluso de árbol), en el que se van añadiendo los post o los comentarios a un fichero intermedio apilados por orden y cada cierto tiempo hacer un bloqueo de los ficheros de texto para actualizarlos, deshaciendo la pila. Más o menos como Analytics o Adsense hacen con los datos de visitas y clicks, por eso se actualiza cada cierto tiempo.
Otra opción más puede ser meter los ficheros de un mismo blog en un contenedor único (por ejemplo un gzip) al estilo de lo que hacen los ficheros phar para php o los jar para java.
Por poner un ejemplo, la MySQL lo que hace es tener una serie de ficheros de cache de consultas para devolver resultados sin necesidad de almacenar los datos en la base de datos y cuando se cierra o se anula la persistencia se actualiza.

Existen otras formas de almacenarlos en ficheros, como las bases de datos sqlite o las viejas dbf (para los que php, python o perl tienen soporte).

Básicamente, lo importante es no dar acceso a escribir a mismo tiempo a dos usuarios a un mismo fichero, algo que puede solucionarse con un sistema de semáforos y un sistema de pila, si los datos son muy complicados de gestionar en diferentes ficheros.

Posted By: HackerAbrir 200 o 300 ficheros, leerlos, procesar la información. ¿No parece bastante ineficiente?

En mi caso, lo que haría aquí sería (con cada blog en un directorio diferente):

configuracion.txt (Guardar datos de la configuración tipo variable-valor, por ejemplo la plantilla o el nombre del blog)

{
[0]: { ["var"]: "nombre", ["value"]: "Mi blog"},
[1]: ....
}

indice-de-posts.txt (Guardar un índice de las entradas al blog, guardando los mismos posts si serán pocos o en otros ficheros si son muchos)

{
[0]:{["id"]: 0,["fecha"]: 11111111, ["titulo"]: "Mi post", ["contenido"]: "Este es el contenido de mi post" }
[1]: ....
}

En contenido también podría ser el nombre del fichero a abrir con el contenido del texto. Normalmente guardando el mismo contenido en el índice valdría para una cantidad de posts limitada.
En caso contrario leyendo los ficheros o el fichero del post que hay que mostrar en ese momento sería suficiente, ya que en un blog, por regla general, muestran un máximo de 10 a la vez. También se pueden cachear los html de esos 10 a la vez hasta que vuelva a modificarse, con lo que no habría que leer los 10 hasta que no se modificase uno de ellos.

...y para los comentarios lo mismo.
Creo que la mejor opción para los comentarios sería crear un fichero de comentarios por cada post, anotando en un campo en el fichero de post el número de comentarios que hay para facilitar esa información sin abrir el fichero. El fichero de comentarios puede llamarse como el [id del post].txt así se sabe cuál hay que leer en cada momento. Y, al igual que en el de posts, se pueden ir añadiendo al final del fichero abriéndolo como append con los campos:
[id]
[usuario]
[email]
[web]
[comentario]
[fecha]

Currándolo un poquito más se puede optimizar muchísimo mejor, esto sería para una versión fácil.
Ahora, suponiendo un blog con 10000 posts (bastante grande) y 10 comentarios por blog, tendrías:
1 fichero config
1 fichero indice
10000 ficheros de posts
10000 ficheros de comentarios

Todos ellos bastante pequeños.

Hay que tener en cuenta que la mayoría de los blogs, serán muchísimo más pequeños y en cada directorio pueden guardarse muchos menos.
En el caso de blogia, yo me imagino que por cada blog almacenará 3 ficheros (aunque esto es hablar por hablar): config, indice (con el contenido), comentarios (de todos los posts con un id_post). Con una buena memoria RAM del servidor creo que funcionaría de forma óptima, al menos para la mayoría de los blogs, teniendo en cuenta que el contenido HTML puede cachearse mientras no cambien entradas y comentarios.

Sería algo como:
[CONFIG] (nombre_blog, usuario, contraseña_md5, plantilla, widgets, etc...)
var
value

[POSTS]
id
title
date
content
tags
id_categorie
stick

[COMMENTS]
id
id_post
date
user
email
web
comment
aproved?

¿[CATEGORIES]?
id
name

Jajaja maravillosa la respuesta. Al final como dijiste en los primeros post lo que estamos es creando una base de datos organizada en ficheros de texto a lo cutre. ¿De verdad es esto más eficiente que usar mysql? XDDD

Eso si, esto lo veo tremendamente escalable, ya que podemos tener servidores para los distintos contenidos estáticos montados muy fácilmente.

Entonces tu veredicto de usar texto plano vs mysql para servicios tipo blogia con esa cantidad de visitas (unos 4-5 millones de impresiones mensuales) ¿es? :P

Posted By: HackerEntonces tu veredicto de usar texto plano vs mysql para servicios tipo blogia con esa cantidad de visitas (unos 4-5 millones de impresiones mensuales) ¿es?

Como decía antes, por comodidad probablemente usaría MySQL, pero por eficiencia, mucho mejor el texto plano. Eso sí, hay que currarse bien la estructura con los ficheros y la MySQL ya está programada

Posted By: prophPD: pido disculpas por hacer una aportación tan cutre a un post con tanto nivel

Hombre, mejor no lo has podido decir y de cutre nada.

Posted By: prophPuedes escalarlo a nivel de servidores

Con MySQL es más dificil (que se lo digan a Twitter ) pero sí es cierto, que por ejemplo con Cassandra o MongoDB se hace muy fácil la escalabilidad.

Creo que en realidad no hay mucha diferencia, al fin y al cabo los compiladores y los intérpretes funcionan igual con funciones u objetos a la hora de compilar.
El tema de secuencial o POO creo que está más en con lo que cada uno se sienta más cómodo a la hora de programar. Por ejemplo en mi caso me gusta más la secuencial, muy probablemente porque fue como aprendí y por tanto me desenvuelvo mejor, pero en ciertas cosas me parece más útil la POO, especialmente en proyectos muy grandes, al ir encapsuladas las clases como pildoritas, hace pensar en la aplicación como un todo más fácilmente. En el caso de pequeños proyectos en php yo sigo empleando funciones exceptuando las BBDD que uso PDO (Si ya está programado para qué volverlo a hacer?).
En los frameworks php que ahora están tan de moda, la mayoría usa POO para toda la aplicación algo que veo muy bien, como decía antes, para grandes proyectos: symphony, codeigniter, cake, zend, etc... Para estos proyectos me decanto por symphony que da más libertad (aunque codeigniter es más sencillo). Para proyectos pequeños me gusta especialmente limonade que es a base de funciones y me parece que facilita mucho el entendimiento de una aplicación sencilla. En POO me gusta Silex (de los mismos que Symphony) pero se complica el aprendizaje.
Esto de los framworks lo digo porque parece que la inmensa mayoría de los desarrolladores que usan estos frameworks se decantan por el POO, pero viendo los valores de la misma aplicación sencilla el resultado en eficiencia es similar entre POO y secuencial-estructurada. Imagino que a la larga, cuando la mayoría va decantándose por la POO el desarrollo base de PHP optimizará mucho más para este tipo de desarrollo y por tanto terminará siendo más eficiente. En PHP 6 parece que empieza a transformarse en una rama más de java con la forma de escribir clases y objetos y zend está muy volcado por esta vía.

En resumen, creo que la eficiencia debe ser similar y que hay que contar también con la eficiencia a la hora de programar, curva de aprendizaje y todo eso. Ahora creo que es mejor adaptarse a en lo que uno se sienta más cómodo.

Busca por ahí scripts de foros sin base de datos y verás que es fácil el tema de artículos con comentarios.Haciendo Cuentas __ Ayuda Familiar _ _ casas rurales

Posted By: PedroTengo una web con 12 millones de fichas, almacenadas en una bbdd de varios Gb.

¡¡Pedro, por Dios!!

¿Qué tienes en 12 millones de fichas? tienes fichados a todos los portugueses o qué... Haciendo Cuentas __ Ayuda Familiar _ _ casas rurales

Posted By: Hacker¿Usáis algún IDE en particular para vuestros desarrollos?

Para pequeños Geany.

Para más grandes Netbeans. Este es el mejor, para mí, de los que he probado. La pena es que está hecho en Java y es bastante lento aunque algo más rápido que eclipse (también en Java).

Muy cómodo para muy pequeños también es Scribes (este solamente está para Linux de momento).

Voy a arrojar algo de mi experiencia en este campo.

Administro una web con 5 millones de visitas al mes y casi 19 millones de impresiones y uso Mysql, soportada por dos servidores pequeños (entorno a 2 gb de ram cada uno) en balanceo de carga, y según mis cuentas aun aguantaría un 40% más de visitas.

Escucho mucho, sobre soluciones nosql, y esa gente que me lo dice, no gestionan bien las peticiones tanto al servidor como las consultas a la base de datos.

Hay que realizar una optimización de todo, php, apache, mysql, peticiones http imágenes, etc.


1º) si tu página tarda medio segundo de media en cargarse, en vez 7 o 8 segundos como pasa en algunos blogs, seguramente puedas atender muchas más peticiones concurrentes.
2º) Limitar peticiones http. Una web tiene que cargar el fichero html, un css, un javascript y una sola imagen con sprite, de esta forma tendrás 4 archivos para servir, 4 peticiones por cada página. En algunas páginas he visto 50 peticiones entre css, javascrit, imágenes, fondos, etc, multip?icalo por cientos de usuarios y notarás la diferencia.
3º) Optimizar apache, parámetros de Tunning(todo un mundo)
4º) Optimizar consultas mysql, y servidor mysql (un mundo mas extenso)
5º) Usar mysql cuanso sea extrictamente necesario, en mi caso las páginas se generan y se guardan en el servidor en un archivo, cuando una página es requerida no se consulta la bd, se envía el archivo, si la página cambia, se regenera.
6º) Si tienes una bd muy muy grande, como una tabla de comentarios con millones de filas, pártela en 2 una con los comentarios más recientes y los antiguos (que son muy poco visitados) en otra, generalmente en otro servidor (algo así hace facebook con los comentarios antiguos)

Hay muchas cosas que puedes cambiar, sin dejar las ventajas de una bd te ofrece.

Posted By: Pingalgo así hace facebook con los comentarios antiguos

Facebook ahora usa Cassandra

Posted By: Hacker¿Usas también php? Si es así, ¿qué acelerador/cache usas?

Pues no uso ningun acelerador, está todo programado por mi, genero las páginas, las comprimo y las guardo en el servidor para ser enviadas, si son modificadas se regeneran.

No puedo recomendarte ningún sistema, no he provado ninguno.

Gracias Hacker, lo pongo en mi pila de cosas pendientes por mirar.

También para los que quieran mirar las consultas más lentas: http://dev.mysql.com/doc/refman/5.0/es/slow-query-log.html

Saludos.

Por cierto corso, usas tu algún acelerador para php?

Posted By: Pingun javascript

¿Analytics y Adsense hay alguna forma de juntarlos?

Posted By: PingNo, que yo sepa no hay forma de juntarlos, pero yo me refiero juntar todos los javascript que se cargan en tu servidor en para reducir el número de peticiones http, por tanto de conexiones, memoria, cpu.

Adsense y analytics no se cargan en tu servidor, por lo que no consumen recursos, pero si aumetan el tiempo de carga en el cliente.

Era más que nada para ver si había alguna manera de mejorar los tiempos de carga de esos js, mera curiosidad.

Muy buenas aportaciones

Javi, ¿cómo va el formulario?