Я аспирант кафедры ядерной физики, сейчас работаю над программой анализа данных. Данные состоят из миллиардов многомерных точек.
В любом случае я использую кривые заполнения пространства для сопоставления нескольких измерений с одним измерением, и я использую дерево B + для индексации страниц данных. Каждая страница будет иметь постоянное максимальное количество точек внутри.
Когда я читаю необработанные данные (несколько сотен гигабайт) из исходных файлов, обрабатываю и индексирую их, мне нужно вставить отдельные точки на страницы. Очевидно, что страниц будет слишком много, чтобы просто сохранить их в памяти и затем выгрузить на диск. Итак, мой вопрос таков: какова хорошая стратегия записи страниц на диск, чтобы было минимальное перетасовка данных, когда страница достигает максимального размера и должна быть разделена.
Основываясь на комментариях, позвольте мне немного уменьшить это.
У меня есть файл, который будет содержать упорядоченные записи. Эти записи вставляются в файл, и их слишком много, чтобы просто сделать это в памяти и затем записать в файл. Какую стратегию мне следует использовать, чтобы минимизировать количество перетасовок, необходимых при вставке записи.
Если это вообще имеет смысл, я был бы признателен за любые решения этой проблемы, которые могут у вас быть.
Изменить:
Данные представляют собой точки в многомерных пространствах. По сути списки целых чисел. Каждое из этих целых чисел составляет 2 байта, но с каждым целым числом также связаны дополнительные 2 байта метаданных. Итак, 4 байта на координату и от 3 до 20 координат. Таким образом, по сути, данные состоят из миллиардов фрагментов, каждый фрагмент находится между 12 и 100 байтами. (очевидно, что точки с четырьмя измерениями будут расположены в другом файле, чем точки с пятью измерениями после их извлечения).
Я использую методы, аналогичные описанным в этой статье: http://www.ddj.com/184410998
Изменить 2: я немного сожалею, что задаю этот вопрос здесь, поэтому считаю его официально отмененным; но вот причина, по которой я не использую готовые продукты. Мои данные - это точки, которые варьируются от 3 до 22 измерений. Если вы думаете о каждой точке как о простом списке, вы можете представить себе, как я хочу запрашивать точки, как все числа, которые появились в тех же списках, что и эти числа. Ниже приведены некоторые примеры с низкой размерностью (и намного меньшим количеством точек данных, чем обычно) Пример: данные 237, 661, 511, 1021 1047, 661, 237 511, 237, 1021 511, 661, 1047, 1021
Queries:
511
1021
237, 661
1021, 1047
511, 237, 1047
Responses:
237, 661, 1021, 237, 1021, 661, 1047, 1021
237, 661, 511, 511, 237, 511, 661, 1047
511, 1021, 1047
511, 661
_
Так что это небольшая трудная проблема для большинства программ баз данных, хотя я знаю некоторые существующие, которые могут справиться с этим хорошо.
Но проблема усложняется. Не все координаты одинаковы. Часто мы просто работаем с гамма-сферой отдельно, и поэтому каждая координата представляет энергию гамма-излучения. Но в других случаях мы вставляем нейтронные детекторы в гамма-сферу или детекторную систему, называемую микрошаром, или иногда нуклиды, образующиеся в гамма-сфере, направляются в масс-анализатор фрагментов, все эти и другие детекторные системы могут использоваться по отдельности или в любой комбинации с гамма-сферой. К сожалению, мы почти всегда хотим иметь возможность выбирать эти дополнительные данные способом, аналогичным описанному выше. Итак, теперь координаты могут иметь разное значение: если у одного есть просто микрошарик в дополнение к гамма-сфере, вы создаете n-мерное событие таким количеством способов, как есть положительные решения уравнения x + y = n. Кроме того, с каждой координатой связаны метаданные. таким образом, каждое из чисел, которые я показал, будет иметь по крайней мере два дополнительных числа, связанных с ними: первое, номер детектора, для детектора, зафиксировавшего событие, второе, значение эффективности, чтобы описать, сколько раз это конкретное гамма-излучение учитывается (поскольку процент гамма-лучей, попадающих в детектор, которые фактически обнаруживаются, варьируется в зависимости от детектора и энергии).
Я искренне сомневаюсь, что какое-либо готовое решение для баз данных может делать все эти вещи и одновременно хорошо работать без огромного количества настроек. Я считаю, что время, потраченное на это, лучше потратить на написание моего собственного, а тем более общего решения. Из-за потери общности мне не нужно реализовывать функцию удаления для любого кода базы данных, мне не нужно строить вторичные индексы для входа в разные типы координат (только один набор, эффективно подсчитывающий каждую точку только один раз), и Т. Д.
