Здравствуйте. Возникла проблема, заключающуюся в том что мое приложение использует большие массивы(List,ArrayList) данных которые хранятся естественно в оперативной памяти, общий размер которых привышает 2-3ГБ. Естественно возникают эксепшены что память переполнена. Есть ли в НЕТ способ позволяющий работать например с классами содержащими такие размеры данных не в оперативной памяти, а с файлом на диске, то есть чтобы программа также работала как и работает, но всю свою память хранила в каком нибудь файле. Хотел спользовать FileMapping но тогда возникает проблема, как работать(запись\чтение) с классам помещенным туда ведь он преобразовывается в байты, и как потом получить доступ например к какимнить аттрибутам класса.

А база данных чем не подходит? SQLite или SQL CE например.

nuke4303, а почему у тебя классы хранят столько информации? раздели данные и обработку данных. вариант с базой данных очень кошерный. принцип тот же - отделяешь данные, запихиваешь их в базу данных, потом тянешь по необходимости из базы мелкими порциями. если не загоняться с базой то можно написать самому хранение в файлах, это не так сложно(особенно если ты не сразу начал работать с шарпом, а до этого делал какие нить элементарные задачки на СИ, etc, они сильно помогают представить как это все работает в "живую", особенно задачи в которых по условию запрещено загружать все данные из файла в память и надо менять значения непосредственно в файле). написать пару классов которые будут сохранять и читать данные из файла. главное грамотно разделить.

В томто и проблема, что слить в один файл все данные, это просто, а вот потом извлеч нужный блок да и еще с возможностью замены частей блока другой длины без перезаписи всего файла не знаю как.
Насчет SQLite, какова скорость работы с большими объемами записей? Можно ли там заменять один блок данных другим?

Думаю сначала тебе надо изучить что такое база данных и как с ней работать, потом уже переходить к использованию SQLite

KelTron, согласен, без основ в этом деле никак. 

nuke4303, а для 

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

Как рбоатать с БД я и так знаю, неоднократно писал ПО под нее.

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

если


то откуда такой вопрос


??? люди которые работают с БД таких вопросов задавать не могут в принципе.

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

но БД все же кошернее, это несомненно.


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

Я работал с MySQl, Acces, MSSql и есстествеено они больше предназначаются чтобы хранить стравнительно не большие по объему блока данные. У меня же каждый блок может занимать несколько гигобайт, я не уверен что тодже Mysql выдержит это, вот и спросил про возможности SQLite.
Данные разбиты на группы, каждая группа хранится в своем List<>, листом я счтаю блок памяти, в листе много эелементов в сумме которые составляют Гб'ты. Данные при запуске приложения считываются из источника, производятся необходимые(долгие!!) операции с ними и сохраняются в эти блоки(List) по типу, далее в процессе своей работы приложение активно использует эти данные(поэтому не могу каждый раз перед запросом данных считвать его и преобразовывать, изза долготоы преобразования).....но и в памяти оперативной не могуу держать изза нехватки, вот и встает вопрос о хранении их гдето в файле, ну или в БД как выясняется

Это сообщение отредактировал(а) nuke4303 - 11.2.2011, 01:11

nuke4303,   в MySQL есть тип данных LONGTEXT и LONGBLOB  размер которых  до 4 гигабайт 
в MSSql есть аналогичные но с возможностью хранить до 6 гигов (если не ошибаюсь )   
- это размеры 1 "ячейки данных", не всей таблицы или БД


а нельзя ли поинтересоваться что  за предметная область  требующая  работу с такими большими объемами данных ( причем  постоянную и одновременную .. ) ?

мне с такого рода задачами сталкиваться не приходилось но чет мне кажется  что  там не совсем все оптимально , и можно сделать попроще 


Это сообщение отредактировал(а) FF0000 - 11.2.2011, 01:41

много это сколько? приблизительно...

в любом случае хранить в памяти несколько гигов инфы мне кажется не разумным. это удобно только если критично время выполнения и бой идет за каждую секунду. но мне что то слабо в это верится. тут есть несколько вопросов: 1. что происходит с обработанными данными(которые долго откуда то читаются и потом долго обрабатываются) после завершения приложения? предполагаю что в утиль.а они изменяются в источнике? может лучше поменять их там и сэкономить на обработке? 2. данные нужны все сразу? или все же они используются линейно? к примеру, обработка видео(конвертация из DVD в AVI), никогда не загружается весь фильм в память, загружены только текущие и ближайшие кадры, все остальное читается с диска по необходимости и сразу же сливается на диск как только становится не нужным.

ну и отстраненные размышления. по сути память(ОЗУ) работает очень похоже на ПЗУ, в том плане что если ты выделил кусок в 1 метр, то два метра ты в него не запихнешь никак, так же и с файлами. просто если тебе нужно больше места за тебя всю работу делает система, а с файлами придется развлекаться тебе лично. в принципе это не так уж и сложно, но требует немножко больше времени на организацию и обработку. да и к тому же как ты собираешься хранить в файлах блоки разной длины? а как их потом читать? или ты еще отдельно хранишь размер каждого блока?

Они удаляются после во время закрытия приложения. В ичтонике они не изменяются.

Данные на входе всегда разные при запуске приложения.

Нет нужны не все сразу, используются по примеру конвертации видео. Только они послее того как обработались и загрузились в память используются по блочно. Скорость подгрузки блоков важна!

Вот я и озвучивал эту проблему уже про разную длину и монотонный общий файл. Поэтому хочу использовать БД. Исходные данные представляют из себя набор бинарников.

А может делать сериализацию данных на жеский диск и при необходимости к ним обращаться ?

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

Ну значит выход один увеличить кол-во памяти или файл подкачки )))
Сто процентов конечно есть выход... как нибуть можно делатить...

Это сообщение отредактировал(а) Miller_time - 11.2.2011, 11:54

nuke4303, тут узкий момент есть, в смысле что использовать базу это больше нагрузить систему, с файлами будет шустрее(это личное ИМХО). я бы все же просто дополнял блоки до максимального размера и писал их в бинарный файл, читать файл можно асинхронно, в отдельном потоке, зарание читая очередной блок информации и ставя его в очередь на обработку, а с другой стороны сохранять данные когда они достигнут какой нить критической массы(пару сотен метров, к примеру). в итоге получим что и память не будет забиваться полностью и в производительности не сильно потеряешь(это конечно с учетом что в системе не одно ядро). работа с базой будет проходить по такому же принципу, но база тяжелее файла(у нее должен работать свой сервер, запросы обрабатывать и пр....). если делать базу то проще писать, если делать с файлами то скорее всего будет шустрее работать(с учетом твоей личной грамотности как разработчика, конечно)

ну а по поводу разных блоков повторюсь, приводи их к одному размеру, тогда будет проще писать их и читать. или можно хранить информацию о величине блока в самом файле. к примеру предположим у тебя есть блок размером 100 байт, и блок размером в 200 байт. в файл можно записать так: 
100[]200[]...

т.е. сначала размер блока, потом(вместо []) сам блок данных, потом следующая пара. минус всего этого это сложность реализации.

Чтобы подогнать все файлы к одному размеру нужно знать размер самого большого блока(на абум делать неполучится так как размер блоков может сильно варьироваться и быть непредсказуем), а как узнать размер самого большого блока не загрузив их все в память и не плодя множества временных файлов!?...возможно бд будет оптимальным вариантом, размер файла не сильно важен, главное чтобы оператива была свободна

а по поводу хранения информации о блоке?

А что по информации? Если хранить блоки в одном файле, то при замене блока придется перезаписывать весь файл, если взять стандартный какойто размер метаблока и в него всовывать блоки, то стоит проблема подбора этого максимального блока-контейнера....хочется какойто оптимальный вариант по производительность/удобство.....сложность реализации не важна

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

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