Элементарная задачка - XML, добавление
А если ЕСТЬ более простое решение, чем использование БД?
У каждого инструмента есть своя область применение. Безусловно, орехи можно колоть и гидравлическим прессом, но есть и более подходяшие инструменты ;)
Ты, кстати, допустил ту же ошибку, которую уже разбирали: выполняешь парсинг всего файла, об котором в задании НИЧЕГО не говорится.
Нет, просто если у тебя есть 10гиг конфигурации, то использовать XML будет очень странный человек :) И этого странного человека надо гнать ссаными тряпками.
есть и более подходяшие инструменты
-----
Вот и Я не понимаю - зачем ты тянешь гудравлический пресс (БД), туда где он совершенно не нужен.
если у тебя есть 10гиг конфигурации, то использовать XML будет очень странный человек
-----
Скучно.
Есть - задача. Известно, что есть решение. Известно что решение - простое.
Так нет - обсуждается то, что задача изначально неправильная.
А она не неправильная - она - целевая... 
Насколько? Успеешь за 20 мил отсканить SAXom 10-20 гиг?
Конечно нет. За 20 мс. 10 ГБ даже с диска прочитать не успеешь. Даже с ССД. Мегабайт 60 максимум.
- понимаешь что не успеешь
- утверждается что решение есть
то надо как-то подумать над вопросом...
А что тут думать? Очередной "муркин высер". Который в конечном итоге через 100500 уточняющих вопросов сведётся к какой-то ерунде не имеющей ни малейшего отношения к изначальной формулировке вопроса.
PS Вангую что окажется что оффсет от начала файла заранее известен (искать не надо) и используется отлично работающая с random access файлами файловая система. Отсюда и ограничение в 4 К.
Или нет, это же мурка... Тут надо думать максимально нелогично...Какой-нибудь индекс сейчас всплывёт.
Хранить и давать доступ для чтения и записи к 10ГБ структурированной информации - это задача для БД.
Есть - задача. Известно, что есть решение.
Нет даже решения, чтобы прочитать 10ГБ за 20милисекунд. Можно конечно записывать эти фрагменты тупо в конец файла, но не факт, что 10ГБ можно будет открыть за 20 милисекунд.
Как решать не знаю.
-----
Это Я вполне хорошо понимаю - задачка дана именно под то что ты не знаешь.
слишком много неоговорено
-----
Уточняй. Что будет реально влиять на выполнение задачи - доопределим.
Честно, мне лень дальше по этой задачке думать. Извините.
Давайте уже своё решение, и желательно без копирайта. ))
PS Вангую что окажется что оффсет от начала файла заранее известен (искать не надо) и используется отлично работающая с random access файлами файловая система. Отсюда и ограничение в 4 К.
У него было про случайные вставки - т.е. никаких заранее известных оффсетов и меток. Т. е. по идее нужно сначала найти место в фале, куда вставлять (т.е. просканировать его), затем вставить. Чтобы просканировать, нужно открыть целиком или простримить. И если место для встаки окажнтся в конце файла, то в 20 мс никак не уложиться.
Конечно нет.
-----
Ну тогда не трогаем SAX...
Вангую
-----
Уже ближе.
Товарищ, которому задачка адресована, уже предлагал какие-то метки в файл помещать.
Какой-нибудь индекс сейчас всплывёт.
-----
Нее, не всплывет.
Бо, решение совершенно элементарное.
Даже при 30 потоках...
оффсет от начала файла заранее известен (искать не надо)
-----
В том решении об котором ты подумал - это решение номер два - нет.
Просто есть еще более простой вариант при котором будет ответ - да.
Думаю, что подумав и посмотрев в доки ты его найдешь.
А когда найдешь, будь ласка, подтверди наличие решения и поделись ТОЛЬКО ссылкой на доку... Ок?
давать доступ для чтения
-----
Где именно в задании есть это требование? 
Нет даже решения, чтобы прочитать 10ГБ за 20милисекунд.
-----
Ну если ты ЭТО понимаешь, то зачем говоришь что надо читать?
Напряги извилины, перечитай задание, подумай, ковырни доки...
... и будем смеяться вместе над примитивностью решения. 
Только - тссс... не подсказывай...
но не факт, что 10ГБ можно будет открыть за 20 милисекунд
-----
А с каких пор размер файла начал влиять на время создания дескриптора доступа?
Ну если там шадов копи делается, маппинг или какой-нибудь индекс система строит - то да...
но просто открыть файл у меня это около 22 мс...
Инклюдом сократим количество записываемой информации до одной строчки. Но всё равно надо сначала найти место, где его вставить (в 10 гигах), а потом записать изменение.
Или вы думаете Мурр собрал 10 гигов данных в 10.000 файликах по 1 мегу и все их заинклюдил в один большой из 10.000 инклюдов? Не, он может, конечно :)
Для сомневающихся в возможностях решения задачи,
По результатам фактического теста (под отладчиком Студии) - 3883 милисекунд на 10.000 добавлений...
Время включает подготовку отдельного хмл для каждой записи - т.е. реальное время где-то 0.3 мс/добавление...
Все записи реально добавлены в файл. Записи - короткие - всего в файле 2.7Мб...
Ах, даа... старый лапоть - ССД, НТФС, И7, 8 Гб РАМ...