Каков наиболее эффективный способ хранения больших массивов (10000x100) в базе данных, скажем, hsqldb? Мне нужно сделать это для определенной математической программы, которую я пишу на java. Пожалуйста помоги. Будет часто извлекаться и сохраняться весь массив (не столько отдельные элементы). Кроме того, некоторые метаданные о массиве должны храниться о массиве.
Вы знаете решение для PostgreSQL?




Определите таблицу с данными, хранящимися в вашем массиве, и вставьте значения массива в таблицу.
Это очень простой доступ / хранение данных. Всегда ли размеры вашего массива будут одинаковыми?
Нет, размеры не останутся прежними.
Если размеры не совпадают, вам придется использовать что-то вроде сериализации, как указано ниже.
Я бы сделал то же самое, если бы размеры не остались прежними. Нет смысла постоянно создавать и удалять таблицы.
Отличный вопрос.
Если вы не хотите переводить свои массивы в набор нормализованных таблиц, что, похоже, у вас нет, вы можете подумать о сериализации.
Сериализация - это модное слово для преобразования объектов в некоторый формат, который вы можете сохранить на диск или в базу данных. Два основных формата сериализации - это двоичный и XML, и я уверен, что Java имеет некоторую поддержку для этого.
В зависимости от того, какие типы данных вы используете, вы сможете преобразовать свой массив в XML или двоичный, а затем сохранить его в одном поле в базе данных. Вы можете начать работу с этой техникой на Java, проверив http://java.sun.com/developer/technicalArticles/Programming/serialization/. Я знаю, что он встроен в .NET.
Надеюсь, это поможет. Дайте мне знать, если я могу дать вам еще направление.
Как насчет сохранения данных как BLOB и использования Java для декодирования BLOB в реальный массив Java? Было бы намного эффективнее хранить и извлекать весь массив одним залпом, но было бы ужасно при перемещении отдельных элементов.
PostgreSQL имеет встроенную поддержку массивов.
http://www.postgresql.org/docs/8.0/interactive/arrays.html
Это очень хороший момент (хотя OP указал какой-то другой db, который может не обладать удивительной гибкостью PostgreSQL в этом отношении). Вы знаете, насколько эффективно это реализовано? У меня сложилось впечатление, что он не предназначен для больших массивов, но я могу ошибаться.
Есть ли эквивалент типа ARRAY PSQ в MySQL и MicrosoftSQL?
Придумайте внутреннее представление - будь то XML, JSON, какой-нибудь двоичный файл, который вы придумали сами, или любая другая форма сериализации.
Сохраните его в таблице, используя тип данных «blob». Храните любые метаданные, связанные с матрицей, в дополнительных столбцах.
Я категорически не согласен с тем, что способ сделать это - создать таблицу с тем же количеством строк и столбцов, что и ваша матрица - это очень высокая цена за функциональность, которую вы не используете.
Заранее подготовьте операторы вставки / выбора и используйте переменные связывания, чтобы изменить матрицу, с которой вы работаете - не заставляйте базу данных повторно анализировать каждый запрос.
Если это всего лишь 1 массив, почему бы не использовать двоичный файл?
Как уже было предложено: не используйте СУБД, если вам не нужны функции. Однако вместо сериализации вам может потребоваться низкоуровневый API, такой как JDBM, который предоставляет некоторые функции, подобные базе данных, такие как управление индексом на диске.
Если ваши данные плотно упакованы (гистограмма значений близка к плоской линии), ваш лучший выбор - это blob и сериализация с использованием Object [Output / Input] Stream.
В противном случае вы можете найти более эффективным использование разреженных массивов и вариаций схемы Entity-Attribute-Value. Вот пример:
Name | IndexKey | Value
------+-----------+-------
foo | 'default' | 39
foo | 0:0:0 | 23
foo | 0:0:1 | 34
foo | 1:5:0 | 12
...
bar | 1:3:8 | 20
bar | 1:3:8 | 23
bar | 1:1:1 | 24
bar | 3:0:6 | 54
...
Это также позволяет вам быстро обновлять части таблицы и выбирать срезы с помощью оператора SQL Like.
Если количество ваших измерений фиксировано, чтобы разбить ключевой столбец на отдельные столбцы int для каждого измерения, чтобы повысить эффективность индекса и иметь более гибкие критерии выбора (вы можете использовать первый индекс 'null' для метаданных, таких как значение по умолчанию) .
В любом случае рекомендуется создать кластерный индекс для столбцов Name, IndexKey.
Сериализация Java в массив байтов, хранящийся как BLOB, будет вашим лучшим выбором. Java довольно эффективно сериализует большой массив. Используйте остальные столбцы строк для всего, что вы хотите запросить или легко отобразить. Также может быть хорошей идеей хранить большие двоичные объекты в их собственной таблице и иметь «обычные» строки, указывающие на строки «больших двоичных объектов», если вы запрашиваете и сообщаете данные, не относящиеся к большим двоичным объектам (хотя это может варьироваться в зависимости от реализации базы данных. ).
HSQLDB 2.0 поддерживает одномерные массивы, хранящиеся в виде столбца таблицы. Таким образом, каждая строка таблицы будет соответствовать одной строке 2D-массива.
Но если вы хотите получить 2D-массив в целом, BLOB - лучшее решение.
Вам нужен произвольный доступ к элементам массива или только к массивам?