Работа с большим количеством текстовых строк

Question

Мой проект, когда он запущен, соберет большое количество строковых текстовых блоков (около 20 Кбайт, самый большой из которых я видел около 200 Кбайт) за короткий промежуток времени и сохранит их в реляционной базе данных. Каждый текст строки является относительно небольшим, и в среднем будет около 15 коротких строк (около 300 символов). Текущая реализация находится в C # (VS2008), .NET 3.5, а внутренняя СУБД - Ms. SQL Server 2005

.

Производительность и хранение являются важными задачами проекта, но приоритет будет в первую очередь производительность, а затем хранение. Я ищу ответы на эти вопросы:

• Должен ли я сжимать текст перед сохранением его в БД? или позволить SQL Server беспокоиться о сжатии хранилища?
• Знаете ли вы, какой алгоритм сжатия / библиотека лучше всего использовать для этого контекста, который дает мне наилучшую производительность? В настоящее время я просто использую стандартный GZip в .NET Framework
• Знаете ли вы какие-либо лучшие практики для борьбы с этим? Я приветствую нестандартные предложения, если они реализуются в .NET Framework? (это большой проект, и это лишь малая часть его требований)

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

• Мне не нужна индексация текста или поиск по этому тексту. Мне просто нужно иметь возможность получить их на более позднем этапе для отображения в виде текстового блока, используя его первичный ключ.
• У меня есть рабочее решение, реализованное, как указано выше, и SQL Server не имеет проблем с его обработкой. Эта программа будет запускаться довольно часто и должна работать с большим контекстом данных, чтобы вы могли представить, что размер будет расти очень быстро, поэтому каждая оптимизация, которую я могу сделать, поможет.

Answer 1

Строки, в среднем, 300 символов каждая. Это 300 или 600 байт, в зависимости от настроек Unicode. Допустим, вы используете столбец varchar(4000) и используете (в среднем) 300 байт каждый.

Тогда у вас есть до 200 000 из них для хранения в базе данных.

Это менее 60 МБ дискового пространства. На земле баз данных это, прямо скажем, арахис. 60 ГБ хранилища - это то, что я бы назвал "средней" базой данных.

На данный момент даже 1010 * размышление о сжатии является преждевременной оптимизацией. SQL Server может обрабатывать такое количество текста без проблем. За исключением любых системных ограничений, о которых вы не упомянули, я не буду заниматься этим до тех пор, пока вы действительно не начнете видеть проблемы с производительностью, и даже тогда это, вероятно, будет результатом чего-то другого, например, плохой стратегии индексации.

А сжатие определенных видов данных, особенно очень небольших объемов данных (а 300 байтов определенно мало), может на самом деле иногда давать худшие результаты. Вы можете получить «сжатые» данные, которые на самом деле больше исходных данных. Я предполагаю, что в большинстве случаев сжатый размер, вероятно, будет очень близок к исходному размеру.

SQL Server 2008 может выполнять сжатие на уровне страницы, что было бы несколько более полезной оптимизацией, но вы работаете на SQL Server 2005. Поэтому нет, определенно не пытайтесь сжимать отдельные значения или строк , это не будет стоить усилий и может даже ухудшить ситуацию.

Answer 2

Если вы можете перейти на SQL Server 2008, я бы порекомендовал просто включить сжатие страниц, как описано здесь: http://msdn.microsoft.com/en-us/library/cc280449.aspx

Например, вы можете создать сжатую таблицу следующим образом:

CREATE TABLE T1 
(c1 int, c2 nvarchar(50) )
WITH (DATA_COMPRESSION = PAGE);

Если вы не можете использовать сжатие в базе данных, к сожалению, ваши строки (не более 300 символов) не имеют смысла сжимать с использованием чего-то вроде System.IO.Compression. Я полагаю, вы могли бы попробовать это.

Answer 3

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

Answer 4

Не совсем понятно, о чем вы спрашиваете.

Что касается производительности - если вы сжимаете строки в памяти перед тем, как сохранить их в базе данных, ваша программа будет работать медленнее, чем если бы вы просто помещали данные прямо в таблицу и позволяли SQL беспокоиться об этом позже. Компромисс заключается в том, что база данных sql будет больше, но жесткие диски емкостью 1 ТБ дешевы, а разве объем хранилища так велик?

Исходя из ваших чисел (200 КБ на 300 байтов), вы говорите только о 60 Мег. Это не очень большой набор данных. Рассматривали ли вы возможность использования функции группового копирования в ADO.NET (http://msdn.microsoft.com/en-us/library/7ek5da1a.aspx). Если все данные хранятся в одной таблице, это должно быть весело.

Это было бы альтернативой тому, чтобы что-то вроде EF генерировало, по сути, операторы вставки 200K.

UPDATE Вот еще один пример: http://weblogs.sqlteam.com/mladenp/archive/2006/08/26/11368.aspx

Answer 5

Похоже, вы пытаетесь решить определенно нереляционную проблему с реляционной базой данных. Почему именно вы используете базу данных? Конечно, это можно сделать, но некоторые проблемы просто не подходят. TFS показывает, что вы можете перебить проблему с помощью RDBS, как только вы добавите на нее достаточно оборудования, но это не делает его хорошей идеей.

Answer 6

Я бы не стал беспокоиться об их сжатии. Для строк такого размера (300 символов или около того) это будет скорее головной болью, чем стоит. Сжатие строк требует времени (независимо от того, насколько оно мало), и SQL Server 2005 не имеет встроенного способа сделать это, что означает, что вам придется написать что-то для этого. Если вы сделаете это в приложении, которое ухудшит вашу производительность, вы можете написать процедуру CLR, чтобы сделать это в базе данных, но это все еще будет дополнительный шаг для фактического использования сжатой строки в вашем приложении (или любой другой, который использует его в этом отношении).

Пространство в базе данных дешево, поэтому вы не особо экономите, сжимая все строки. Ваша самая большая проблема - хранить большое количество строк в памяти вашего приложения. Если вы регулярно возвращаетесь в базу данных, чтобы загрузить некоторые из них и не пытаетесь кэшировать их все одновременно, я бы не стал беспокоиться об этом, если вы на самом деле не видите проблем.

Answer 7

Звучит так, как если бы вы выиграли от использования Типы данных большого значения

Эти типы данных будут хранить до 2 ^ 31-1 байт данных

Если все ваши струны малы, то сжатие приводит к уменьшению отдачи. Без естественного сжатия SQL они не будут доступны для поиска, если вы их сожмете.