Библиотека сериализации Kryo: используется ли она в производстве?

я постараюсь ответить на свой вопрос (Kyro все еще очень новый!).

у нас есть набор около 120 различных веб-сервисов, реализованных с помощью основы Restlet. Они поедаются клиентов веб-служб, как правило, построена на вершине Restlet-клиент библиотека. Представления, отправляемые между сервером и клиентом, включают XML (используя библиотека сериализации XStream), JSON (используя Джексон), XHTML,Java Сериализация Объектов, а со вчерашнего дня,Kryo. Таким образом, мы в состоянии сделать некоторые надежные параллельные сравнения.

Kryo 1.0.1 кажется достаточно стабильной. Как только я прочитал о том, как использовать API, единственной реальной проблемой, которую я нашел, была java по умолчанию.утиль.Сериализатор дат, казалось, исказил даты на несколько месяцев в прошлое. Я просто должен был предоставить свое собственное переопределение:

kryo.register(Date.class, 
  new SimpleSerializer<Date>() {
   @Override public void write (ByteBuffer b, Date d) { b.putLong(d.getTime()); }
   @Override public Date read (ByteBuffer b) { return new Date(b.getLong()); }
  });

но это была единственная возможная проблема, которую я нашел до сих пор. Мы имейте набор JavaBeans, которые имеют строковые, Float, целочисленные, длинные, даты, логические и список полей.

вот некоторые приблизительные ориентиры. Во-первых, я сделал 100 000 сериализации и десериализации иерархии объектов, которая описывает одну телевизионную программу (т. е. сделал 100 000 глубоких копий). Скорость была:

XStream XML:                 360/sec
Java Object Serialization: 1,570/sec
Jackson JSON:              5,000/sec
Kryo:                      8,100/sec

далее, я также сериализовал каталог 2,000 описаний телевизионных программ и подсчитал байты:

XStream XML:         6,837,851 bytes
Jackson JSON:        3,656,654 bytes
Kryo:                1,124,048 bytes

Я также обнаружил, что регистрация сериализаторов была очень важно:

kryo.register(List.class);
kryo.register(ArrayList.class);
// ...
kryo.register(Program.class);
kryo.register(Catalog.class);
// ...

если бы я этого не сделал, сериализации были почти вдвое больше, и скорость была, возможно, на 40% медленнее.

мы также провели полные сквозные тесты нескольких веб-сервисов, используя каждый из этих четырех методов сериализации, и они также показали, что Kryo работает быстрее, чем другие.

так в резюме, Kryo кажется достаточно прочным. Я буду поддерживать его в нашей базе кода, и когда мы получим опыт работы с ним, я надеюсь используйте его в других местах. Слава команде крио!

обновление (3/9/2011): я, наконец, добрался до предложения @StaxMan попробовать бинарный сериализатор "улыбка" Джексона 1.6. Используя Jackson 1.6 и Kryo 1.04, я сделал 100 000 глубоких копий (сериализация / десериализация) несколько иной иерархии объектов телевизионной программы:

XStream XML:     429/sec    5,189 bytes
Jackson JSON:  4,474/sec    2,657 bytes
Kryo:          4,539/sec    1,066 bytes  
Jackson Smile: 5,040/sec    1,689 bytes

этот тест не сочетался с тестом макроуровня, где я пробовал разные сериализаторы в веб-службе REST, которая предоставляет многие из подобные объекты. Там общая пропускная способность системы поддерживает интуицию @StaxMan о производительности:

Jackson JSON:     92 requests/sec
Jackson Smile     97 requests/sec
Kryo:            108 requests/sec

Kryo является частью проекта S4 Yahoo (простая масштабируемая потоковая система). S4 еще не производство, насколько я знаю.

с помощью Джим Ferrans ответы и комментарии выше я нашел более подробное объяснение о проблеме сериализации даты с Kryo на этой странице:http://groups.google.com/group/kryo-users/browse_thread/thread/91969c6f48a45bdf/ а также как использовать DateSerializer () Kryo:

kryo.Регистрация(дата.class, new DateSerializer ());

Я надеюсь, что это может помочь другим.

последняя версия Kryo имеет несколько условий гонки в некоторых экстремальных случаях, работает на интерфейсе симулятора для ns-3 С Java. Может попросить разработчика зафиксировать некоторые из моих изменений, если они свободны от проблем.

в Apache Storm использует его для сериализация перед передачей сообщений от одной задачи к другой.

Так что да, он должен быть довольно стабильным, так как Storm используется несколько крупных компаний, т. е. Twitter и Spotify.

сайт Kryo имеет раздел на проекты в производстве с использованием Kryo

Kryo 2.x также использован мулом ESB, и настолько широко использован в продукции.

обновление 2017:

Kryo используется Flink. Поэтому практически все, что использует Flink framework, полагается на Kryo. Ссылка: https://ci.apache.org/projects/flink/flink-docs-release-0.8/programming_guide.html#specifying-keys