Когда-то я делал шаблон C++ класса для операций с огромными массивами. Реально сам массив хранился в файле. В памяти кэшировалось определенное количество элементов этого массива. По факту обращения к какому-то элементу он либо читался с диска, либо брался из кэша. При заполнении кэша и необходимости прочитать с диск еще один элемент, на диск выгружался элемент к которому наиболее долго не было обращений.
Для двумерных и более-мерных массивов элементом моего массива был обычный массив.

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

nomadmindedматрица порядка (500 000) х (20 000), но информация есть примерно в 1% ячеек. nomadmindedпотому что получается даже при 1% заполненности матрицы около 8 миллиардов рядов в таблице с 3 полями.если не ошибаюсь, 1% от 500000*20000 = 100000000, т.е. всего 100 миллионов.

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

nomadmindedа потом, если весь массив закинуть в файл, то каким образом осуществлять поиск? только последовательный просмотр - это смерть врагам при таком-то объеме..Ну так кладите в любую СУБД. 100 миллионов записей при правильной индексации и методах работы - не проблема.

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

ну если не принимать во внимание дополнительные структуры (индексы и прочее) и не очень плотно упаковывать данные, то потребуется (3+2+1)*100 000 000=600 000 000 байт. Т.е. в оперативку на современной машине уместиться все-таки возможно. При использовании более сложной структуры (если номер строки хранить только один раз), то будет достаточно (3*500000)+(2+1)*100 000 000~=300 Мб.

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

Если объединить оба способа, то достаточно будет (3*500000)+(2*100 000 000) ~= 200 Мб.

Т.е. в оперативку уместиться вполне реально. Вопрос только в том, насколько быстро будет работать с такой структурой. Но это уже зависит от алгоритмов...

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

nomadmindedхотя к теме форума вроде не очень относитсяОчень даже относится! Посмотрите внутреннюю структуру индексов в разных СУБД - увидите много общего.

nik_xНу-у-у, тогда рекомендую почитать как устроен FAT у ... например Ёкселя.
...красно/черное дерево.Не уловил вашей мысли насчет FAT :(
Как устроен FAT (если речь о файловой системе) я знаю, но каким боком он тут - не понимаю.
И причем тут "красно/черное дерево"?

nik_xКопай в сторону описания FAT от MS Excel.У меня FAT ну никак не ассоциируется с MS Excel.
На всякий случай поискал слово FAT в хелпе к MS Excel 2003 - пусто.

Если вы имеете в виду что-то конкретное - можно ссылочку?