Методология сохранения значений во времени - PullRequest
2 голосов
/ 21 декабря 2009

У меня есть задача, которую я знаю, как кодировать (в C #), но я знаю, что простая реализация не будет соответствовать всем моим потребностям. Итак, я ищу хитрости, которые могли бы удовлетворить ВСЕ мои потребности.

  1. Я пишу симуляцию, включающую N объектов, взаимодействующих во времени.

  2. N начнется примерно с 30 и приблизится к многим тысячам.

    a. The number of entities will change during the course of the simulation.
    

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

  3. Каждый субъект имеет минимум 20 параметров, до миллионов; Я хочу отслеживать с течением времени.

    а. Это, скорее всего, потребует, чтобы мы не могли хранить все значения в памяти все время. Некоторое подмножество должно быть в порядке.

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

  4. Симуляция будет длиться миллионы временных шагов, и мне нужно сохранять каждое значение для каждого параметра.

  5. Что я буду использовать эти следы для:

    а. Построение подмножества (настраиваемых) параметров в течение фиксированного промежутка времени от текущего временного шага до прошлого.

    i.  Normally on the order of 300 time steps.
    
    ii. These plots are in real time while the simulation is running.
    

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

    i.  This requires the values be stored in a file(s) which can be inspected/loaded after restarting the software.
    
    ii. Using a database is NOT an option.
    

    с. Я буду использовать параметры для последующего анализа, которые я не могу определить заранее, поэтому желательна более гибкая система.

Моя первоначальная мысль:

  1. Один класс на объект, который содержит все параметры.

  2. При поддержке файла сопоставленной памяти.

  3. Только фиксированный, но движущийся объем файла сопоставляется с основной памятью

  4. Второй файл сопоставления памяти, который содержит временные индексы к основному файлу для более быстрого доступа во время повторного воспроизведения симуляции. Это может быть очень важно, потому что каждый файл сущности будет представлять различный временной интервал полного моделирования.

Ответы [ 4 ]

3 голосов
/ 21 декабря 2009

Я бы начал с SQLite. SQLite похож на библиотеку двоичного формата, к которой можно удобно и быстро обращаться с запросами. Это не действительно как база данных, так как вы можете запустить ее на любом компьютере без какой-либо установки.

Я настоятельно рекомендую против XML, учитывая требование миллионов шагов, потенциально с миллионами параметров.

РЕДАКТИРОВАТЬ : Учитывая огромное количество данных, SQLite может оказаться слишком медленным для вас. Не поймите меня неправильно, SQLite работает очень быстро, но он не справляется с поиском и чтением, и похоже, что ваш сценарий использования таков, что базовый двоичный ввод-вывод вполне уместен.

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

2 голосов
/ 21 декабря 2009

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

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

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

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

По той же причине - скорость и эффективность использования пространства - забудьте XML.

1 голос
/ 21 декабря 2009

Только для части памяти ...

1.Вы можете сохранить данные как xElemet (извините, что не знаете много о linq), но они содержат логику XML.

2. держите счетчик записей.

после того, как n записей сохранят xelement в xmlFile (data1.xml, ... dataN.xml)

Это может быть идеальный журнал для любого имеющегося у вас параметра с любой логикой:

<run>
  <step id="1">
     <param1 />
     <param2 />
     <param3 />
  </step>
  .
  .
  .
  <step id="N">
     <param1 />
     <param2 />
     <param3 />
  </step>
</run>

Таким образом, ваша память свободна, а данные относительно свободны. Вам не нужно слишком много думать о проблемах с БД, и удивительно, что LINQ может сделать для вас ... просто откройте правильный XML-файл журнала ...

0 голосов
/ 19 марта 2013

вот что я делаю сейчас

int bw = 0;
private void timer1_Tick(object sender, EventArgs e)
        {
            bw = Convert.ToInt32(lblBytesReceived.Text) - bw;
            SqlCommand comnd = new SqlCommand("insert into tablee (bandwidthh,timee) values ("    + bw.ToString() + ",@timee)", conn);
            conn.Open();
            comnd.Parameters.Add("@timee",System.Data.SqlDbType.Time).Value = DateTime.Now.TimeOfDay;
            comnd.ExecuteNonQuery();
            conn.Close();
        }
...