FAL Labs tiene múltiples productos Tokio y Kioto productos:¿Cuál es la diferencia entre el gabinete de Tokio y el gabinete de Kioto?
Puede alguien explicar la diferencia entre los productos de Tokio y Kioto?
Tokyo Cabinet and Tyrant son LGPL y están escritos en C. Kyoto Cabinet y Tycoon son GPLv3 y están escritos en C++.
Kyoto Tyrant admite registros caducados en la memoria, por lo que puede reemplazar a memcached.
El desarrollador dice que Kyoto * no es el sucesor de Tokio *, pero es solo una estrategia de marketing; si no va a desarrollar un producto comercial, use Kyoto. Es nuevo y mejor
Y le sugiero que lea el blog del desarrollador (tanto en japonés como en inglés) y lea los archivos del encabezado con cuidado (si va a utilizar la biblioteca).
Buena suerte.
Tokyo Cabinet es más completo y estable, Kyoto todavía está muy fresco (hoy es 8 de diciembre de 2010) y tiene algunos problemas. Kioto, escrito en C++, es (mucho) más simple que Tokio (escrito en C), pero esta simplicidad deja algo de espacio. El rendimiento de Kioto es un poco peor que el de Tokio, pero funciona mejor con hilos (al menos la documentación lo promete).
De la documentación oficial:
< < En 2007, Tokio Gabinete fue desarrollado como el sucesor de qdbm en los siguientes propósitos. Se lograron y Tokyo Cabinet podría reemplazar los productos convencionales de DBM.
(...)
En 2009, el Gabinete de Kyoto fue desarrollado como otro sucesor qdbm. Comparado con el producto hermano (Tokyo Cabinet), se persiguieron las siguientes ventajas. Sin embargo, el rendimiento de Tokyo Cabinet es más alto que el de Kyoto Cabinet, al menos en operaciones de un solo hilo. >>
Usé ambos, pero aún prefiero Tokio, porque tuve un problema con Kyoto: In Kyoto Cabinet Database using File Hash Database, how can avoid file size increasing? y nadie pudo ayudarme. Todavía no sé cómo resolver eso.
En mi experiencia personal, encontré que Kioto es más fácil de compilar e instalar, y también más fácil de usar. Tenía grandes problemas con las dependencias de la biblioteca de Tokio y problemas para vincular la biblioteca nativa con la interfaz de Java. Con Kyoto, todo estuvo bien y funciona bien en el primer intento. Pero, como dije antes, siento más control sobre la base de datos usando Tokio.
Hola. ¿Qué otras cuestiones de Kioto has enfrentado? – Jeff
¿Puede informarme si Tokyo Cabinet admite la implementación B + Tree en memoria y cómo lograr eso? Porque en algún artículo web que encontré, es compatible pero no puede encontrar ningún documento que indique cómo hacerlo. Lo sentimos, por preguntar de esta manera, pero no podemos encontrar ningún usuario experimentado de Tokio que nos ayude a resolver este problema. – Arpssss
¿Qué tal ahora? ¿Todavía encuentras a Tokio más establecido que Kioto? – amertkara
La diferencia más importante entre los dos con respecto a mis casos de uso es que TC tiene una "base de datos de tablas", mientras que KC no.
Sí, puede serializar datos arbitrarios para encadenarlos y almacenarlos como valor de elemento, pero no puede buscar por valor o iterar sobre todo el conjunto de datos y deserializar cada elemento, o reinventar la rueda y manualmente indexar los datos.
La TDB del Tokyo Cabinet ofrece excelentes capacidades de consulta para datos anidados (índices, comparación numérica y de cadenas, incluso expresiones regulares dentro de "campos"). Lo de Kyoto es solo una tienda de KV; TC también es una poderosa base de datos orientada a documentos.
Además, de acuerdo con la prueba de lo que hice, el protocolo de Kyoto solo está basado en HTTP - más abierto, pero más lento que el protocolo binario de la cosa de Tokio.
KyotoTycoon está basado en HTTP: no Kyoto. – MechanTOurS
Claro. "Kyoto" no significa nada. El producto se llama Kyoto Cabinet (lib) y Kyoto Tycoon (servidor) – Nick
[Kyoto Tycoon * solo * tiene un complemento que expone un servidor memcached] (http://fallabs.com/mikio/tech-en/promenade.cgi?id=20). Tokyo Tyrant tiene la misma función menos vencimiento de clave. – Tobu