serialización de alto rendimiento: Java vs Protocolo de Google Buffers vs ...?

Question

Para algo de caché que estoy pensando hacer para un próximo proyecto, he estado pensando en la serialización de Java. A saber, ¿debería ser utilizado?

Ahora he escrito previamente serialización personalizada y deserialización (Externalizable) por varias razones en años pasados. En estos días, la interoperabilidad se ha convertido en un problema aún mayor y puedo prever la necesidad de interactuar con las aplicaciones .Net, así que he pensado en utilizar una solución independiente de la plataforma.

¿Alguien ha tenido alguna experiencia con el uso de alto rendimiento de GPB? ¿Cómo se compara en términos de velocidad y eficiencia con la serialización nativa de Java? Alternativamente, ¿hay algún otro esquema que valga la pena considerar?

Answer 1

No he comparado los Buffers de Protocolo con la serialización nativa de Java en términos de velocidad, pero para la interoperabilidad la serialización nativa de Java es un serio no-no. Tampoco va a ser tan eficiente en términos de espacio como Buffers de Protocolo en la mayoría de los casos. Por supuesto, es algo más flexible en términos de lo que puede almacenar, y en términos de referencias, etc. Protocol Buffers es muy bueno para lo que está destinado, y cuando se adapta a tus necesidades es genial, pero hay restricciones obvias debido a la interoperabilidad (Y otras cosas).

Recientemente publiqué un marco de benchmarking Protocol Buffers en Java y .NET. La versión de Java se encuentra en el main Google project (en el), la versión de .NET está en my C# port project. Si desea comparar la velocidad de PB con la velocidad de serialización de Java, puede escribir clases similares y compararlas. Sin embargo, si está interesado en la interoperabilidad, realmente no le daría un segundo pensamiento a la serialización Java nativa (o serialización binaria nativa .NET).

Hay otras opciones para la serialización interoperable, además de Protocol Buffers, aunque - Thrift, JSON y YAML me vienen a la mente, y sin duda hay otras.

EDITAR: De acuerdo, con la interoperabilidad no es tan importante, vale la pena tratar de enumerar las diferentes cualidades que desea de un marco de serialización. Una cosa que debes pensar es el control de versiones: esta es otra cosa que PB está diseñada para manejar bien, tanto hacia atrás como hacia delante (para que el nuevo software pueda leer datos antiguos y viceversa), cuando te apegas a las reglas sugeridas, por supuesto :)

Después de haber tratado de ser cauteloso sobre el rendimiento de Java frente a la serialización nativa, realmente no me sorprendería encontrar que PB era más rápido de todos modos. Si tiene la oportunidad, use el servidor vm: mis evaluaciones recientes mostraron que la máquina virtual del servidor es más del doble de al serializar y deserializar los datos de muestra. Creo que el código PB se adapta muy bien al JIT de la VM del servidor :)

Al igual que las cifras de rendimiento de la muestra, serializando y deserializando dos mensajes (uno 228 bytes, uno 84750 bytes) obtuve estos resultados en mi computadora portátil usando el servidor VM:

 
Benchmarking benchmarks.GoogleSize$SizeMessage1 with file google_message1.dat 
Serialize to byte string: 2581851 iterations in 30.16s; 18.613789MB/s 
Serialize to byte array: 2583547 iterations in 29.842s; 18.824497MB/s 
Serialize to memory stream: 2210320 iterations in 30.125s; 15.953759MB/s 
Deserialize from byte string: 3356517 iterations in 30.088s; 24.256632MB/s 
Deserialize from byte array: 3356517 iterations in 29.958s; 24.361889MB/s 
Deserialize from memory stream: 2618821 iterations in 29.821s; 19.094952MB/s 

Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file google_message1.dat 
Serialize to byte string: 17068518 iterations in 29.978s; 123.802124MB/s 
Serialize to byte array: 17520066 iterations in 30.043s; 126.802376MB/s 
Serialize to memory stream: 7736665 iterations in 30.076s; 55.93307MB/s 
Deserialize from byte string: 16123669 iterations in 30.073s; 116.57947MB/s 
Deserialize from byte array: 16082453 iterations in 30.109s; 116.14243MB/s 
Deserialize from memory stream: 7496968 iterations in 30.03s; 54.283176MB/s 

Benchmarking benchmarks.GoogleSize$SizeMessage2 with file google_message2.dat 
Serialize to byte string: 6266 iterations in 30.034s; 16.826494MB/s 
Serialize to byte array: 6246 iterations in 30.027s; 16.776697MB/s 
Serialize to memory stream: 6042 iterations in 29.916s; 16.288969MB/s 
Deserialize from byte string: 4675 iterations in 29.819s; 12.644595MB/s 
Deserialize from byte array: 4694 iterations in 30.093s; 12.580387MB/s 
Deserialize from memory stream: 4544 iterations in 29.579s; 12.389998MB/s 

Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file google_message2.dat 
Serialize to byte string: 39562 iterations in 30.055s; 106.16416MB/s 
Serialize to byte array: 39715 iterations in 30.178s; 106.14035MB/s 
Serialize to memory stream: 34161 iterations in 30.032s; 91.74085MB/s 
Deserialize from byte string: 36934 iterations in 29.794s; 99.98019MB/s 
Deserialize from byte array: 37191 iterations in 29.915s; 100.26867MB/s 
Deserialize from memory stream: 36237 iterations in 29.846s; 97.92251MB/s 

la "velocidad" vs "tamaño" es si el código generado está optimizado para la velocidad o el tamaño del código. (Los datos serializados son los mismos en ambos casos. La versión de "tamaño" se proporciona para el caso en que tiene muchos mensajes definidos y no quiere tomar mucha memoria para el código.)

Como puede ver, para el mensaje más pequeño puede ser muy muy rápido - más de 500 mensajes pequeños serializados o deserializados por milisegundo. Incluso con el mensaje 87K tarda menos de milisegundos por mensaje.

Answer 2

¿Qué quiere decir con alto rendimiento? Si desea una serialización milli-second, le sugiero que use el enfoque de serialización que es el más simple. Si quiere menos de milisegundos, es probable que necesite un formato binario. Si desea mucho menos de 10 microsegundos, es probable que necesite una serialización personalizada.

No he visto muchos puntos de referencia para la serialización/deserialización, pero pocos soportan menos de 200 microsegundos para la serialización/deserialización.

Los formatos independientes de plataforma tienen un costo (en esfuerzo por su parte y latencia) puede que tenga que decidir si desea rendimiento o independencia de la plataforma. Sin embargo, no hay ninguna razón por la que no pueda tener ambos como una opción de configuración a la que cambie según sea necesario.

Answer 3

Aquí está la sugerencia de la pared del día :-) (que acaba pellizcó algo en mi cabeza que ahora quiero probar) ...

Si usted puede ir para toda la solución de almacenamiento en caché a través de este podría funcionar: Project Darkstar. Está diseñado como un servidor de juegos de muy alto rendimiento, específicamente para que las lecturas sean rápidas (tan buenas para un caché). Tiene API Java y C, así que creo (creo que ha pasado mucho tiempo desde que lo vi, y no pensaba en esto entonces) que puedes guardar objetos con Java y leerlos en C y viceversa.

Por lo menos él se puede dar algo para leer en la actualidad :-)

Answer 4

Si está confundiendo entre PB & serialización de Java nativa en la velocidad y la eficiencia, ir a por PB.

• PB fue diseñado para lograr tales factores. Ver http://code.google.com/apis/protocolbuffers/docs/overview.html
• Los datos de PB son muy pequeños, mientras que la serialización de Java tiende a replicar un objeto completo, incluida su firma. ¿Por qué siempre obtengo mi nombre de clase, mi nombre de campo ... serializado, a pesar de que lo sé al revés en el receptor?
• Piense en el desarrollo del lenguaje. Se está poniendo duro si un lado usa Java, un lado usa C++ ...

Algunos desarrolladores sugieren Thrift, pero yo usaría Google PB porque "Creo en Google" :-) .. De todos modos, vale la pena un vistazo: punto http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers

Answer 5

Uno más datos: este proyecto:

http://code.google.com/p/thrift-protobuf-compare/

da una idea del rendimiento esperado para objetos pequeños, incluyendo la serialización de Java en PB.

Los resultados varían mucho según la plataforma, pero hay algunas tendencias generales.

Answer 6

También puede consultar FST, un reemplazo directo para la serialización JDK incorporada que debería ser más rápida y tener una salida más pequeña.

estimaciones crudas en la evaluación comparativa frecuente que he hecho en los últimos años:

100% = binarios enfoques basados ​​/ struct (por ejemplo,SBE, FST-estructuras)

• inconvenientes
• postprocesado (acumulación obejcts "reales" en el lado del receptor) puede comer hasta ventajas de rendimiento y nunca se incluye en los puntos de referencia

~ 10% -35 % protobuf & Derivados de

~ 10% -30% serializadores rápidas como FST y Kryo

• objetos convenientemente deserializados se pueden utilizar más a menudo directamente sin código de traducción manual adicional.
• puede Pimped para el rendimiento (anotaciones, registro clase)
• preservar enlaces en el gráfico objeto (sin objeto serializado dos veces)
• puede manejar estructuras cíclicas
• solución genérica, FST es totalmente compatible con JDK serialización

~ 2% -15% JDK serialización

~ 1% -15% JSON rápido (por ejemplo, Jackson)

• no puede manejar cualquier gráfico de objetos, pero sólo un pequeño subconjunto de las estructuras de datos Java
• no ref restaurar

0.001-1% lleno gráfico JSON/XML (por ejemplo, JSON.io)

Estos números tienen el propósito de dar una impresión muy áspera orden de magnitud. Tenga en cuenta que el rendimiento depende MUCHO de las estructuras de datos que se serializan/comparan. Por lo tanto, los puntos de referencia simples de clase simple son en su mayoría inútiles (pero populares: por ejemplo, ignorar unicode, sin colecciones, ...).

ver también

http://java-is-the-new-c.blogspot.de/2014/12/a-persistent-keyvalue-server-in-40.html

http://java-is-the-new-c.blogspot.de/2013/10/still-using-externalizable-to-get.html

Answer 7

para la serialización de alambre de usar, considere el uso de la interfaz Externalizable. Utilizado inteligentemente, tendrá un conocimiento íntimo para decidir cómo gestionar de forma óptima y eliminar campos específicos. Dicho esto, tendrá que gestionar el control de versiones de cada objeto correctamente - fácil de ONU-ordenar, sino formación de trenes un objeto V2 cuando el código es compatible con V1 o bien la rotura, perder información o datos corruptos peor de una manera sus aplicaciones no pueden procesar correctamente Si está buscando un camino óptimo, tenga cuidado, ninguna biblioteca resolverá su problema sin algunos compromisos. En general, las bibliotecas se adaptarán a la mayoría de los casos de uso y contarán con el beneficio adicional de que se adaptarán y mejorarán con el tiempo sin su aporte, si ha optado por un proyecto de código abierto activo. ¡Y pueden agregar problemas de rendimiento, introducir errores e incluso corregir errores que aún no te han afectado!