Самые быстрые типы данных .Net и SQL

Question

Я надеюсь, что этот вопрос не слишком «правильное поле», и я буду честен, говоря, что я новичок по сравнению со многими людьми в стеке ...

Я хочу сравнить изображения объектов, изображения и аудио для проекта AI, над которым я работаю. Я хотел бы преобразовать все три входа в один тип данных и использовать центральный алгоритм сравнения для определения статически вероятных совпадений.

Какие самые «быстрые» нативные типы данных .Net и SQL для таких сравнений? В .Net какой тип данных требует наименьшего количества преобразований в CLR? Для SQL какой тип может быть «CRUD-ed» самым быстрым?

Я думал о байтах для .Net и целых числах для SQL, но целые числа ставят проблему того, чтобы быть одномерной концепцией. Считаете ли вы, что изображения и аудио должны обрабатываться в файловой системе, а не в SQL ... Я так думаю ...

FWIW Я строю робота из деталей, которые я купил на TrossenRobotics.com

Answer 1

Лично, если вам нужно часто сравнивать большие двоичные объекты, я бы хешировал объекты и сравнивал их.

Если хэши не совпадают, вы можете быть уверены, что объекты не совпадают (что должно быть в большинстве случаев).

Если хэши совпадают, вы можете запустить более длительную процедуру для сравнения реальных объектов.

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

Answer 2

Скорость типов данных немного сложно измерить. Это имеет большое значение, если вы используете 32-битную операционную систему или 64-битную. Зачем? Потому что это определяет скорость, с которой эти данные могут быть обработаны. В целом, в 32-битной системе все типы данных, которые помещаются в 32-битные (int16, int32, char, byte, указатели), будут обрабатываться с одинаковой скоростью. Если вам требуется много данных для обработки, лучше всего разделить их на блоки по четыре байта каждый, чтобы ваш процессор обрабатывал их.

Однако, когда вы записываете данные на диск, скорость передачи данных, как правило, зависит от гораздо большего числа факторов. Если ваше дисковое устройство подключено к какому-либо USB-порту, все данные сериализуются, поэтому они будут байтами за байтами. В этом случае размер не имеет большого значения, хотя самые маленькие блоки данных оставляют наименьшие пробелы. (В таких языках, как Pascal, вы будете использовать упакованную запись для данных такого типа для оптимизации производительности потоковой передачи, при этом поля ваших записей будут выровнены с кратностью 4 байта для производительности ЦП.) Обычные диски будут хранить данные в больших блоках. Чтобы увеличить скорость чтения / записи, вы бы предпочли сделать ваши структуры данных максимально компактными. Но для производительности обработки их выравнивание по 4-байтовым границам более эффективно.

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

Чтобы повысить производительность, вам просто нужно найти самую слабую (самую медленную) ссылку и начать там. После оптимизации появится еще одно слабое звено ...

Answer 3

Прежде чем что-либо загружать в .NET, вы должны проверить длину данных в SQL Server, используя функцию LEN. Если длина отличается, вы уже знаете, что эти два объекта различны. Это должно сэкономить удаление большого количества ненужных данных из SQL Server в ваше клиентское приложение.

Я бы также рекомендовал хранить хэш-код (в отдельном столбце от двоичных данных) с помощью функции CHECKSUM (http://msdn.microsoft.com/en-us/library/aa258245(SQL.80).aspx).). Это будет работать только в том случае, если вы используете SQL Server 2005 и более поздние версии и сохраняете свой данные как varbinary (MAX). Еще раз, если хеш-коды отличаются, двоичные данные определенно отличаются.

Если вы используете SQL Server 2000, вы застряли с типом данных 'image'.

И image, и varbinary (MAX) будут красиво отображаться на объектах byte [] на клиенте, однако, если вы используете SQL Server 2008, вы можете сохранить свои данные как тип данных FILESTREAM (* 1010). *

Answer 4

Насколько я помню, с точки зрения чистой производительности тип Int32 относится к числу более быстрых типов данных .NET. Не могу сказать, является ли он наиболее подходящим для вашего приложения.

Answer 5

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