Answer the question
In order to leave comments, you need to log in
Storing hashes in mysql and memory consumption. Which algorithm is more profitable?
It was necessary to store hashes in mysql. Lot. Several billion.
In what form is it more profitable to do this in terms of memory and performance? Apparently the less memory it will take the better?
It turns out that with several billions a 32-bit hash is unacceptable?
Remains 64 bit. For example murmur3. And this turns out to be about 20 digits in the hash column ..
Maybe there are hashes that are not only digital? Then it turns out that the characters in the column will be much less than 20 ... Or is a short character hash worse than a long digital hash?
Answer the question
In order to leave comments, you need to log in
Уточните пожалуйста условия задачи.
Что за хеши, от чего они, зачем, какой к ним планируется доступ.
Существует огромное количество разных хеш функций.
google "хеш функции"
т.к 20 символов в bigint не влезут, вам придется хранить это дело в текстовом виде, а тут однозначно лучше использовать символьный хеш.
Может быть как то его дополнительно пережимать в непечатные символы и хранить как BINARY какой нибудь
И да, миллиарды в одной таблицe mysql это уже экстрим :)
table "reference" of two columns.
1.hash
2.text up to 200 characters.
There is a ready hash. We pull the table to find out which line this hash corresponds to?
1. Хранить можно по разному. Можно, например, разбить таблицу на 2n таблиц по первым битам хэша (table_00, table_01, ... table_ff).
2. Хэш, как таковой, не гарантирует однозначного отображения, то есть вполне вероятен вариант, когда две разные строки будут иметь один и тот же хэш. Для n-битного хэша перебор 2n/2 строк выдаст два одинаковых значения хэша с вероятностью 63% (парадокс дней рождения). По таблице можете оценить, какая вероятность коллизии будет для вашего количества строк при разной длине хэша.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question