Need help! Не решается задача, упираюсь в ограничения железа - страница 6

 
YuraZ:

не знаю что  ищет ...

>>> Необходимо многократно перебирать все последовательности и производить некие расчеты.

Ну - пусть да -  ищет  - но ищет перебирая 20 гиг...  

В принципе поиск и основан на том что идет некоторый перебор и сравнение

я исхожу из того что автор написал

возможно данные нельзя уменьшить -  сжать - индексировать


логично уложить данные в SQL

т е передать бизнеслогику  на сервер  + данные

эксперт будет посылать серверу только  короткие данные  для  перебора  и расчетов

и получать готовый ответ

Поиск перебором это средневековье.
 
Integer:

Ой а меня как тут много чего поражает.  

Мне кажется и ребенку должно быть понятно. Если какой-то текст сжать каким-то алгоритмом, то он и сегодня будет точно такой же в сжатом виде и завтра тоже.

к слову -  3 террабайта копировались с сервера на сервер несколько часов - сеть  1ггб

при сжатии в ZIP   3 террабайта  у нас сжимались больше суток 

При покупке классной утилиты  LiteSpeed , которая сначала сжимает в памяти сервера а затем бекапит

сжатие 3 террабайт удалось свести к нескольким часам 

распаковка ( что бы что то изменить восстановить удалить ) длиться так же несколько часов


Решить алгоритм поиска в сжатых данных это круто!

возможно в будущем кто то придумает алгоритмы поиска вставки и удаления в базах которые уже сжаты

... но пока таких алгоритмов в промышленных масштабах нет


Есть промышленные базы ORACL MS SQL никто в мире не хранит данные в сжатом виде - если с ними идет интенсивная работа 

 
YuraZ:

1. к слову -  3 террабайта копировались с сервера на сервер несколько часов - сеть  1ггб

при сжатии в ZIP   3 террабайта  у нас сжимались больше суток 

При покупке классной утилиты  LiteSpeed , которая сначала сжимает в памяти сервера а затем бекапит

сжатие 3 террабайт удалось свести к нескольким часам 

распаковка ( что бы что то изменить восстановить удалить ) длиться так же несколько часов


2. Решить алгоритм поиска в сжатых данных это круто!

3. возможно в будущем кто то придумает алгоритмы поиска вставки и удаления в базах которые уже сжаты

 4. ... но пока таких алгоритмов в промышленных масштабах нет


Есть промышленные базы ORACL MS SQL никто в мире не хранит данные в сжатом виде - если с ними идет интенсивная работа 

1. Для рассматриваемой здесь задачи сжатие данных выполняется один раз, можно и неделю сжимать.

2. А что крутого? 

3. А что изобретать то? Вопрос в том, нужно это или нет? 

4. Ну и что что нет? 

 
Integer:

1. Для рассматриваемой здесь задачи сжатие данных выполняется один раз, можно и неделю сжимать.

2. А что крутого? 

3. А что изобретать то? Вопрос в том, нужно это или нет? 

4. Ну и что что нет? 

1) п1 только после решения п4

2) ну - не знаю возможно вопрос(БЫСТРОГО) поиска в больших массивах данных уже продумывался  достаточно квалифицированными спецами  и не раз -  и пока нет алгоритма

3) да  бог его знает возможно изобретут поиск в сжатых данных ,   но не решено и скорее всего потому что это как раз не нужно...

4)  возможно  - лучшие умы планеты еще придумают алгоритм (БЫСТРОГО) поиска в сжатых данных

  искать (МЕДЛЕННО) в сжатых данных можно  -  с методикой  ( разжимая  и затем поиска ) это не вопрос...

 

Да никто не говорит про поиск в сжатых данных. Разговор про сравнение двух сжатых последовательностей.

Допустим массив, "ааа", "ббб", "ввв". Каждый из трех элементов массива сжимаем сам по себе независимо от остальных. Допустим, сжали и поолучил массив "а", "б", "в".

Имеем искомую строку "ббб", которую надо найти в массиве. Прежде чем искать, сжимаем ее и получаем "б". Теперь ищем, и находим.

 
Integer:

Да никто не говорит про поиск в сжатых данных. Разговор про сравнение двух сжатых последовательностей.

Допустим массив, "ааа", "ббб", "ввв". Каждый из трех элементов массива сжимаем сам по себе независимо от остальных. Допустим, сжаи и поолучил массив "а", "б", "в".

Имеем искомую строку "ббб", которую надо найти в массиве. Прежде чем искать, сжимаем ее и получаем "б". Теперь ищем, и находим.

мысль понятна...

и тем не менее  методики - этой ( с быстрым поиском)  в  промышленных базах  нет

видимо есть причины

 
Integer:

Ой а меня как тут много чего поражает.  

Мне кажется и ребенку должно быть понятно. Если какой-то текст сжать каким-то алгоритмом, то он и сегодня будет точно такой же в сжатом виде и завтра тоже.

Вы утверждаете, что используя один и тот же алгоритм сжатия и сжимая два разных текста на выходе можно получить две совершенно одинаковых последовательности данных? 

Это из чего Вы решили что я такое утверждаю? 

 
YuraZ:

мысль понятна...

и тем не менее  методики - этой ( с быстрым поиском)  в  промышленных базах  нет

видимо есть причины

Естественно, причины есть :)

Сжатие данных это - устранение избыточности. И чем эффективнее произведено сжатие, тем меньше избыточность. И искать предложенным выше методом не получится, т.к. в сжатом тексте любая часть будет зависеть от всего текста.

 
Contender:

Естественно, причины есть :)

Сжатие данных это - устранение избыточности. И чем эффективнее произведено сжатие, тем меньше избыточность. И искать предложенным выше методом не получится, т.к. в сжатом тексте любая часть будет зависеть от всего текста.

:-) о чем и речь ...
 
elugovoy:

Это из чего Вы решили что я такое утверждаю? 

Как бэ намекаете:

Ну даст сжатие, как для текстовика в 4-8 раз. Учтите тот факт, что алгоритмы сжатия создают деревья перекодировок для каждого файла свои.

Иными словами, для исходного файла будет одно дерево, а для порции данных, которые нужно найти - будет свое, совсем другое.

Просто интересно как Вы предлагаете вести поиск? пусть даже теоретически )))

Как вести поиск, написал чуть раньше.