At 20:02 27/03/2012, Emanuel Calvo wrote:
>> si dices "Fractal tree indexes" yo pienso en algún tipo de índice pero
>> innodb no es un tipo de índice sino un tipo de almacenamiento.
>>
>> [... googleando al respecto ...]
>>
>> http://en.wikipedia.org/wiki/TokuDB
>>
>> TokuDB es un tipo de almacenamiento al igual que InnoDB que implementa
>> "Fractal tree indexes" en lugar de b-tree
>
> Creo que este tipo de artículo sería más útil para evaluar fractal tree
> como reemplazo de btrees:
>
> http://en.oreilly.com/mysql2010/public/schedule/detail/13265
>
> Se ve interesante, pero obviamente hace falta un nivel de detalle mucho
> mayor para poder implementarlo. Â En todo caso me imagino que el fractal
> tree sería solamente un nuevo tipo de "access method"; a diferencia de
> mysql no hace falta un fork de Postgres para implementarlo ... ah, la
> extensibilidad ...!
>

Aún así los b-tree si caben en memoria, siguen dando mejores resultados. Por lo
que en sistemas con bastante memoria y datos que quepan en ella,
conviene InnoDB.

Por la descripcion son trees mas rapidos cuando el medio en el que los tienes guardados tiene una velocidad de acceso (lectura y escritura) secuencial mas rapida que la aleatoria. Esto tiene sentido si la estructura esta en un disco duro convencional pero pierde sentido si las velocidades de acceso son iguales en ambos casos, como en las SSD.

Por las descripciones de los algoritmos parece que lo que hacen es reordenar la forma en que se almacena el btree en el disco para aprovechar al maximo el acceso secuencial

Está en inglés, pero esta talk es muy buena (min ~14/16) escucharán a un alumno
preguntando respecto de eso y su respuesta [1]



[1] http://www.youtube.com/watch?v=dLFgJvVrzJ0


-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Responder a