Open moon155 opened 6 years ago
Search engines optimized for search:
Conoceis alguno de los dos?! Probado? Mroonga aún esta siendo mantenido y parece ser adaptado si nos fiamos de la descripción, no? Aunque tiene limitaciones gordas: http://mroonga.org/docs/reference/limitations.html Excede lo de Kaos esto?
no las conozco, pero miraré...
El 20/01/18 a las 16:12, moon155 escribió:
Search engines optimized for search:
- SphinxSE is used as a proxy to run statements on a remote Sphinx database server (mainly useful for advanced fulltext searches).
- Mroonga provides fast CJK-ready full text searching using column store.
Conoceis alguno de los dos?! Probado?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ingobernable/kaos155/issues/32#issuecomment-359178127, or mute the thread https://github.com/notifications/unsubscribe-auth/AYTEACP9F2sCenqc5R25WB7eIHL9Q2WBks5tMgJCgaJpZM4RleAC.
en principio no excede, (mas líos de instalación :( )
Mroonga tiene buen pinta, ahora ..... ¿como se instala eso? sudores frios me dan
haciendo pruebas con el scrap en marcha, y leido el articulo https://mariadb.com/kb/en/library/choosing-the-right-storage-engine/ desde luego gana MyISAM para la DB de TEXT
Ni idea sobre como instalar Mroonga... pero creo que tendremos que probarlos todos (los engines), uno por uno, no?
Dices que gana MyISAM porque has podido probar más cosas? (cuales?)
Ahí dicen que "First major difference I see is that InnoDB implements row-level lock while MyISAM can do only a table-level lock.".. no debería ser InnoDB mejor entonces? Yo probé un combo TokuDB/InnoDB pero aunque iba super rápido, cada día se corrompía el servidor de BBDD entero. A lo mejor tendría que probar sin mezclar ambos engines en la misma tabla (usar solo uno por tabla). https://dba.stackexchange.com/questions/1/what-are-the-main-differences-between-innodb-and-myisam
Este, "ColumnStore", no parece muy malo tampoco! https://www.percona.com/blog/2017/01/30/mariadb-columnstore/ https://logicalread.com/sql-server-columnstore-index-w02/
Y esta MonetDB, también un "column-based storage", que parece sobrepasar y de mucho ColumnStore según esta prueba: https://reportserver.net/blog/2016/06/20/mariadb-columnstore-vs-innodb-vs-monetdb/
A lo mejor me lanzo con uno de los dos, creo que es pertinente el column-based storage para precalcular cualquier atributo "actual" de las entidades (empresas). Tipo, para sacar todas las empresas de Barcelona digamos, solo accedería una página del index (una columna), por lo que nos permitiría crear tablas de entidades con muuuuchas columnas (con los valores actuales, de capital, de ubicación, cualquier valor precalculable), y filtrar por ellas sin problema, entiendo. Eso puede permitir generar resultados con muchos datos agregados me parece. Pero todavía no lo tengo 100% claro porque hay bastantes operaciones (JOINs) cuando uno busca algo en la bbdd.. (ubicación, tipo, nombre (FULL_TEXT, claro, que tal vez no puede ser column-based)
Alguien puede desarrollar/confirmar esta teoría?
parece ser que cuando los index son de longitud Fija gana MyISAM a InnoDB, yo he vuelto un paso atrás, pues el PARSER del borme con las tablas del texto a MyISAM a poco le da un telele lo despacio que van, asi que parece por ahora que tablas con un motor tablas con el otro, otros no he probado, tampoco quiero perder la compatibilidad con mysql
Todos los engines que he citado aquí usan MySQL. O sea, para la app es bastante transparente a que engine se esta conectando, ella solo tiene que seguir los indicios. Y me parecía que la velocidad de búsqueda era un problema para kaos.. pero me equivocaré.
Aquí un enlace interesante! https://mariadb.com/kb/en/library/choosing-the-right-storage-engine/
Que usa Kaos?
Aconsejo una mezcla de InnoDB para FULL_TEXT (o XtraDB??) y TokuDB con indices de tipo HASH (no BTREE) para columnas de tamaño fijo o búsqueda desde principio de cadenas.