Base de datos MySQL... u otra?

2008-02-17 Por tema Rodrigo Fuentealba 
El 17/02/08, Leonardo Soto M. <[EMAIL PROTECTED]> escribió:
> 2008/2/16 Rodrigo Fuentealba <[EMAIL PROTECTED]>:
> > El 16/02/08, Leonardo Soto M. <[EMAIL PROTECTED]> escribió:
> > > 2008/2/15 Rodrigo Fuentealba <[EMAIL PROTECTED]>:
> > > > El 15/02/08, Leonardo Soto M. <[EMAIL PROTECTED]> escribió:
> > > > > Dudo *mucho* que el índice del buscador de google esté almacenado en 
> > > > > un RDBMS.
> >
> > MySQL /no/ es un RDBMS.
>
> No seas odioso. Ya leimos eso un montón de veces.

Fue un lapsus nada más...

> Pero (a) yo puse RDBMS para ahorrarme la lata de escribir "Base de
> datos SQL o algo por el estilo"

DBMS podría funcionar; o SGBD, SABD, SMBD si quieres.

> De donde se desprende que el 99% del tiempo, la gente usa
> el término RDBMS en un sentido no demasiado estricto.

No me extraña; pero bueno; por cierto, pues no le cojo la gracia.

> > Y no hablo del buscador (que siempre fue
> > BigTable + GFS) sino del índice de servicios de Google.
>
> Ah. De ahí la confusión entonces.

Suele pasar.

> En cualquier caso, volviendo al tema original, ni Google, ni
> Wikipedia, ni todos esos sitios con necesidades absurdas de
> rendimiento usan un "Base de datos SQL o algo por el estilo"

Ninguno ha dado la talla en rapidez a tal punto; los DBMS de la clase
PostgreSQL, SQL Server, MySQL y otros son para sistemas no tan
grandes, en los que importa mucho la integridad.

Si se quiere mejorar la performance en sitios que son grandes pero que
no son masivamente utilizados (como Yahoo! Bookmarks), es mejor no
usar claves foráneas y planificar muy bien las consultas. Y ojalá
mandar al autoincrement y similares a la punta del cerro, pues causan
problemas.

Germán Poó dio un buen par de detalles de esto.

http://listas.inf.utfsm.cl/pipermail/linux/2007-July/038322.html

Los sistemas del tipo redes sociales utilizan demasiado la caché, sin
utilizar mucho las bases de datos, pues les interesa justamente que
sea rápido y no preciso (algo fundamental en un DBMS donde se hacen
varios cientos de miles de transacciones bancarias).

Por ejemplo, los Google Groups dan cuenta de varios errores. Si ven la
lista de threads, en los detalles dice "9 mensajes"; pero cuando van a
leer el thread, se dan cuenta de que sólo existen 8. Last.fm tampoco
está exento de estos fallos: la primera semana que estuve suscrito
salió en mi lista que yo había escuchado un disco de Sin Bandera,
cuando yo lo único que escucho es metal y música clásica (y no hay
otros MP3 en mi disco duro que los que yo escucho, y me niego a que
haya).

> Como referencia, acá un tipo colleccionó links
> a un montón de material "on topics related to designing of high
> throughput, scalable, highly available websites":
> 

Excelente! tendré harta lectura para el fin de semana.

-- 
Rodrigo Fuentealba

Problemas de enrutamiento en una sola via con openvpn

2008-02-17 Por tema kazabe 
Holas

Estoy intentando conectar dos redes (RedA 10.2.2.0/24 y RedB
10.1.1.0/24) por medio de servidores debian usando openvpn.  El
servidor RedA esta configurado como servidor VPN, y el servidor RedB
esta conectado a RedA como cliente.   Pero me sucede que desde
cualquier estadion de RedB puedo conectarme a cualquier estacion de
RedA, pero no funciona al reves (RedA no puede ver a RedB).

Basicamente, desde RedB hacia red RedA todas las comunicaciones se van
directamente por medio de la VPN,  Pero desde RedA hacia RedB, el
trafico se va directamente por internet, sin intentar buscar el
destino por medio de la vpn.  La unica diferencia entre las dos redes,
es que RedA sale a internet por medio del enrutador del ISP como
puerta de enlace, mientras que el servidor de RedB sale directamente a
internet con la ip publica configurada en eth0.

Esta es la informacion de RedA
=
RedA
tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:192.168.12.1  P-t-P:192.168.12.2  Mask:255.255.255.255

eth0  Link encap:Ethernet  HWaddr 00:D0:09:A8:F8:AE
  inet addr:10.2.2.1  Bcast:10.2.2.255  Mask:255.255.255.0

Kernel IP routing table
DestinationGateway Genmask   Flags  Metric Ref
   Use Iface
192.168.12.2 *255.255.255.255  UH  0
 0 0 tun0
192.168.1.0  *255.255.255.0  U0
0 0 eth1
10.2.2.0   *255.255.255.0  U0
  0 0 eth0
192.168.12.0192.168.12.2255.255.255.0UG  00
 0 tun0
10.1.1.0   192.168.12.2255.255.255.0UG  00
0 tun0
default192.168.1.2540.0.0.0 UG   0
   0 0 eth1



y esta es la informacion de RedB


RedB
tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:192.168.12.6  P-t-P:192.168.12.5  Mask:255.255.255.255

eth1  Link encap:Ethernet  HWaddr 00:05:5D:8A:98:BE
  inet addr:10.1.1.1  Bcast:10.1.1.255  Mask:255.255.255.0

Kernel IP routing table
DestinationGateway  Genmask   Flags
Metric  RefUse Iface
192.168.12.1192.168.12.5255.255.255.255   UGH 0
 00 tun0
192.168.12.5  *   255.255.255.255UH
0 00 tun0
200.232.741.96   *  255.255.255.248 U
000 eth0
10.2.2.0   192.168.12.5   255.255.255.0UG   0
  00 tun0
192.168.12.0192.168.12.5   255.255.255.0UG   0
   00 tun0
10.1.1.0 *  255.255.255.0 U
 000 eth1
default200.232.741.970.0.0.0   UG
 000 eth0
=

Que puede estar faltando?  segun me parece, las tablas de enrutamiento
estan correctas (en ambos casos se indica que la puerta de enlace
hacia la otra red es la misma de la VPN).

Que me recomiendan revisar?

Gracias de antemano por su colaboracion

saludos


-- 
"Imagination is more important than knowlege"
A.E.
From [EMAIL PROTECTED]  Sun Feb 17 09:27:46 2008
From: [EMAIL PROTECTED] (Leonardo Soto M.)
Date: Sun Feb 17 09:37:55 2008
Subject: Base de datos MySQL... u otra?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

2008/2/16 Rodrigo Fuentealba <[EMAIL PROTECTED]>:
> El 16/02/08, Leonardo Soto M. <[EMAIL PROTECTED]> escribió:
> > 2008/2/15 Rodrigo Fuentealba <[EMAIL PROTECTED]>:
> > > El 15/02/08, Leonardo Soto M. <[EMAIL PROTECTED]> escribió:
> > > > Dudo *mucho* que el índice del buscador de google esté almacenado en un 
> > > > RDBMS.
>
> MySQL /no/ es un RDBMS.

No seas odioso. Ya leimos eso un montón de veces.

Pero (a) yo puse RDBMS para ahorrarme la lata de escribir "Base de
datos SQL o algo por el estilo" y (b) si es por ponerse pesados, según
los criterios del tío Edgard Codd
, PostgreSQL tampoco
califica como RDBMS. Ni Oracle, ni MSSQL, ni ninguna BD SQL usada en
la práctica. De donde se desprende que el 99% del tiempo, la gente usa
el término RDBMS en un sentido no demasiado estricto.

Pero la discusión teórica de lo que es o no es RDBMS no aporta
demasiado en este thread, IMO.

> Y no hablo del buscador (que siempre fue
> BigTable + GFS) sino del índice de servicios de Google.

Ah. De ahí la confusión entonces.

En cualquier caso, volviendo al tema original, ni Google, ni
Wikipedia, ni todos esos siti