Re: Fractal tree indexes para PostgreSQL

¿Alguien sabe si hay algún desarrollo en vista para incorporar
"Fractal tree indexes" a PostgreSQL y en qué etapa está ?

Los desarrolladores de Tokutek, dicen que son en MySQL un reemplazo de
InnoDB, que le parmite escalar de GB a TB, mejorando la velocidad de
inserción, consulta, compresión, etc. conservando el estándar SQL y
soportando ACID y MVCC.

Aducen que la mejora en performance es de 20 a 80x comparado con InnoDB.

http://www.tokutek.com/

http://www.pythian.com/news/5139/testing-tokudb-faster-and-smaller-for-large-tables/

Gracias por anticipado.

--
Guillermo O. Burastero

Bahía Blanca, Buenos Aires, Argentina
Tel. +54 (291) 454-6132 - Móvil [15] 574-3173

MSN: guillermo(dot)burastero(at)gmail(dot)com
ICQ: 97148268
Usuario GNU/Linux #84879 - https://linuxcounter.net/user/84879.html

2012/3/27 Guillermo O. Burastero <linux(dot)gb(at)gmail(dot)com>:
> ¿Alguien sabe si hay algún desarrollo en vista para incorporar
> "Fractal tree indexes" a PostgreSQL y en qué etapa está ?
>

NPI

>
> Los desarrolladores de Tokutek, dicen que son en MySQL un reemplazo de
> InnoDB,

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

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

El día 27 de marzo de 2012 16:20, Jaime Casanova
<jaime(at)2ndquadrant(dot)com> escribió:
> 2012/3/27 Guillermo O. Burastero <linux(dot)gb(at)gmail(dot)com>:
>> ¿Alguien sabe si hay algún desarrollo en vista para incorporar
>> "Fractal tree indexes" a PostgreSQL y en qué etapa está ?
>>
>
> NPI
>
>>
>> Los desarrolladores de Tokutek, dicen que son en MySQL un reemplazo de
>> InnoDB,
>
> 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
>
> --

TokuDB es un fork de Mysql con un storage engine que utiliza Fractal Indexing.
En el link que postean algunas estadísticas veo algunas inconsistencias, por lo
que preguntaré a la gente que trabaja conmigo si han visto
experiencias al respecto.

--
--
                        Emanuel Calvo
                         Helpame.com
Curso Postgres 9.1 Nivel 1 Info (at) helpame (dot) com

El día 27 de marzo de 2012 16:27, Emanuel Calvo
<postgres(dot)arg(at)gmail(dot)com> escribió:
> El día 27 de marzo de 2012 16:20, Jaime Casanova
> <jaime(at)2ndquadrant(dot)com> escribió:
>> 2012/3/27 Guillermo O. Burastero <linux(dot)gb(at)gmail(dot)com>:
>>> ¿Alguien sabe si hay algún desarrollo en vista para incorporar
>>> "Fractal tree indexes" a PostgreSQL y en qué etapa está ?
>>>
>>
>> NPI
>>
>>>
>>> Los desarrolladores de Tokutek, dicen que son en MySQL un reemplazo de
>>> InnoDB,
>>
>> 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
>>
>> --
>
> TokuDB es un fork de Mysql con un storage engine que utiliza Fractal Indexing.
> En el link que postean algunas estadísticas veo algunas inconsistencias, por lo
> que preguntaré a la gente que trabaja conmigo si han visto
> experiencias al respecto.
>
>

Ese artículo es bastante viejo. En el equipo ya hubo gente que ha
hecho sus benchmark, veré
si están dispuestos a publicarlos.

--
--
                        Emanuel Calvo
                         Helpame.com
Curso Postgres 9.1 Nivel 1 Info (at) helpame (dot) com

Excerpts from Jaime Casanova's message of mar mar 27 11:20:23 -0300 2012:
> 2012/3/27 Guillermo O. Burastero <linux(dot)gb(at)gmail(dot)com>:

> 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 ...!

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

>> 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.

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

--
--
Emanuel Calvo

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

Excerpts from Eduardo Morras's message of mié mar 28 05:33:23 -0300 2012:
> At 20:02 27/03/2012, Emanuel Calvo wrote:

> >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.

No creo que sea tan simple, porque precisamente uno de las breves
introducciones que leí decía que la mejora de rendimiento existía tanto
en discos rotatorios como en SSD. Debe haber alguna otra diferencia que
explique esto.

> 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

Eso sería totalmente inútil en un sistema como Postgres, porque cada
archivo (índice, tabla) crece una página por vez, y por lo tanto el
sistema operativo podría poner cada siguiente página de un índice en una
posición completamente distinta de la página anterior. Acá también
sospecho que la diferencia entre fractal tree y btree debe ser más
compleja que lo que tú dices.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

At 15:32 28/03/2012, Alvaro Herrera wrote:

>Excerpts from Eduardo Morras's message of mié mar 28 05:33:23 -0300 2012:
> > At 20:02 27/03/2012, Emanuel Calvo wrote:
>
> > >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.
>
>No creo que sea tan simple, porque precisamente uno de las breves
>introducciones que leí decía que la mejora de rendimiento existía tanto
>en discos rotatorios como en SSD. Debe haber alguna otra diferencia que
>explique esto.

He encontrado documentacion sobre fractal trees,
te pongo el enlace, yo lo pongo en mi pila de documentacion para leer

http://www.pittsburgh.intel-research.net/people/gibbons/papers/fpbptrees.pdf

El documento es del año 2002 y se puede encontrar
en mas sitios como en citeseerx donde ademas te
ponen que otra documentacion similar se cita en esta o en cual esta citada.

Un saludo y buena lectura L