LINUX.ORG.RU
Форум — Development  

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

 , , ,


0

2

Есть большой объем однообразных данных (500 гб). Все данные можно разделить на отдельные блоки (допустим, по 1 гб). Хотелось бы как-то удобно и быстро вгружать несколько блоков данных прямо в оперативную память для дальнейшей обработки.

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

Может уже есть какие-то готовые либы/технологии для этого? Подскажите в какую сторону копать.

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

Спасибо.

★★★

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

anonymous
()

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

500 гб

рукалицо

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

slyjoeh ★★★
()

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

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

pon4ik ★★★★★
()

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

protocol buffers

maloi ★★★★★
()
Ответ на: комментарий от anonymous

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

maloi ★★★★★
()

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

Valor ★
()

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

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/

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

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

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

mashina ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

mashina ★★★★★
()

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

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

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

MKuznetsov ★★★★★
()

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

Iron_Bug ★★★★★
()

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

observer ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development