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