Need help! Не решается задача, упираюсь в ограничения железа - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Думал об этом. Интересовался мнением:
Какое будет ускорение по сравнению с чтением файла и какое замедление по сравнение с работой в памяти?
СУБД размещает свои таблицы в памяти по возможности.
но не в твоем случае, если у тебя конечно не 32 Гб ОЗУ
поэтому как раскинуть 20Г в 4Г это надо поломать голову над оптимизацией.
Если упростишь свою задачу, то лучше таки сделай обычный RAM диск в памяти. и не заморачивайся на СУБД.
Если не смогёшь, ну тогда дерзай по винту.
Какое будет ускорение по сравнению с чтением файла и какое замедление по сравнение с работой в памяти?
Ну, Вам ведь не просто читать нужно файл, а еще вести поиск, вычисления, конвертировать текст в числа, выполнять сортировку и т.п.
Во-первых, если данные не часто обновляются, то можно создать сколь угодно индексов по атрибутам, участвующим в поиске данных (в т.ч. и совокупности атрибутов). Таким образом, поиск будет производиться быстрее (при использовании индексов), следовательно и расчеты тоже.
Во-вторых, скажем MySQL, MS SQL, Oracle и другие СУБД используют технологию кеширования данных для повторяющихся запросов, это тоже дает некоторый плюс скорости обработки.
В-третьих, можно разбить таблицу на части (partitions), скажем по годам. При этом запросы, выбирающие данные по одному году не будут считывать/вести поиск по данным, находящимся в других партициях.
В-четвертых, поскольку исходные данные у Вас находятся в текстовом виде, то при загрузке в БД объем должен уменьшиться в связи с приведениям к естественным типам. Например, число 124.223456221 в текстовом виде займет 13 байт, в БД в зависимости от типа 4-8; дата и время "2014-08-17 10:23:35" - 19 байт, а в БД - 8 байт.
В-пятых, если используется часто агрегированная информация за определенные периоды, то можно эти данные агрегировать разово и хранить в другой таблице.
Конечно, если речь лишь о чтении данных в память, то WinApi выполнит это шустрее, но что с данными делать потом? Представьте, даже для поиска нужной части данных, необходимо все данные прочитать с диска. Или же самому писать функционал индексирования, сортировать данные в файле, создавать индексные фалы на все операции поиска, в общем переписывать половину функционала СУБД. Для обработки такого объема данных и желания разумной производительности, это необходимо.
Мое мнение однозначно - серверная СУБД (файловые БД типа MS Access, SQLite тут не подойдут) на выделенной машине. Будет достаточно разумная производительность и удобство обработки данных (SQL-запросы). Иначе убьете много времени на написание низкоуровневых "внутренностей" для обработки файла.
Думал об этом. Интересовался мнением:
Какое будет ускорение по сравнению с чтением файла и какое замедление по сравнение с работой в памяти?
( имею опыт работы с базой более 3ТБ и относительно карликовыми базами 10-100гиг )
но при определенном железе ... скажем от 64ггб озу и выше с хорошей дисковой подсистемой
в этой ситуации в сравнении с работой с огромным файлом
ускорение на SQL будет существенное но скорость конечно будет зависеть от реализации на SQL
- правильная разработка базы - правильные индексы - правильная конфигурация базы
имеется ввиду разбитие файлов ( т о о чем пишет elugovoy верно )
Для полноценной реализации потребуется отдельный сервер , серверная операционка - база SQL
если MS SQL то не ниже 2008 ( по софту так же желательно не ниже 64 )
Но на мой взгляд реализация будет достаточно трудоемкая и затратная по железу... ( в идеале 64 бита )
--
если же на машине всего 16 гиг и при этом машина используется как станция
ставить на нее SQL сервер будет не сильно здорово - но лучше чем мучатся с текстовым файлом
правда если нет опыта работы с SQL некоторые потребуются усилия при реализации
А если этот файл сжать архиватором, какой получится объём (ведь текст должен очень хорошо сжиматься)?
время на раз-архивацию при каждом проходе убьет производительность намертво
время на раз-архивацию при каждом проходе убьет производительность намертво
Я не имел ввиду разархивацию. Если архивация может сильно сократить объём, значит имеет смысл сжимать информацию в индексный файл.
изначально было
А если этот файл сжать архиватором, какой получится объём (ведь текст должен очень хорошо сжиматься)?
отсюда и была реакция на ваш пост!
индексный файл - создать... ?! это уже другая тема
еще вообще круче написать свой ( подобие SQL ) сервер - но зачем ?
изначально было
отсюда и была реакция на ваш пост!
индексный файл - создать... ?! это уже другая тема
еще вообще круче написать свой ( подобие SQL ) сервер - но зачем ?
Изначально был вопрос к автору - а насколько сожмётся файл. ....
Можно вопрос , а зачем ?
ну сожмется допустим на 70-80% и что это даст ? автору в решении проблемы которую он описал