Каков наиболее эффективный способ хранения больших массивов (10000x100) в базе данных, скажем, hsqldb? Мне нужно сделать это для определенной математической программы, которую я пишу в java. Пожалуйста помоги. Весь массив будет извлекаться и храниться часто (не так много отдельных элементов). Кроме того, некоторые метаданные о массиве должны храниться в массиве.Хранение массивов в базах данных
Большой вопрос.
Если вы не хотите переводить свои массивы в набор нормализованных таблиц, что звучит так, как будто вы этого не делаете, вам может потребоваться сериализация.
Сериализация - это причудливое слово для превращения объектов в какой-либо формат, который можно сохранить на диск или базу данных. Два основных формата для сериализации - двоичные и XML, и я уверен, что Java имеет определенную поддержку для этого.
В зависимости от того, какие типы данных вы используете, вы должны иметь возможность превратить свой массив в XML или двоичный код, а затем сохранить его в одном поле в базе данных. Вы можете начать эту технику на Java, проверив http://java.sun.com/developer/technicalArticles/Programming/serialization/. Я знаю, что он встроен в .NET.
Надеюсь, что это поможет. Дай мне знать, смогу ли я дать вам больше указания.
Определите таблицу с данными, хранящимися в вашем массиве, и вставьте значения массива в таблицу.
Это очень простой доступ к данным/хранилище. Будут ли размеры вашего массива одинаковыми?
Нет, размеры не останутся прежними. – 2008-10-17 20:37:50
Если размеры не совпадают, вам придется использовать что-то вроде сериализации, как указано ниже. – Nick 2008-10-17 20:43:07
Как насчет хранения данных в виде BLOB и использования Java для декодирования BLOB в реальном массиве Java? Было бы намного эффективнее хранить и извлекать весь массив одним глотком, но было бы ужасно для скрещивания отдельных элементов.
PostgreSQL имеет встроенную поддержку массивов.
Придумайте внутреннее представление - будь это XML, JSON, некоторый двоичный файл, который вы придумали сами, или любую другую форму сериализации.
Сохраните его в таблице, используя тип данных «blob». Храните любые метаданные, связанные с матрицей, в дополнительных столбцах.
Я категорически не согласен с тем, что способ сделать это состоит в том, чтобы создать таблицу с таким же количеством строк и столбцов, что и ваша матрица, - это очень высокая цена за неиспользованные функции.
Предварительно подготовьте свои инструкции вставки/select и используйте переменные связывания, чтобы изменить, с какой матрицей вы работаете, - не делайте db перепрофилировать каждый запрос.
Если это всего лишь 1 массив, почему бы не использовать двоичный файл?
Как уже было сказано: не используйте СУРБД, если вам не нужны функции.Вместо Serialization, хотя вы можете захотеть проанализировать API низкого уровня, например JDBM, который предоставляет некоторые базы данных, такие как функции индексирования на диске.
Если ваши данные плотно упакованы (гистограмма значений близка к плоской линии), ваш лучший выбор - это blob и сериализация с использованием потока Object [Output/Input].
В противном случае может оказаться более эффективным использование разреженных массивов и изменение схемы 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 «как» оператора.
Если число ваших измерений фиксировано для разбивки столбца ключа для разделения столбцов int для каждого измерения, чтобы повысить эффективность индекса и иметь более гибкие критерии выбора (вы можете использовать первый индекс «null» для метаданных, таких как значение по умолчанию).
В любом случае, рекомендуется создать кластерный индекс для столбцов Name, IndexKey.
Java Serialization to Byte Array, сохраненный как BLOB, будет вашим лучшим выбором. Java значительно упростит сериализацию большого массива. Используйте остальные столбцы строк для чего-либо, что вас интересует при запросе или отображении. Также может быть хорошей идеей сохранить BLOB в своей собственной таблице и иметь «обычные» строки, указывающие на строки «BLOB», если вы много раз запрашиваете и отправляете данные не BLOB (хотя это может варьироваться в зависимости от реализации базы данных).
HSQLDB 2.0 поддерживает одномерные массивы, хранящиеся в виде столбца таблицы. Таким образом, каждая строка таблицы будет соответствовать одной строке 2D-массива.
Но если вы хотите получить 2D-массив в целом, BLOB - лучшее решение.
Вам нужен случайный доступ к элементам массива или только к массивам? – gnud 2008-10-17 20:34:36
Знаете ли вы решение для PostgreSQL? – luksmir 2013-07-04 13:23:21