Максимаотное количество строк

[Jonik-Mnimonik]

Подскажите какое максимальное количество строк может храниться в базе данных mySQL 2005, если база содержит 4 столбца?

[kim-aa]

Теоретически ограничений нет, точнее они не достижимы на практике.

Реально я сталкивался с такой базой http://forum.oszone.net/thread-98946.html

[vadimiron]

Jonik-Mnimonik,
Ограничений нет - всё зависит от вашего железа - сколько оно выдержит.
Вот выдержка из списка features MySQL
Handles large databases. We use MySQL Server with databases that contain 50 million records.
We also know of users who use MySQL Server with 60,000 tables and about 5,000,000,000 rows.

[Jonik-Mnimonik]

Просто не необходимо сохранять в базе данных пароли и соответсвующие к ним хэш-значение.
Если допустить что длина пароля 6 символов, а мощность алфавита 52. то количесто строк должно быть 56,800,235,584.
Вот теперь у меня возникает другой вопрос. Если значение хэш-функции 32 байта, а размер пароля 6 байт, то общий размер одной записи будет 38 байт. Умножая 56,800,235,584*38 получим 2,158,408,952,192 т.е. получается размер базы данных 2Тбайта. Правильно ли я рассуждаю?

[kim-aa]

о количесто строк должно быть 56,800,235,584 »

Вы расчитали все возможные значения (комбинации).
Однако, в ваших рассуждениях есть ошибка, а именно - число реально хранимых записей (строк) будет равно числу пользователей (аккаунтов).
Расчитанных же вами 56 милиардов, хватит на 9 аккаутнов для каждого жителя Земли.
Вы расчитали некое умозрительное максимальное значение, причем, пароли у пользователей не должны дублироваться.

[Jonik-Mnimonik]

Это я всё понимаю. Просто передо мной стоит задача нагенерировать все возможные хэш-значения от паролей, а потом найти пароль по значению хэша.

[Amin]

Лучше будет нарезать хеши в несколько таблиц, сгруппировав по сложности. Т.е., чтобы сперва просматривались таблицы с легкими (наиболее распространенными паролями), а если в них нету записей - только тогда переходить к таблицам со сложными паролями. Это здорово поможет поднять скорость.
56 миллиардов записей в одной таблице - это под нагрузкой ни одна БД не вынесет, будь она хоть на ассемблере написана.
А вообще MySQL для такой задачи отличный выбор.

[dmitryst]

Jonik-Mnimonik, а зачем вам пароль из хэша? ИМХО, абсолютно ненужная трата ресурсов. У меня, например, в одной из программ используется такой метод - клиент присылает нешифрованый пароль, скрипт его принимает, шифрует, далее из базы запрашивется образец хэша, и с ним сравнивается свежезашифрованый. Таким образом, в базе у меня хранятся только хэши - никаких паролей в явном виде, правда, если пользователь его забудет, придется вводить новый. Зато количество записей соответствует количеству пользователей, не более. Для повышения безопасности я еще и блокирую учётку при трёхкратной ошибке набора пароля. Ну, как вариант, можно применить двусторонние алгоритмы, т.е. пароль можно получить из хэша и наоборот, хэш из пароля. Количество записей, опять же, по количеству пользователей.
получим 2,158,408,952,192 т.е. получается размер базы данных 2Тбайта. » :lol: вам придется создавать кластер для более-менее быстрой работы такой БД.

[Jonik-Mnimonik]

Лучше будет нарезать хеши в несколько таблиц, сгруппировав по сложности. Т.е., чтобы сперва просматривались таблицы с легкими (наиболее распространенными паролями), а если в них нету записей - только тогда переходить к таблицам со сложными паролями. Это здорово поможет поднять скорость.
56 миллиардов записей в одной таблице - это под нагрузкой ни одна БД не вынесет, будь она хоть на ассемблере написана.
А вообще MySQL для такой задачи отличный выбор. »

Я так и делаю. Я разбил таблицы на разные длинны паролей. То есть пароль с длиной 3 храниться в одной таблице, а пароль с длиной 4 в другой.

Jonik-Mnimonik, а зачем вам пароль из хэша? ИМХО, абсолютно ненужная трата ресурсов. У меня, например, в одной из программ используется такой метод - клиент присылает нешифрованый пароль, скрипт его принимает, шифрует, далее из базы запрашивется образец хэша, и с ним сравнивается свежезашифрованый. Таким образом, в базе у меня хранятся только хэши - никаких паролей в явном виде, правда, если пользователь его забудет, придется вводить новый. Зато количество записей соответствует количеству пользователей, не более. Для повышения безопасности я еще и блокирую учётку при трёхкратной ошибке набора пароля. Ну, как вариант, можно применить двусторонние алгоритмы, т.е. пароль можно получить из хэша и наоборот, хэш из пароля. Количество записей, опять же, по количеству пользователей. »

Дело в том, что задача поставилась именно восстановить пароль по значению хэш-функции. Это трудная задача. Вот мне и приходиться выщитывать все значения хэш-функций. а потом сравнивать, с тем по которому необходимо найти пароль. А в таблице храниться хэш-функция и соответствующий ему пароль. Если говорить про систему аутентификаци, то конечно я бы выбрал так как вы сказали.

зы Диплом, ни куда не деться.

[Busla]

Jonik-Mnimonik, размер БД будет гораздо больше, т.к. для эффективного поиска в дополнение к таблице строится индекс. По здравым размышлениям это вроде бы и избыточная информация для данной конкретной задачи, но сервера БД идут по универсальному пути.

Разбивать таблицы по длине исходных паролей imho плохая концепция. Если бы заранее была точно известна длина пароля - поиск бы ускорился, а без этого вы вынуждены частично идти методом перебора.

[dmitryst]

Диплом, ни куда не деться. »
ааа, ну сразу надо было сказать... Я б столько не писал :biggrin:
Кстати, алгоритм хэширования односторонний, что ли? А насчет разбиения... ну хз, наверное, лучше, но тут оптимизацию не придумаешь, да и кэш самой базы не используется, практически

[Jonik-Mnimonik]

Кстати, алгоритм хэширования односторонний, что ли? »
Алгоритм хэширования используется односторонний ГОСТ 34.11. Хотя я не знаю сучествуют ли двухсторонние алгоритмы хэширования? Мне кажеться алгоритм хэширования по определению односторонний.