[Решено] Хранение структурированных данных

[ql_Nik_lp]

Всем доброго времени суток.
В общем ситуация такая:
1) Надо хранить данные.
2) Сериализация / NBT - плохой вариант
3) Данные имеют глубокую структуру, хоть это не так, но для примера представим что надо хранить массив сетов хешмапов

До этого пользовался MySQL, но тут приходится создавать по 5-6 таблиц по 15+ колонок в каждой да бы сохранить одну структуру...
Как быть? Какие есть решения? За любые ответы буду благодарен c:

 

[D_ART]

Чем не нравится сериализация? Ещё можно использовать JSON, если всё это не подходит.

 

[ql_Nik_lp]

Чем не нравится сериализация? Ещё можно использовать JSON, если всё это не подходит.

Личная неприязнь, да и удаленный доступ нужен
На тему JSON'a вкладочки и так в браузере висят, но все таки хотелось бы базу данных т.е. какую нибудь более продвинутую альтернативу MySQL

 

[dark32]

Массив сетов хешмапов? что вы такое хотите хранить.
Подумайте над структурой, что-то не реалистично выглядит массив сетов хешмапов. А лучше предоставьте схематично пример структуры данных, на примере будет проще разобрать как хранить.

 

[ql_Nik_lp]

Массив сетов хешмапов? что вы такое хотите хранить.
Подумайте над структурой, что-то не реалистично выглядит массив сетов хешмапов. А лучше предоставьте схематично пример структуры данных, на примере будет проще разобрать как хранить.

Как-то так.
Количество Value несколько преуменьшено ввиду ограничения кол-ва элементов в одном проекте (Фри версия)
Под Value подразумевается любая переменная / объект (double, boolean, enum, location, своё, etc)
@fromgate @DPOH-VAR :C

 

[Reality_SC]

Я для большинства всего сейчас использую JSON, реально удобная тема.
Он, конечно, имеет некоторые ограничения, с теми же коллекциями, из-за Java Type Erasure, но я выкручиваюсь, используя массивы.

 

[ql_Nik_lp]

Я для большинства всего сейчас использую JSON, реально удобная тема.
Он, конечно, имеет некоторые ограничения, с теми же коллекциями, из-за Java Type Erasure, но я выкручиваюсь, используя массивы.

К данным требуется доступ из онлайна, так что файловые варианты отпадают

 

[Reality_SC]

JSON это не файл, а формат. Придуманный, кстати, для онлайнового использования JavaScript-ом.
Храни его себе в одной ячейке в мускуле, никто ж не запрещает.

Лично для меня удобство использования Google GSON и, как следствие, отсутствие необходимости в написани кода для сериализации и десериализации перекрывают большую часть недостатков этого метода.

 

[ptnk]

А что насчёт подключения ORM системы? Все таблички создаст за тебя, всё будет замечательно, будешь работать с объектами, как и раньше.

Есть такая замечательная штука в java - сериализация, любые объекты записываем в xml\json и выгружаем это дело в бд.

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


Просто множество вариаций.

Для показа структуры классов - есть диаграмма классов, для показа таблиц - есть ER-диаграммы. Ищем по запросу UML и просвящаемся.

 

[ql_Nik_lp]

А что насчёт подключения ORM системы? Все таблички создаст за тебя, всё будет замечательно, будешь работать с объектами, как и раньше.

Есть такая замечательная штука в java - сериализация, любые объекты записываем в xml\json и выгружаем это дело в бд.

Меня смущает в таком варианте что нельзя будет просто открыть табличку и поменять значение
Или я не прав?

А про ORM - не в курсе. Буду гуглить. Спасибо.

 

[ptnk]

Меня смущает в таком варианте что нельзя будет просто открыть табличку и поменять значение
Или я не прав?

А про ORM - не в курсе. Буду гуглить. Спасибо.

При сериализации в массив байт - не сможешь поменять, при сериалиации в xml/json - всё меняется.

 

[DPOH-VAR]

Всем доброго времени суток.
В общем ситуация такая:
1) Надо хранить данные.
2) Сериализация / NBT - плохой вариант
3) Данные имеют глубокую структуру, хоть это не так, но для примера представим что надо хранить массив сетов хешмапов

До этого пользовался MySQL, но тут приходится создавать по 5-6 таблиц по 15+ колонок в каждой да бы сохранить одну структуру...
Как быть? Какие есть решения? За любые ответы буду благодарен c:

Что конкретно нужно от механизма сохранения данных?

Если тип данных произвольный или очень сложный, то без сериализации не обойтись.
Сериализованный объект можно засунуть в MySQL как blob - но это извращение.
Лучше поднять службу типа http или ftp, и через нее проводить синхронизацию данных.

Не забывайте о snakeyaml.
https://code.google.com/p/snakeyaml/wiki/Documentation (отличная документация)
В отличии от JSON, он поддерживает перекрестные ссылки и его приятнее править вручную.

С использованием ORM выйдет те же 5-6 таблиц по 15+ колонок, да еще промежуточные таблицы для хранения связей. Но всё на автомате. И, конечно же, придется следить за транзакциями.

Нет способа взять и "расшарить" память для разных приложений на java, чтобы они видели объекты друг друга. Также нет возможности сделать это по сети. Все способы, эмулирующие такое поведение - используют сериализацию.

 

[kris13]

Механизм сериализации HashMap есть в java, вам осталось прописать сериализацию для ваших Object, которые в нем лежат и сериализацию вашего основного Object в котором лежит вся эта красота.
Онлайн доступ? RMI вам в помощь.

 

[ql_Nik_lp]

Всем большое спасибо за ответы.
Скорее всего либо буду таки городить таблицы, ибо данные обновляются часто и сериализация, как по мне займет много времени если сериализовать по несколько сотен объектов каждые несколько секунд, да и с учетом того что дело с BukkitAPI - некоторые вещи отправляются в базу из Sync потоков в то время как другие из Async... Так что похоже что все грустно.

 

[fromgate]

как по мне займет много времени если сериализовать по несколько сотен объектов каждые несколько секунд

Это ничего не говорит. Проверяйте такие сомнения. Считайте время выполнения конкретных методов. Я помнится был приятно удивлён, когда сам опасался обработки больших объемов данных.

 

[ptnk]

Всем большое спасибо за ответы.
Скорее всего либо буду таки городить таблицы, ибо данные обновляются часто и сериализация, как по мне займет много времени если сериализовать по несколько сотен объектов каждые несколько секунд, да и с учетом того что дело с BukkitAPI - некоторые вещи отправляются в базу из Sync потоков в то время как другие из Async... Так что похоже что все грустно.

1) Сериализация не занимает много времени.
2) А ты не делай сериализацию каждые несколько секунд, а сериализируй то, что только изменяется в конкретный момент.

 

[kris13]

Хм, а вы уверенны, что все делаете правильно, в смысле вы уверенны, что данные надо так часто где-то сохранять, а не хранить в программе? И да, поддерживаю ptnk и fromgate, сериализация не занимает прямо уж так много времени, что бы ее боятся. Банковские приложения(те которые на java) успешно используют сериализацию и уже упомянутый RMI.

 

[ql_Nik_lp]

Сохранение определенных значений у меня происходит каждые 10 секунд
Других - каждую секунду.

2) А ты не делай сериализацию каждые несколько секунд, а сериализируй то, что только изменяется в конкретный момент.

Это даст прирост производительности по сравнению с кучей таблиц?

 

[ptnk]

Сохранение определенных значений у меня происходит каждые 10 секунд
Других - каждую секунду.

Это даст прирост производительности по сравнению с кучей таблиц?

Это может дать и не дать прироста производительности, всё зависит от данных и их объёмов.
Мы не знаем какие данные ты собираешься хранить, в каком объёме. Может быть вообще данные не требуется каждые 10 секунд обновлять в бд, а может быть из-за необходимой синхронизации между серверами будут какие-то общие данные для которых сериализация объекта просто не подойдёт, ну или просто структура данных будет плохой для сериализации (что-то вынести в другое место).

Для каждой конкретной ситуации нужно думать и оптимизировать.

Увидил, что Bukkit из коробки поддерживает ORM, что уже просто восхительно и не требует таскать с собой множество лишних библиотек.

Все механизмы по хранению данных интересны и могут быть использоваться совместно для обеспечения лучшего результата.

 

[ql_Nik_lp]

Это может дать и не дать прироста производительности, всё зависит от данных и их объёмов.
Мы не знаем какие данные ты собираешься хранить, в каком объёме. Может быть вообще данные не требуется каждые 10 секунд обновлять в бд, а может быть из-за необходимой синхронизации между серверами будут какие-то общие данные для которых сериализация объекта просто не подойдёт, ну или просто структура данных будет плохой для сериализации (что-то вынести в другое место).

Для каждой конкретной ситуации нужно думать и оптимизировать.

Увидил, что Bukkit из коробки поддерживает ORM, что уже просто восхительно и не требует таскать с собой множество лишних библиотек.

Все механизмы по хранению данных интересны и могут быть использоваться совместно для обеспечения лучшего результата.

В общем покурил Вики, покурил баккит вики - это действительно то что нужно. Спасибо.