привет
Работаю с биржевыми данными
данных много — 30 000 000 экземпляров записей
в каждом экземпляре есть поле — цена — тип Double
необходимо иметь быстрый доступ к экземпляру по цене
dictionary of double на мой взгляд работает медленно
подскажите есть ли что то быстрее
может есть специализированные библиотеки сторонних производителей.
или может кто то видел библиотеки для работы с большими обьемами данных.
Спасибо.
Здравствуйте, Alexander_fx, Вы писали:
A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее
А зачем хранить double, храните int или long просто * 1000 или 10000 сколько будет достаточно чтобы копейки, центики и евроцентики перешли в целую часть
A_>может есть специализированные библиотеки сторонних производителей.
Помоему для быстрой навигации по большому объему используются всякие балансированные деревья , по крайней мере в СУБД их используют для индексов.
A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Alexander_fx, Вы писали:
A_>подскажите есть ли что то быстрее
Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_> 30 000 000 экземпляров записей
На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти.
Так. К слову.
Здравствуйте, xednay89, Вы писали:
X>А этот взгляд чем обоснован? Как вы определили, что медленно?
Любая структура такого размера будет медленной. 240мб — не хухры мухры, а это одними только даблами.
Издержки на dictionary это еще столько же. +30млн самих объектов — это столько же, по самой скромной оценке.
Итого, все это постоянно кочует между виртуальной(свопом) и физической памятью.
Здравствуйте, Alexander_fx, Вы писали:
A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных.
У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет. Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей.
Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
Здравствуйте, Ikemefula, Вы писали:
A_>>в каждом экземпляре есть поле — цена — тип Double A_>>необходимо иметь быстрый доступ к экземпляру по цене A_>>dictionary of double на мой взгляд работает медленно A_>>подскажите есть ли что то быстрее A_>>может есть специализированные библиотеки сторонних производителей. A_>>или может кто то видел библиотеки для работы с большими обьемами данных.
I>У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет.
Вы меня уж простите за влезание в непрофильный форум в воскресенье, но почему не будет?
Вот люди терабайт в одну машину складывают, а не "несчастный" гигабайт.
I> Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей.
Это же всё измеряется?
I>Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, Alexander_fx, Вы писали:
A_>>подскажите есть ли что то быстрее M>Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_>> 30 000 000 экземпляров записей M>На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти. M>Так. К слову.
32 бита — забыл лет 5 назад. в текущей машине 64 гига.
текущая реализация в пике кушает 25 гигов.
Здравствуйте, Alexander_fx, Вы писали:
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
Как инициализируешь Dictionary ? Размер указываешь ?
Здравствуйте, netch80, Вы писали:
A_>>>может есть специализированные библиотеки сторонних производителей. A_>>>или может кто то видел библиотеки для работы с большими обьемами данных.
I>>У тебя расход памяти по скромной оценке около 1гб по скромной оценке. К слову, физической памяти у твоего процесса никогда столько не будет.
N>Вы меня уж простите за влезание в непрофильный форум в воскресенье, но почему не будет?
Это я погорячился. C учетом дополнения "В принципе, с учетом "в текущей машине 64 гига. текущая реализация в пике кушает 25 гигов.""
Память вроде как должна быть, на худой конец, винду можно принудить её использовать.
I>> Т.е. данные будут постоянно перекачиваться между диском и физической памятью. Так работает виртуальная память. Дополнительно проблемы у GC, из за фрагментации и прочих вещей. N>Это же всё измеряется?
Конечно.
I>>Независимо от стурктуры данных, у тебя уже тупик нарисовался. В твоем условии нет сведений, как можно выйти из этого тупика.
N>
В принципе, с учетом "в текущей машине 64 гига. текущая реализация в пике кушает 25 гигов.", можно выжимать биты.
Здравствуйте, Alexander_fx, Вы писали:
M>>Полюбопытствую: какое сейчас время запроса? И на сколько быстрее хочется?
A_>>> 30 000 000 экземпляров записей M>>На 32-х разрядных ДотНетах можно и OutOfMemory схватить, если такое количество держать в памяти. M>>Так. К слову.
A_>32 бита — забыл лет 5 назад. в текущей машине 64 гига. A_>текущая реализация в пике кушает 25 гигов.
Какие типичные операции ? Что показывает профайлер ? Где именно тормозит твое решение ?
Какие издержки на GC ?
Сколько физической памяти винда отдаёт твоему процессу ?
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, Alexander_fx, Вы писали:
A_>>в каждом экземпляре есть поле — цена — тип Double
Ф>
В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Философ, Вы писали:
Ф>>Здравствуйте, Alexander_fx, Вы писали:
A_>>>в каждом экземпляре есть поле — цена — тип Double
Ф>>
I>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Я не про скорость в данном случае.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
Ф>>
I>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Для цен и денег советуют decimal использовать. Аккуратнее будет.
Здравствуйте, xednay89, Вы писали:
I>>Итого, все это постоянно кочует между виртуальной(свопом) и физической памятью.
X>Я не понял, из чего следует, что данные куда-то кочуют. Вроде по размерности данных — все вполне помещается в память
После того как ТС сказал, что у него 64гб и из них 25 занято в пике — да, очевидно, что все может вместиться в память.
Здравствуйте, Sharov, Вы писали:
I>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
S>Для цен и денег советуют decimal использовать. Аккуратнее будет.
Здравствуйте, Философ, Вы писали:
Ф>>>
I>>В 64бит double ни на что не влияет. От размера объекта этот оверхед составит хорошо если десятую часть. От размера стандартного словаря этот оверхед составит не более четверти.
Ф>Я не про скорость в данном случае.
Тот же децимал вдвое больше дабла. Это скользкий момент. Без учета основных операций над числом нет оснований просто так распылять память.
Здравствуйте, Alexander_fx, Вы писали:
A_>привет A_>Работаю с биржевыми данными A_>данных много — 30 000 000 экземпляров записей A_>в каждом экземпляре есть поле — цена — тип Double A_>необходимо иметь быстрый доступ к экземпляру по цене A_>dictionary of double на мой взгляд работает медленно A_>подскажите есть ли что то быстрее A_>может есть специализированные библиотеки сторонних производителей. A_>или может кто то видел библиотеки для работы с большими обьемами данных. A_>Спасибо.
А смысл это все иметь в памяти?
Почему бы не использовать, например,SQLite ?
