Мне надо обрабатывать очень большой массив однотипных структур — всего их порядка 60 миллионов. Каждая структура вида {PID, type (atom), direct (atom), index (Integer), nextind (Integer), prevind (Integer), position (Integer)}. Я думаю такая структура займёт около 50 байт, и того на весь массив надо 60 * 50 = 3 ГБ. А это значит массив желательно должен частично сбрасываться на диск. Плюс нужен быстрый доступ по полям PID, index, nextind, prevind: время поиска нужной структуры по этим полям должно составлять около 2 мкс, время их записи — столько же. Запись и чтение часто идёт в одни и те же структуры (обчно их всего около 30 000, остальные просто ждут). Вопрос: как мне организовать такой массив?
Максимум, что я могу посоветовать — это использовать (d)ets или mnesia, на более развернутый ответ силенок не хватает. Помогите, а?
кроме того, я сомневаюсь, что накладные расходы любого БД-подобного движка уложатся в эти 2 мкс. так что первый вопрос, который я бы задал — а как ты решил бы эту задачу на C?
Здравствуйте, Mamut, Вы писали:
M>На форуме проекта "Erlang по-русски" был задан следующий вопрос:
[skip] M>Максимум, что я могу посоветовать — это использовать (d)ets или mnesia, на более развернутый ответ силенок не хватает. Помогите, а?
Такое очень сложно сделать без мутируемых структур — говорю по опыту
Проще взять и написать модуль на С++, с использованием Boost.MultiIndex. Естественно, все должно хранится в памяти.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>2 мкс? disk seek time ~10 ms BZ>кроме того, я сомневаюсь, что накладные расходы любого БД-подобного движка уложатся в эти 2 мкс. так что первый вопрос, который я бы задал — а как ты решил бы эту задачу на C?
Уложатся, особенно если слегда расслабить требования на букву D в ACID.
Здравствуйте, Mamut, Вы писали:
M>Максимум, что я могу посоветовать — это использовать (d)ets или mnesia, на более развернутый ответ силенок не хватает. Помогите, а?
При использовании Мнезии времена около 2 мкс для поиска вполне достижимы. На Пне-4 2.1 Ггц у меня было менее 6 мкс под Вынью. Запись там с 2-мя уровнями кэширования ( в памяти и на диске ), отчего многое зависит от быстродействия диска и размера его аппаратного кэша.
Ну и конечно же — память и еще раз память ! Чем ее больше, тем быстрее работает
M>Мне надо обрабатывать очень большой массив однотипных структур — всего их порядка 60 миллионов. Каждая структура вида {PID, type (atom), direct (atom), index (Integer), nextind (Integer), prevind (Integer), position (Integer)}. Я думаю такая структура займёт около 50 байт, и того на весь массив надо 60 * 50 = 3 ГБ. А это значит массив желательно должен частично сбрасываться на диск. Плюс нужен быстрый доступ по полям PID, index, nextind, prevind: время поиска нужной структуры по этим полям должно составлять около 2 мкс, время их записи — столько же. Запись и чтение часто идёт в одни и те же структуры (обчно их всего около 30 000, остальные просто ждут). Вопрос: как мне организовать такой массив?
M>Максимум, что я могу посоветовать — это использовать (d)ets или mnesia, на более развернутый ответ силенок не хватает. Помогите, а?
На 32-х битной ахитектуре это все в память не влезет принципиально. А в каком состоянии порт Эрланга на 64 бита и какие у него свойства я не знаю.
Так что единственный вариант — это dets (и то — надо протестировать, как это будет . Ets не канает — она живет только в памяти. mnesia ничего полезного не добавит, только лишние ресурсы отожрет.
Учитывая требования к производительности, я бы постарался выжать максимум из dets — это самое простое и быстрое для дисковых look-up запросов, что можно себе в принципе представить. Это быстрее mnesia — у dets меньше оверхэд. Это теоретически должно быть быстрее реляционных БД — там применяются хэшлисты, а не B-деревья, и живет это в вашем процессе, а не в другом. Добиванием памяти к системе мы добьемся того, что оперсистема будет кэшировать фрагменты dets. Так что все должно быть ok.
Здравствуйте, Gaperton, Вы писали:
G>На 32-х битной ахитектуре это все в память не влезет принципиально. А в каком состоянии порт Эрланга на 64 бита и какие у него свойства я не знаю. G>Так что единственный вариант — это dets (и то — надо протестировать, как это будет . Ets не канает — она живет только в памяти. mnesia ничего полезного не добавит, только лишние ресурсы отожрет.
Хотя можно использовать mnesia в режиме fragmented tables — тогда есть надежда, что еще и кэширование будет адекватно работать средствами mnesia. Ведь там часто в одни и те же поля запросы идут?
Второй вариант — организовать собственный кэш в памяти. Write through кэш делается просто элементарно, write back — тут надо думать, как делать. Но тоже можно.
Я бы все перечисленное пробовал только по показаниям — если dets будет работать неадекватно.
Здравствуйте, Gaperton, Вы писали:
G>На 32-х битной ахитектуре это все в память не влезет принципиально. А в каком состоянии порт Эрланга на 64 бита и какие у него свойства я не знаю. G>Так что единственный вариант — это dets (и то — надо протестировать, как это будет . Ets не канает — она живет только в памяти. mnesia ничего полезного не добавит, только лишние ресурсы отожрет.
Влезет, впритык. Если хорошо постараться и пошаманить. Ну и еще PAE есть — его из С-шного модуля можно использовать в Windows.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>На 32-х битной ахитектуре это все в память не влезет принципиально. А в каком состоянии порт Эрланга на 64 бита и какие у него свойства я не знаю. G>>Так что единственный вариант — это dets (и то — надо протестировать, как это будет . Ets не канает — она живет только в памяти. mnesia ничего полезного не добавит, только лишние ресурсы отожрет. C>Влезет, впритык. Если хорошо постараться и пошаманить. Ну и еще PAE есть — его из С-шного модуля можно использовать в Windows.
На настольной винде у тебя процессу отводится 2 гига адресного пространства (не влезет гарантированно). На серверной винде — 3 гига на процесс (все равно не влезет), а PAE (это страничная адресация, позволяющая адресовать до 64 гиг, да?), если мне не изменяет память, есть только в самой крутой серверной винде.
Так что на десктопной 32-х битной винде — не влезет точно. А чем извращаться с PAE (это того не стоит) , проще взять 64-битную ось и закрутить ее, скажем, на оптероне, и добить памяти до восьми гиг. Вот тогда можно реально рассчитывать, что влезет.
G>>На 32-х битной ахитектуре это все в память не влезет принципиально. А в каком состоянии порт Эрланга на 64 бита и какие у него свойства я не знаю. C>Влезет, впритык. Если хорошо постараться и пошаманить. Ну и еще PAE есть — его из С-шного модуля можно использовать в Windows.
Gaperton wrote: > На настольной винде у тебя процессу отводится 2 гига адресного > пространства (не влезет гарантированно).
На XP Pro можно ключик /3G указать — работает.
> На серверной винде — 3 гига на процесс (все равно не влезет), > а PAE (это страничная адресация, позволяющая адресовать до > 64 гиг, да?), если мне не изменяет память, есть только в > самой крутой серверной винде.
Нет, она есть во всех виндах — там только максимальный разрешенный объем
физической памяти ограничивают на обычных виндах до 4Гб. Я даже писал на
XP приложение, его использующее. Когда писал — вспоминал старый добрый
DOS с его сегментной адресацией
> Так что на десктопной 32-х битной винде — не влезет точно. А чем > извращаться с PAE (это того не стоит) , проще взять 64-битную ось и > закрутить ее, скажем, на оптероне, и добить памяти до восьми гиг. Вот > тогда можно реально рассчитывать, что влезет.
Ну да, это надежный метод. Просто не всегда возможен, в частности из-за
несовместимости кучи софта с 64-битной Виндой
