Сериализация с архивацией

Структура данных?

большой объем однообразных данных

500 гб

рукалицо

Попробуй hadoop или spark. Хотя объем данных слишком маленький, и скорее всего выигрыша не будет.

звучит как memory mapping.

Если упаковку/распаковку делать ленивую, то вполне прокатит для cpp, для java - не в теме я чего там как.

1. Какой-то универсальный механизм с поддержкой многих языков программирования. Хотя бы для C++ и Java.

protocol buffers

protocol buffers

не умеет больше 64 мегов в 1 мессадж.

1. это можно обойти
2. а кто говорит, что надо 1 ГБ писать одним мессаджем?

Загоняй все в монгу, самый верный вариант

Не говноплюсы конечно, но у них есть жабовский интерфейс к:

AllegroGraph® is a modern, high-performance, persistent graph database. AllegroGraph uses efficient memory utilization in combination with disk-based storage, enabling it to scale to billions of quads while maintaining superior performance. AllegroGraph supports SPARQL, RDFS++, and Prolog reasoning from numerous client applications.

http://franz.com/agraph/allegrograph/

не умеет больше 64 мегов в 1 мессадж.

Умеет, но протобуф гогнецо для таких задач, лучше делать свои велосипеды.

не умеет. Чтоб умел нужно пересобрать и с собой это таскать. 3 может быть умеет.

гогно. лучше тогда уж монгоДБ.

Чтоб умел нужно пересобрать и с собой это таскать.

т.е. документация врет? https://developers.google.com/protocol-buffers/docs/reference/cpp/google.prot...

не умеет. Чтоб умел нужно пересобрать и с собой это таскать. 3 может быть умеет.

Умеет второй и без перекомпиляции. Но 1Гб всё равно не осилит.

Раньше все это работало через БД Postgresql. Эффективность сильно низкая. На select-ах теряется много времени. Индексы есть.

эээ..в job привести схему и реквестировать спеца?

ps/ «эффективность» настолько расплывчатое слово, что полностью ангажированно менеджерами и прочими маркетолагами.

быстро и удобно одновременно обычно не бывает. практика показывает, что те, кто работает с действительно большими объёмами данных, не юзают RDBMS и даже NoSQL не юзают, а пишут свои велосипеды на С/С++. если файлы уже на машине, на которой работает софт, я бы просто в С++ мапила файлы на память для работы. это самая быстрая работа с данными. работала так с многогигабайтными изображениями (нужна была векторная обработка больших сканов), вроде вполне прилично выходило. а через базы как ни крути, но будет медленно и печально.

Всем спасибо за советы.