Это быстрее для поиска большой строки в DB его хэш-кодом?
Здесь простое решение с использованием функции sscanf.
#include <stdio.h>
#include <stdlib.h>
int main( int argc,char *argv[])
{
int var1,var2;
char *buffer=NULL,c;
size_t bufsize = 32;
size_t characters;
FILE *fp;
if( argc != 2)
return -1;
buffer = (char *)malloc(bufsize * sizeof(char));
fp = fopen(argv[1],"r");
if( fp == NULL)
return -2;
characters = getline(&buffer,&bufsize,fp);
buffer[characters-1]='\0';
sscanf( buffer, "aux = \"%c=%d+%d\"",&c,&var1, &var2 );
printf("var1 = %d , var2 = %d \n",var1,var2);
return 0;
}
10 ответов
Я был бы удивлен, рекомендуем ли это предлагаемое огромное улучшение и я не использовать Ваши собственные оптимизации производительности для поиска DB.
При использовании индекса базы данных существует объем для производительности, которая будет настроена DBA с помощью попробованных и методов, которым доверяют. Трудно кодирование Вашей собственной индексной оптимизации предотвратит это и может остановить Вас получающий для любых повышений производительности в индексации в будущих версиях DB.
Если Ваши строки будут коротки (меньше чем 100 символов в целом), то строки будут быстрее.
Если строки являются большими, HASH поиск может и по всей вероятности быть быстрее.
HashBytes(MD4) кажется, является самым быстрым на DML.
Хотя я никогда не делал этого, это кажется, что это работало бы в принципе. Существует шанс, можно получить ложные положительные стороны, но это, вероятно, довольно тонко.
Я пошел бы с алгоритмом FAST, таким как MD5, поскольку Вы не хотите тратить дольше хеширование строки, чем это взяло бы Вас, чтобы просто искать его.
Заключительная вещь, которую я могу сказать, состоит в том, что Вы будете только знать, лучше ли, если Вы испытываете его и измеряете уровень.
Вы делаете соответствие равенства или соответствие включения? Для соответствия равенства необходимо позволить дб обработать это (но добавить некластерный индекс) и просто протестировать через WHERE table.Foo = @foo. Для соответствия включения необходимо, возможно, посмотреть на полнотекстовый индекс.
В целом: вероятно, не, принятие столбца индексируется. Серверы баз данных разработаны, чтобы сделать такие поиски быстро и эффективно. Некоторые базы данных (например, Oracle) предоставляют возможности создавать индексы на основе хеширования.
Однако в конце этому может только ответить тестирование производительности с представителем (Ваших требований) на данные и шаблоны использования.
Сначала - ИЗМЕРЯЮТ его. Это - единственный способ сказать наверняка.
Второй - Если у Вас нет проблемы со скоростью поиска строки, затем сохраните это простым и не используйте Хеш.
Однако для Вашего фактического вопроса (и просто потому что это - интересная мысль). Это зависит от того, насколько подобный строки. Помните, что механизм DB не должен сравнивать все символы в строке, только достаточно для нахождения различия. При просмотре 10 миллионов строк, которые все запускают с тех же 300 символов затем, хеш почти наверняка будет быстрее. Если однако Вы ищете единственную строку, которая запускается с x, то я сравнение строк мог быть быстрее. Я думаю хотя, что SQL должен будет все еще получить всю строку от диска, даже если это затем только будет использовать первый байт (или первые несколько байтов для многобайтовых символов), то таким образом, общая длина строки все еще окажет влияние.
При попытке сравнения хеша затем, необходимо сделать хеш индексируемым вычисляемым столбцом. Это не будет быстрее при разработке хешей для всех строк каждый раз, когда Вы выполняете запрос!
Вы могли также рассмотреть использование функции CRC SQL. Это производит интервал, который будет еще более быстрым для выдерживания сравнение и быстрее для вычисления. Но необходимо будет проверить результаты дважды этого запроса путем фактического тестирования строковых значений, потому что функция CRC не разработана для этого вида использования и является намного большим количеством likly для возвращения дублирующихся значений. Необходимо будет сделать, CRC или Хеш регистрируются в одном запросе, затем имеют внешний запрос, который сравнивает строки. Вы также захотите наблюдать QEP, сгенерированный, чтобы удостовериться, что оптимизатор обрабатывает запрос в порядке, который Вы предназначили. Это могло бы решить сделать сравнения строк сначала, затем CRC или вторые проверки Хеша.
Как кто-то еще указал, это только хорошо работает при выполнении точного совпадения. Хеш не может помочь, при попытке сделать какой-либо вид диапазона или частичного соответствия.
При использовании поля фиксированной длины и индекса, это, вероятно, будет быстрее...
ПОДСКАЗКА: если Вы собираетесь сохранить хеш в базе данных, Хеш MD5 всегда - 16 байтов, так может быть сохранен в uniqueidentifier столбце (и Система. Гуид в.NET)
Это могло бы предложить некоторое увеличение производительности по сохранению хешей по-другому (я использую этот метод для проверки на binary/ntext полевые изменения, но не на strings/nvarchars).
Я смущен и вероятно неправильно понимаю Ваш вопрос.
Если у Вас уже есть строка (таким образом, можно ли вычислить хеш), почему необходимо получить его?
Вы используете большую строку в качестве ключа для чего-то, возможно?
'Идеальный' ответ - определенно да. Сопоставление строк против индексированного столбца всегда будет медленнее, чем соответствие значению хэш-функции, сохраненному в столбце индекса. Это - то, для чего разработаны значения хэш-функции, потому что они берут большой набор данных (например, 3 000 точек сравнения, один на символ) и объединяют его в меньший набор данных, (например, 16 точек сравнения, один на байт).
Так, наиболее оптимизированный инструмент сравнения строк будет медленнее, чем оптимизированное сравнение значения хэш-функции.
Однако, как был отмечен, реализование Вашей собственной оптимизированной хеш-функции опасно и вероятно не подходить. (Я попробовал и потерпел полный провал), Хэш-коллизии не являются particulrly проблема, потому что затем необходимо будет просто возвратиться к алгоритму сопоставления строк, что означает, что это было бы (в худшем случае) точно с такой скоростью, как метод сравнения строк.
Но, это все предполагает, что Ваше хеширование сделано оптимальным способом, (которым это, вероятно, не будет), и что не будет никаких ошибок в Вашем компоненте хеширования (которым будет), и что увеличение производительности будет стоить усилия (вероятно, не). Алгоритмы сравнения строк, особенно в индексированных столбцах уже довольно быстры, и усилие по хешированию (время программиста), вероятно, будет намного выше, чем Ваше возможное усиление.
И если Вы хотите знать о производительности, Просто Мера Это.