Need help! Не решается задача, упираюсь в ограничения железа - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
То, что ищешь можно сжать и искать в сжатом. Даст снижение объема данных и возможность держать все данные в оперативке. (теоретически)
То, что ищешь можно сжать и искать в сжатом. Даст снижение объема данных и возможность держать все данные в оперативке. (теоретически)
ихмо - что бы искать в сжатом - придется сначала разжать - в теории писать алгоритм поиска данных в сжатом виде - охренеть
и проблема в том что в оперативке - мт4 (32 бита) много не удержать
---
большой объем логично положить в какую либо базу и получать с помощью запросов готовые расчетные данные
ничего лучше не приходит на ум как применить готовые решения чем писать свой механизм обработки данных
SQL очень хорошо подходит для хранения больших объемов хотя 20 гиг для SQL это не много...
--
Вариант писать свой механизм и читать данный файл частями выделяя максимальный объем мамяти под читаемый фрагмент для скорости
причем что бы прогнать один цикл расчетов придется из 20 гигов прочитать несколько фрагментов
вопрос - будет ли это быстрее чем - вариант загнать в базу данные и обрабатывать через SQL запросы - думаю нет
считаю практически быстрее будет если загнать данные в SQL
ихмо - что бы искать в сжатом - придется сначала разжать
Самым здоровым решением конечно было бы изменение алгоритма. Но поскольку он неизвестен, ничего конкретного тут не предложишь. Общие мысли могут быть вообще не том конечно.
Например, раз требуется многократное чтение файла, это чтение может происходить во внутреннем "цикле". Можно попытаться "перенести" чтение в самый внешний "цикл" - кавычки использованы потому, что в общем случае такой "перенос" может означать создание с нуля совершенно нового алгоритма :).
Другая зацепка возникает из упоминания последовательного чтения со сдвигом - какой-нибудь итеративный алгоритм, требующий чтения только "сдвига" мог бы эту проблему решить. Но, опять же, это может означать создание с нуля совершенно другого алгоритма.
А может это всё вообще не о том :)
Необязательно. Можно то что ищешь сжать. Вот так вот! :)
---
Есть большой объем информации (около 20 Гб в текстовом файле).
Информация состоит из однотипных последовательностей, их около миллиона.
Необходимо многократно перебирать все последовательности и производить некие расчеты.
---
из 20 гиг надо подать данные в алгоритм
он не ищет - он имеет данные в виде файла- которые используются в алгоритме - подаются в алгоритм расчета
Самым здоровым решением конечно было бы изменение алгоритма. Но поскольку он неизвестен, ничего конкретного тут не предложишь. Общие мысли могут быть вообще не том конечно.
Например, раз требуется многократное чтение файла, это чтение может происходить во внутреннем "цикле". Можно попытаться "перенести" чтение в самый внешний "цикл" - кавычки использованы потому, что в общем случае такой "перенос" может означать создание с нуля совершенно нового алгоритма :).
Другая зацепка возникает из упоминания последовательного чтения со сдвигом - какой-нибудь итеративный алгоритм, требующий чтения только "сдвига" мог бы эту проблему решить. Но, опять же, это может означать создание с нуля совершенно другого алгоритма.
А может это всё вообще не о том :)
---
Есть большой объем информации (около 20 Гб в текстовом файле).
Информация состоит из однотипных последовательностей, их около миллиона.
Необходимо многократно перебирать все последовательности и производить некие расчеты.
---
из 20 гиг надо подать данные в алгоритм
он не ищет - он имеет базу данных - которые используются в алгоритме
Необязательно. Можно то что ищешь сжать. Вот так вот! :)
Батенька, Вы меня поражаете )))
Каким алгоритмом сжимать будем? Хаффман, Лемпель-Зив?
Ну даст сжатие, как для текстовика в 4-8 раз. Учтите тот факт, что алгоритмы сжатия создают деревья перекодировок для каждого файла свои.
Иными словами, для исходного файла будет одно дерево, а для порции данных, которые нужно найти - будет свое, совсем другое.
Просто интересно как Вы предлагаете вести поиск? пусть даже теоретически )))
Сжатие данных есть ни что иное как кодирование. Если провести аналогию с шифрованием, то мы получим два разных сообщения (сжатые данные), зашифрованные разными ключами (деревья перекодировок).
Их даже хоть как-то сопоставить невозможно, не говоря уже о функции поиска )))
Батенька, Вы меня поражаете )))
Каким алгоритмом сжимать будем? Хаффман, Лемпель-Зив?
Ну даст сжатие, как для текстовика в 4-8 раз. Учтите тот факт, что алгоритмы сжатия создают деревья перекодировок для каждого файла свои.
Иными словами, для исходного файла будет одно дерево, а для порции данных, которые нужно найти - будет свое, совсем другое.
Просто интересно как Вы предлагаете вести поиск? пусть даже теоретически )))
Сжатие данных есть ни что иное как кодирование. Если провести аналогию с шифрованием, то мы получим два разных сообщения (сжатые данные), зашифрованные разными ключами (деревья перекодировок).
Их даже хоть как-то сопоставить невозможно, не говоря уже о функции поиска )))
Ой а меня как тут много чего поражает.
Мне кажется и ребенку должно быть понятно. Если какой-то текст сжать каким-то алгоритмом, то он и сегодня будет точно такой же в сжатом виде и завтра тоже.
Вы утверждаете, что используя один и тот же алгоритм сжатия и сжимая два разных текста на выходе можно получить две совершенно одинаковых последовательности данных?
Просто конспирация. Конечно может быть что угодно, но предполагаю, что ищет. Даже преполагаю что.
не знаю что ищет ...
>>> Необходимо многократно перебирать все последовательности и производить некие расчеты.
Ну - пусть да - ищет - но ищет перебирая 20 гиг...
В принципе поиск и основан на том что идет некоторый перебор и сравнение
я исхожу из того что автор написалвозможно данные нельзя уменьшить - сжать - индексировать
логично уложить данные в SQL
т е передать бизнеслогику на сервер + данные
эксперт будет посылать серверу только короткие данные для перебора и расчетов
и получать готовый ответ