Need help! Не решается задача, упираюсь в ограничения железа - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
мысль понятна...
и тем не менее методики - этой ( с быстрым поиском) в промышленных базах нет
видимо есть причины
Да никто не говорит про поиск в сжатых данных. Разговор про сравнение двух сжатых последовательностей.
Допустим массив, "ааа", "ббб", "ввв". Каждый из трех элементов массива сжимаем сам по себе независимо от остальных. Допустим, сжали и поолучил массив "а", "б", "в".
Имеем искомую строку "ббб", которую надо найти в массиве. Прежде чем искать, сжимаем ее и получаем "б". Теперь ищем, и находим.
Давайте уточним, в вашем случае, должно быть 3а, 3б и 3в в сжатом виде, ибо вы опускаете количество повторений.
Если Вы полагаете что подобный алгоритм даст 70-80% сжатия, Вы ошибаетесь. Даже на русскоязычном тексте (не говоря уже о цифрах) такой подход только раздует данные.
Например слово "Эксперт" будет перекодировано как "1Э1к1с1п1е1р1т" и ни на бит не сожмется, а раздуется вдвое. Если опустить "1", то сжатия все равно не будет.
Дата и время 2014.08.18 13:45:45 не даст сжатия вашим способом.
Не говоря уже о котировках... Так что эффективность такой перекодировки близка 0 в данном случае. Это т.н. алгоритм RLE, используемый в формате PCX.
1. Давайте уточним, в вашем случае, должно быть 3а, 3б и 3в в сжатом виде, ибо вы опускаете количество повторений.
Если Вы полагаете что подобный алгоритм даст 70-80% сжатия, Вы ошибаетесь. Даже на русскоязычном тексте (не говоря уже о цифрах) такой подход только раздует данные.
Например слово "Эксперт" будет перекодировано как "1Э1к1с1п1е1р1т" и ни на бит не сожмется, а раздуется вдвое. Если опустить "1", то сжатия все равно не будет.
Дата и время 2014.08.18 13:45:45 не даст сжатия вашим способом.
Не говоря уже о котировках... Так что эффективность такой перекодировки близка 0 в данном случае. Это т.н. алгоритм RLE, используемый в формате PCX.
1. Не факт. Может быть данные такие, что все идет по три раза, поэтому такой вот простой алгоритм сжатия.
Остальное... Ой спаисбо вы мне прям глаза на мир открыли, я прям без вас не знал, что при сжатии коротких последовательностей данных их размер увеличивается.
Потому-что БД итак отлично справляется с задачей поиска без загрузки всех данных в оперативку.
Ну на самом деле хорошо и правильно отстроенный SQL сервер - ( если например у железа 64 г - 128 озу )
занимает практически за минусом нужд операционки практически все 64 г ... 128г
и поиск данных в 20 гиг ( предварительно кешированых данных ) - практически происходил бы в памяти...
поэтому то сжимать - в этой ситуации нет смысла
--
Как бэ намекаете:
Как вести поиск, написал чуть раньше.
Ну во-первых "намек" и "утверждение" это разные понятия.
Во-вторых, в моих словах даже намека на такое нет, повторюсь еще раз Для исходного файла будет одно дерево, а для порции данных, которые нужно найти - будет свое, совсем другое
И используя более менее серьезный алгоритм сжатия (любой классический, хоть Хаффмана) Вы не сможете выполнить поиск. Даже теоретически.
Потому-что БД итак отлично справляется с задачей поиска без загрузки всех данных в оперативку.
Ну во-первых "намек" и "утверждение" это разные понятия.
Во-вторых, в моих словах даже намека на такое нет, повторюсь еще раз Для исходного файла будет одно дерево, а для порции данных, которые нужно найти - будет свое, совсем другое
И используя более менее серьезный алгоритм сжатия (любой классический, хоть Хаффмана) Вы не сможете выполнить поиск. Даже теоретически.
С чего вдруг для порции данных будет другое дерево, если сжимались одни и теже данные? Если дургие данные, то у пусть будет друге дерево. Нам важно совпадение сжатых данных тогда, когда сжималсиь одни и теже данные.
Дмитрий - если бы так можно было
давно бы уже создали SQL промышленную базу - с (БЫСТРЫМ) поиском в хорошо (80%-90% ) сжатых данных ...
еще и с Insert Update Delete
1. Не факт. Может быть данные такие, что все идет по три раза, поэтому такой вот простой алгоритм сжатия.
Остальное... Ой спаисбо вы мне прям глаза на мир открыли, я прям без вас не знал, что при сжатии коротких последовательностей данных их размер увеличивается.
Ну и еще один маааленький аргумент, дабы зафиксировать глаза открытыми. Любое кодирование преследует определенную цель.
Существует кодирование разжатием, назначение - передача бинарных данных по каналам связи, поддерживающим лишь телетайп (например картинки по email), обычно используется Base64, основанный на Radix алгоритме.
Избыточное кодирование связанное с коррекцией данных, (например CD Aduio) назначение - максимально обеспечить защиту данных от повреждения на физическом носителе.
Кодирование сжатием, назначение - хранение/архивация данных.
Дмитрий - если бы так можно было
давно бы уже создали SQL промышленную базу - с (БЫСТРЫМ) поиском в хорошо (80%-90% ) сжатых данных ...
На второй круг пошли? Начните перчитывать с 5-6-ой страницы. Особо внимательно прочтитев пост.
Не приписывайте мне то, чего я предлагал. Я предлагал сравнивать сжатые последовательности, которые сжаты независо от друг от друга. А не искать малый текст сжатый отдельно в отдельно сжатом за раз огромном файле.