Re: Arquitectura P2P entre servidores
El 12 de diciembre de 2010 13:35, Julian julian.reyes.escri...@gmail.comescribió: y donde podria encontrar algo de dcumentacion sobre el proceso de repliegue de informacion creo que aun falta que indiques mas datos acerca de que es lo que realmente necesitas hacer, ya que lo del servidor central vs. servidores secundarios suena a una solucion ya encaminada. si todos los servidores estan fisicamente apartados, y necesitas sincronizar sus datos, una solucion podria ser algo tan simple como que una vez al mes se envien (por SSH) los nuevos datos desde los servidores secundarios en archivos de texto y estos luego son cargados en el servidor central, a su vez desde el servidor central se envian sus nuevos datos a los servidores secundarios tambien mediante archivos de texto. si te quieres complicar con algo mas avanzado puedes revisar el siguiente articulo [1] acerca de como implementar la replicacion circular en MySQL. posiblemente encuentres una guia similar para Postgres, pero insisto que antes deberias analizar bien que es lo que realmente necesitas y buscar la solucion mas simple. [1] http://onlamp.com/onlamp/2006/04/20/advanced-mysql-replication.html -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
te comento es una aplicacion que va a funcionar en uno de los departamentos de mi pais, donde se va recolectar información madiante digitación de unas encuentas, pero obviamente una persona puede ser encuestada en un lugar distinto y luego encuentada en otro momento en otra ciudad creando una duplicidad que es lo que quieren evitar con este sistema. se sugirio que el sistema estuviera totalmente centralizado, es la mejor opcion, pero hay municipios (ciudades), que por X o Y motivo pueden o tiene problemas de conectividad, y necesitan que el trabajo no se suspenda por falta de internet, en otras palabras desean la maxima disponibilidad posible. las personas que plantearon los requisitos estoy completamente seguro que no tiene las minima idea de lo que solicitaron en los terminos del contrato pero el contrato debe cumplir a cabalidad lo que se exige o al menos una solucion aproximada porque si no se incumpliria en el mismo. vuelvo y se que las bases de datos se pueden poner a trabajar de una manera que cada servidor se conumique con los demas, pero estoy seguro que este tipo de configuracion son para que siempre tengan conexion. digamos que la solucion que tengo en mente hasta el momento es la siguiente servidor secundario 1. la persona trabaja sobre un servidor secundario 2. al momento de procesar la informacion el intenta comunicar al servidor central si no hay conexion se guardan los cambios como si se tratase de una CVS. 3. una tarea programada de cada 15 minutos (por ejemplo) revisa si existen datos que sincronizar si existe conexion los sincroniza servidor central 1. el servidor central recibe peticiones de un servidor secundario hace validaciones a los datos y regresa una novedad de dicho registro 2. si no existe conexion con el servidor secundario guarda las respuesta en algun lugar 3. si existe una confrontacion de informacion con otros sistemas el servidor genera las novedades de cada servidor secundario 4. una tarea programa de cada 15 minutos (por ejemplo) revisa que exista conexion entre el y los servidores secundarios si existe envia las novedades a quien corresponda pues mirandolo de este modo se utilizara algun protocolo para que una tarea programa (cron) envie la informacion cuando exista conexion, el resto simple aplicaciones, la diferencia es que el servidor principal seria nada mas web services para los demas servidores. yo tengo esta idea pero me gustaria conocer cuales serian esos metodos de comunicacion como web services escuche una recomendacion de REST de alguien y si estuve mirandola como la solucion viable, tamiben escuche algo con protocolo torrent, me llama mas la atencion ya que el torrent puede tener las conexiones cifradas y ademas en caso de que la conexion se caiga en plena transferencia no se pierde los transferido ya que una vez se haga la confrontacion pueden llegar a ser grandes cantidades de datos las tranferidas
Re: Arquitectura P2P entre servidores
El 13 de diciembre de 2010 11:40, Julian Reyes Escrigas julian.reyes.escri...@gmail.com escribió: [...] digamos que la solucion que tengo en mente hasta el momento es la siguiente servidor secundario 1. la persona trabaja sobre un servidor secundario 2. al momento de procesar la informacion el intenta comunicar al servidor central si no hay conexion se guardan los cambios como si se tratase de una CVS. 3. una tarea programada de cada 15 minutos (por ejemplo) revisa si existen datos que sincronizar si existe conexion los sincroniza servidor central 1. el servidor central recibe peticiones de un servidor secundario hace validaciones a los datos y regresa una novedad de dicho registro 2. si no existe conexion con el servidor secundario guarda las respuesta en algun lugar 3. si existe una confrontacion de informacion con otros sistemas el servidor genera las novedades de cada servidor secundario 4. una tarea programa de cada 15 minutos (por ejemplo) revisa que exista conexion entre el y los servidores secundarios si existe envia las novedades a quien corresponda en tu mail original decias que la sincronizacion debia hacerse una vez al mes... ahora indicas que deberia ser cada 15 minutos? -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
Ricardo te has confundido te explico en el mail inicial escribi que una vez al mes el servidor central va a tener una confrontacion de la informacion de la base de datos con la base ded atos de otros sistemas pero aparte de eso los usuarios van a alimentar los servidores secundarios que estos deben a su vez alimentar el principal, es logico que la informacion de los servidores secundarios deben llegar en algun momento al principal de esto debe ser lo mas pronto posible
Re: Arquitectura P2P entre servidores
El 13 de diciembre de 2010 12:05, Julian Reyes Escrigas julian.reyes.escri...@gmail.com escribió: Ricardo te has confundido te explico en el mail inicial escribi que una vez al mes el servidor central va a tener una confrontacion de la informacion de la base de datos con la base ded atos de otros sistemas pero aparte de eso los usuarios van a alimentar los servidores secundarios que estos deben a su vez alimentar el principal, es logico que la informacion de los servidores secundarios deben llegar en algun momento al principal de esto debe ser lo mas pronto posible hay una expresion llamada aplicar poder de sintesis que hubiera sido bueno aplicar en tu thread... ;) creo que una solucion simple y que no requiera configurar/implementar replicacion de MySQL o Postgres seria, y tal como ya lo mencionaron, el uso de webservices (mediante HTTPS). SOAP o REST da casi lo mismo si el servidor y los clientes los implementaras tu mismo usando el mismo lenguaje (PHP). -- Ricardo Mun~oz A. http://www.tux.cl
Re: Arquitectura P2P entre servidores
En vez de pensar en cocinar cosas... ¿no será mejor probar alguna de estas?: http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas No he probado nunca algo así, pero suena como una solución a este problema. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://card.ly/gon http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Arquitectura P2P entre servidores
Gonzalo He leido las soluciones basadas en sistema de base de datos distrbuidas y no pienso que sea la solución a pesar de que los servidores tienen en comun datos se necesitan realizar datos que sean a ser tratados con PHP por lo que no intersa como solución la comunica directa de las bases de datos sino mas bien la comunicación entre las aplicaciones de una manera que se garantice que en algún momento la información va a ser transferida, sea en el momento de ingreso o luego cuando exista conexión. On lunes 13 de diciembre de 2010 at 11:16, Gonzalo Diaz Cruz wrote: En vez de pensar en cocinar cosas... ¿no será mejor probar alguna de estas?: http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas http://es.wikipedia.org/wiki/Bases_de_datos_distribuidas No he probado nunca algo así, pero suena como una solución a este problema. -- ~~~ Atentamente, Gonzalo Díaz Cruz Estudiante Ingeniería de Ejecución en Computación e Informática Universidad de Santiago de Chile ~~~ http://card.ly/gon http://blog.gon.cl/ http://twitter.com/sir_gon http://flickr.com/photos/sir_gon
Re: Arquitectura P2P entre servidores
y donde podria encontrar algo de dcumentacion sobre el proceso de repliegue de informacion El 12 de diciembre de 2010 00:00, Juan C. Olivares juan...@juancri.comescribió: Es interesante el tema. Twitter utiliza el mismo protocolo de bit torrent para distribuir información entre sus servidores. No es una idea tan descabellada. La implementación dependerá del lenguaje que domines. 2010/12/12 Julian Reyes Escrigas julian.reyes.escri...@gmail.com para darle tambien mas sencilles al tema omitan lo de la confrontacion de la informacion mensual, no tengo la necesidad de hacer replicas de datos. unicamente piensen en que que asi como se comunica un servidor secundario con el principal, ahora va en reversa, para enviarle las novedades. otra cosa pensaba en crear un sistema de historial de modificaciones para cada registro que es el que indica el estado del registro, si este se encuentra sincronizado cuando fue sincronizado y otros datos adicionales para un completo control de el estado de cada registro. existe alguna referencia de esto, algo como lo que he visto en python con Django pero para PHP -- Atte, Juan Cristóbal Olivares *Renovarse o morir: Mi PC de los sesenta tenía veinte mil militantes. Y mi PC del siglo XXI tiene cuarenta gigabytes.* -- Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos – Edsger W. Dijkstra
Re: Arquitectura P2P entre servidores
El 11 de diciembre de 2010 18:58, Julian Reyes Escrigas julian.reyes.escri...@gmail.com escribió: tengo un rato y es que crear una aplicación con un especie de repositorio central de información. un servidor central que va a contener toda la información de X cantidad de locaciones, cada locación tiene su propio servidor donde solo se encuentra la información de su locación, cuando un cliente opera, este lo hace directamente sobre el servidor local, nunca sobre el central, el servidor secundario es el que se conecta con el central (si existe conexión) para validar la información, si no hay conexión este simplemente lo deja para después. la idea es que periódicamente (aproximadamente cada mes) el servidor central va a confrontar toda la información con otros sistemas y las novedades son enviadas a cada servidor secundario (si existe la conexión). alguien tiene idea de si existe algún servicio en especial que ayude con una tarea semejante y se esta se puede implementar en PHP, ya que es un entorno LAMP Estimado :Su idea no es descabellada.Para programar dicha aplicación en PHP investigue sobre SOAP ,ya que dicha librería permite desarrollar aplicaciones cliente/servidor. Ahora mi duda es sobre la base de datos en que lo va a desarrollar :Si el proyecto tiene muchas transacciones, tal vez MySQL sea insuficiente ,y mejor es optar por PostgreSQL, y por lo demás es mas potente. Saludos. Patricio Morales Fariña Técnico en Computación Alumno Ing. Informática (Técnicos Vespertino) Universidad de los Lagos 045-219291- Temuco Chile cel 78732062 Linux user number 481578 http://counter.li.org/
Re: Arquitectura P2P entre servidores
bueno lo de la base de datos es discutible aunque no encuentro una razón para la cual MySQL no sea capaz de manejar dicho proceso, pero igual lo interesante aquí es conocer la forma en la que interactuan los servidores. me gustaría conocer cuales son las razones (pros y contras) de porque usar PostgreSQL en cambio de MySQL. muchas gracias por tu atención y pronta respuesta
Re: Arquitectura P2P entre servidores
El sáb, 11-12-2010 a las 17:33 -0500, Julian Reyes Escrigas escribió: bueno lo de la base de datos es discutible aunque no encuentro una razón para la cual MySQL no sea capaz de manejar dicho proceso, pero igual lo interesante aquí es conocer la forma en la que interactuan los servidores. me gustaría conocer cuales son las razones (pros y contras) de porque usar PostgreSQL en cambio de MySQL. muchas gracias por tu atención y pronta respuesta Existen muchas comparativas en internet buscando solamente como mysql vs postgresql en google. Mira esta es bastante interesante: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL -- Andrés Esteban Ovalle Gahona (kill-9) Ingeniero (E) Computación e Informática SysAdmin - Acepta.com S.A www.acepta.com Staff Debianchile.cl www.debianchile.cl Movil: 09-5795880 Usuario Linux #456290 (counter.li.org) signature.asc Description: Esto es una parte de mensaje firmado digitalmente
Re: Arquitectura P2P entre servidores
otra pregunta dejando de lado lo de los SGBD, el SOAP se ve como un protocolo basado en XML , no hay otras alternativas, algo como JSON o bueno que se yo la verdad me gustaría saber como servicios como facebook (creo) o amazon repliegan la información entre sus servidores, claro esta no tengo la intención de implementar algo mas alla de información de la base de datos. también me gustaría conocer que mecanismos existen para que la comunicación entre dicho servidores sea cifrada algo así como si se comunicaran vía HTTPS, ya que la información puede llegar a ser sensible.
Re: Arquitectura P2P entre servidores
On Dec 11, 2010, at 6:58 PM, Julian Reyes Escrigas wrote: un servidor central que va a contener toda la información de X cantidad de locaciones, cada locación tiene su propio servidor donde solo se encuentra la información de su locación, cuando un cliente opera, este lo hace directamente sobre el servidor local, nunca sobre el central OK. el servidor secundario es el que se conecta con el central (si existe conexión) para validar la información, Para esto, debes crear un servicio en el servidor central. Puede ser SOAP o JSON como conversaban. Mi recomendación personal es REST con JSON o XML... en realidad, lo que te sea mas fácil con el framework en el que estás desarrollando (cakephp, codeigniter, symfony, etc...). si no hay conexión este simplemente lo deja para después. Esto parece complicado y no trivial de hacerlo bien de buenas a primera... Ahí necesitas algún proceso que se encargue de cuadrar periódicamente... uff, un desastre. la idea es que periódicamente (aproximadamente cada mes) el servidor central va a confrontar toda la información con otros sistemas y las novedades son enviadas a cada servidor secundario (si existe la conexión). Si es sólo datos (obviando el tema del servicio descrito arriba), tal vez podrías hacerlo a nivel de bases de datos con replicación. http://www.postgresql.org/docs/9.0/static/different-replication-solutions.html alguien tiene idea de si existe algún servicio en especial que ayude con una tarea semejante y se esta se puede implementar en PHP, ya que es un entorno LAMP. No, desconozco algo para LAMP... este tipo de cosas se resuelve en el mundo de apps empresariales con software muy complicado y que muy poca gente entiende... no te lo recomiendo. Puedes hacer lo mismo con PHP usando los conceptos básicos de orientación a servicios. No es necesario que sea perfecto, lo usual en este tipo de sistemas es que tienes uno o más sistemas que ya existen y los vas modularizando de a poco. Aldrin Martoq http://aldrin.martoq.cl/
Re: Arquitectura P2P entre servidores
On Dec 11, 2010, at 7:33 PM, Julian Reyes Escrigas wrote: me gustaría conocer cuales son las razones (pros y contras) de porque usar PostgreSQL en cambio de MySQL. En una frase: - MySQL vale yuyo y PostgreSQL es el oracle del mundo opensource. En 4 párrafos: - MySQL en sí no es malo, pero la configuración inicial que trae es muy mala para correr sistemas transaccionales cuando quieres tener tranquilidad/seguridad que ningún dato se va a corromper. No conozco ningún sistema en que el requisito de asegurarme que los datos no se corrompan se pueda transar. Ninguno. En todos, la data es lo más importante del sistema. - Ahora, esto en MySQL tiene solución, pero tendrás que aprender un montón. De partida, tendrás que configurar InnoDB con todas sus perillas para que tengas transacciones decentes. Después tendrás que revisar otras configuraciones idiotas, como el strict mode. Ya sólo con eso tienes para aprender 1 mes, y harta pega que hacer en cada sistema que montes bajo MySQL. - Si no lo haces, cuando alguien inserte datos raros MySQL ni siquiera lanzará un error, sino que hará alguna estupidez silenciosamente... este es el peor de los escenarios, pues no te estás dando cuenta la JK%#$JK%$ que está quedando con tus datos. - Si eres testarudo y logras dejar MySQL como debe ser, el rendimiento será horrible... te habrá salido mas barato y seguro haber partido con PostgreSQL al principio. En varios párrafos: busca en internet, como el link que te mandaron. Aldrin Martoq http://aldrin.martoq.cl/
Re: Arquitectura P2P entre servidores
Aldriq gracias por tus comentarios los tendre en cuenta, aunque ahora mismo no me preocupa tanto el sgdb ya que yo no soy el encargado de elllo sino del desarrollo del php. me gustaria saber mas bien hacia donde enfocar mis investigaciones, algun ejemplo si es posible practico
Re: Arquitectura P2P entre servidores
para darle tambien mas sencilles al tema omitan lo de la confrontacion de la informacion mensual, no tengo la necesidad de hacer replicas de datos. unicamente piensen en que que asi como se comunica un servidor secundario con el principal, ahora va en reversa, para enviarle las novedades. otra cosa pensaba en crear un sistema de historial de modificaciones para cada registro que es el que indica el estado del registro, si este se encuentra sincronizado cuando fue sincronizado y otros datos adicionales para un completo control de el estado de cada registro. existe alguna referencia de esto, algo como lo que he visto en python con Django pero para PHP
Re: Arquitectura P2P entre servidores
Es interesante el tema. Twitter utiliza el mismo protocolo de bit torrent para distribuir información entre sus servidores. No es una idea tan descabellada. La implementación dependerá del lenguaje que domines. 2010/12/12 Julian Reyes Escrigas julian.reyes.escri...@gmail.com para darle tambien mas sencilles al tema omitan lo de la confrontacion de la informacion mensual, no tengo la necesidad de hacer replicas de datos. unicamente piensen en que que asi como se comunica un servidor secundario con el principal, ahora va en reversa, para enviarle las novedades. otra cosa pensaba en crear un sistema de historial de modificaciones para cada registro que es el que indica el estado del registro, si este se encuentra sincronizado cuando fue sincronizado y otros datos adicionales para un completo control de el estado de cada registro. existe alguna referencia de esto, algo como lo que he visto en python con Django pero para PHP -- Atte, Juan Cristóbal Olivares *Renovarse o morir: Mi PC de los sesenta tenía veinte mil militantes. Y mi PC del siglo XXI tiene cuarenta gigabytes.*
