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

Я пытаюсь создать базу данных для торговой системы. Данные представляют собой данные Forex Tick, и их структура чрезвычайно проста. Ниже представлен класс, который я использую для создания объекта данных. Как вы заметили, у класса всего четыре свойства. Действительно простой класс, правда?

 using System;
 using System.Globalization;

 namespace InteractiveBrokersTradingSystem
 {
    class ForexDataObject
   {
    public ForexDataObject(string pairName, string timeString, double bid, double ask)
    {
        PairName = pairName;

        var span = DateTime.ParseExact(timeString, "yyyy.MM.dd HH:mm:ss.fff", CultureInfo.InvariantCulture) - new DateTime(1970, 1, 1, 0, 0, 0);
        TimeStamp = span.Ticks;

        Bid = bid;

        Ask = ask;
    }

    public string PairName { get; set; }

    public long TimeStamp { get; set; }

    public double Bid { get; set; }

    public double Ask { get; set; }
}

}

Хорошо, теперь мы читаем файл CSV, в котором сохраняется много тиковых данных. Я провел здесь эксперимент: я собираю тиковые данные пары EURUSD за 1 месяц (2012.01.01 --- 2012.02.02), которые сохраняются в файле EURUSD.csv. В CSV-файле 2465671 строка. В csv я читал, как создать ilist, как показано ниже, так что теперь у меня есть 2465671 объект, и каждый сохраняет один тик:

           IList<ForexDataObject> forexObjectList = new List<ForexDataObject>();
            string[] headers = csv.GetFieldHeaders();

            while (csv.ReadNextRecord())
            {
                    var forexDataObject = new ForexDataObject(pairName, csv[0],Convert.ToDouble(csv[1]),Convert.ToDouble(csv[2]));
                    forexObjectList.Add(forexDataObject);
            }

И файлы CSV имеют размер 137 МБ, теперь я хочу записать этот объект 2465671 в файл Yap с именем Forex.YAP и код, как показано ниже:

        using (IObjectContainer db = Db4oEmbedded.OpenFile(ForexYapFileName))
            {
                foreach(ForexDataObject forexDataObject in forexObjectList)
                {
                    db.Store(forexDataObject);
                }

            }

Статистика по хранению в базе данных db4o: Время: почти 20 минут !!!! Размер файла YAP: 248 МБ.

Я делаю это неправильно?


person Wenhao.SHE    schedule 02.02.2012    source источник


Ответы (2)


Не сказать, что вы неправильно используете db4o, но почему бы не сохранить его в базе данных SQL (MySQL / MS SQL)? Поддерживаются все ваши сохраняемые типы, и он должен давать намного лучшую производительность, чем db4o.

Если вы смотрите на это только локально, вы даже можете рассмотреть базу данных MS SQL Compact Edition.

Что касается того, почему он намного больше, чем файл * .csv, я не претендую на то, что знаю много о внутренней работе того, как все это хранится, но я полагаю, что файл Yap хранит гораздо больше информации для каждого объекта чем просто сами данные.

person Siyfion    schedule 02.02.2012
comment
Спасибо за ваш ответ. Я полностью согласен с тем, что, поскольку у db4o есть философия сохранения объекта в программе C # непосредственно в файл Yap. Он ДОЛЖЕН иметь некоторые накладные расходы. Между тем, но я слышал, что mysql не очень быстр? Я загружаю те же данные из файла csv, ожидая 30 секунд. Как вы думаете, мой sql укусит? Как вы относитесь к двоичному файлу? Заранее спасибо/. - person Wenhao.SHE; 02.02.2012
comment
Я бы сказал, что если mySQL недостаточно быстро, у вас возникнут большие проблемы с написанием кода обработки. Это зависит от того, является ли это чисто локальным решением или может быть размещено на хостинге? - person Siyfion; 03.02.2012
comment
Спасибо за ваше сообщение. Мой план состоит в том, чтобы загрузить данные из базы данных (mysql, двоичный файл, даже csv напрямую) и сохранить их в одной структуре данных в памяти, а затем выполнить обратное тестирование. Это все, что я хочу :) - person Wenhao.SHE; 04.02.2012
comment
Еще одно примечание. Ну, накладные расходы на хранение объектов напрямую не больше, чем на хранение в реляционной базе данных. Однако db4o не оптимизирован для миллионов плоских объектов. Реляционные базы данных оптимизированы для этих табличных плоских данных, поэтому они лучше подходят для этого типа данных. - person Gamlor; 07.02.2012

Сам я никогда не использовал db4o, но, похоже, есть некоторые опасения по поводу его производительности с таблицами, содержащими много строк. См. Пример из stackoverflow, Опыт db4o?. И, как указывает @Siyfion, будут накладные расходы на хранение объекта, а не только данных.

Изначально я собирался предложить попробовать использовать несколько потоков для повышения производительности, но этот пост на веб-сайт сообщества db4o предполагает, что это не принесет никаких улучшений; если вы намерены использовать db4o, форумы могут быть более полезными, чем StackOverflow.

Вот несколько альтернатив, как уже было предложено @Siyfion:

MySQL

Прошло некоторое время с тех пор, как я использовал MySQL, поэтому я не могу комментировать его производительность, но пример использования LOAD DATA IN FILE можно найти в другом вопросе В MySql есть любой класс, который похож на BulkCopy Class в Sql Server 2005.

MS SQL

Другой предлагаемой альтернативой является использование базы данных MS SQL. Затем вы можете использовать SqlBulkCopy для вставки таблицы данных. Обсуждение можно найти на странице SqlBulkCopy из списка ‹> с несколькими полезными ссылками. Документацию MSDN можно найти здесь.

person bebleo    schedule 02.02.2012