[СУБД]организация хранения больших массивов чисел

Их обязательно хранить в РСУБД? Для таких вещей очень хорошо бы подошло что-то типа HDF5.

Имеет ли смысл хранить такие данные в виде блоба, или есть ещё какие-то методы?

вообще, если массивы данных очень большие (как, например, в астрофизике), то принято их хранить в древовидной структуре каталогов, а традиционные БД идут лесом, ибо не нужны

Для таких вещей очень хорошо бы подошло что-то типа HDF5.

плюсую за HDF, кстати

Каждая запись (трасса?) получается по 20Мб. А чем уже SEG-Y не угодил то? Там казалось бы по дцать трасс в файл, а дальше файлы упорядоченно по директориям, все хозяйство на зеркалируемую ФС и вот оно щастье. Ну можно конечно (и нужно наверное) в СУБД лить отдельно содержимое этикеток со ссылками на конкретные файлы, что б по диску не шарится и иметь полную картину мироздания.

Как человек, такие массивы генерящий, могу сказать что у нас так и сделано, только СУБД своя иерархическая (параметры аасоцированные с расчетом лежат в директории расчета в отдельном файле и это можно трактовать как одну запись) заточенная именно под моделирование. Потому как диски и так не успевают напрямую данные писать, а тащщить это все еще через интерфейсы БД...

>Их обязательно хранить в РСУБД?

ну вообще, можно попробовать договориться, но пока бос сказал РСУБД. а бос у нас консервативный. на дельфях вот писать заставляет.

Храни в файле, СУБД тут нафиг не сдалось.

5000 ? если каждое значение по байт 20 - то это 100кбайт на еденицу?
вполне такой хороший размерчик

а их колво сколько ? тысячи - миллионы ?
если бы ненужно обеспечивать к ним доступ удаленно - то ничего проще да и эффективнее файловой системы и нету

а если всеже в базу - так если в этих обьектах нету внутренней структуры - так то это Блоб-ы -и хранить из в sql базе как блобы

А в МС SQL нет деления таблиц на разделы, как это есть в Оракле специально для работы с огромными таблицами в сотни гигабайт?

Для начала ответь на такой вопрос: Тебе в каждый раз нужно получать весь массив или нет.

• Если да, то либо в блоб, либо в отдельный файл.
• Если нужны интервалы, то думай как на стороне сервера получать эти интервалы и отдавать только их. Тут тоже более красиво выглядят файлы, из них проще считывать только нужный диапазон.

Т.е. так или иначе лучше создать отдельный сетевой сервис для выдачи массивов по их ID. В системе эти сервисы должны иметь возможность запускаться на разных узлах для масштабирования. А на сервере храни только мета-информацию.

З.Ы.: Надеюсь правильно понимаю, что «5000 тысяч значений» - это 5 миллионов чисел на массив, а не опечатка.

пардон. опечатка 5000 всего.

а вот получать надо сразу массив. даже не так. десятки массивов для обработки(если я правильно понял, 1 волновую картину 1 исследования). то есть имеет смысл хранить это всё в файлах.

На конфе слышал что народ сливает данные в постгрес(который ещё реплицируется) в виде массивов по 200 значений на строку. У них было 130-150 замеров в секунду, объём данных 1.3тб и продолжал рости. Работало всё без тормозов.

Но если идёт речь о таких смешных объёмах как 5тыщ значений то можно их как угодно хранить, тормозить не будет.

http://crd.lbl.gov/~kewu/fastbit/doc/index.html

Года идут, а вопросы не меняются.

или есть ещё какие-то методы?

Однозначно файлы. В СУБД можно хранить метаданные для массивов.

Оракл так и делает с блобами, но они у него работают с учётом транзакций. У МС тоже самое должно быть. Делать самому — это изобретение велосипеда и программирование уже имеющихся возможностей СУБД.

Если всего 5000, то спокойно внутри базы в блобах

Нафига тебе на такой блоб транзакции? Вангую, совершенно это не нужно в твоей задаче.

>бос у нас консервативный. на дельфях вот писать заставляет.

mssql, дельфя... может нахер такого босса?

>может нахер такого босса?

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

если вам необхадимо только хранение, то вообще используйте файлы.