скорость доступа, бинарный хеш-файл perl против mySQL

Question

В настоящее время я использую много бинарных хеш-файлов perl, хранящихся в нескольких местах для загрузки данных на этот cgi-сайт.Я спорю, будет ли MySQL быстрее или медленнее, если я решу хранить там свои данные.

Есть идеи?Я понимаю, что хеши Perl полностью загружены в память.

Гордон

Answer 1

Использование базы данных означает, что ваши поиски будут выполняться медленнее, но ваш скрипт будет использовать меньше памяти.

Использование хэшей в памяти означает, что ваши поиски будут быстрее, но ваш скрипт будет использовать больше памяти.

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

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

Если у вас проблемы с памятью, используйте базу данных.

Если вы хотите использовать базу данных для использования базы данных (т.е. для изучения новых навыков), то используйте базу данных..

Answer 2

Если Perl-хеш обрабатывает ваши потребности в данных, вам, вероятно, не понадобятся издержки на полноценную базу данных SQL.Существует много вариантов хранения для хранения ключей-> значений, таких как Berkley DB и весь механизм NOSQL.Google те, и вы найдете много информации.Perl-интерфейсы существуют в CPAN для многих из них.

Answer 3

Говоря строго с точки зрения скорости, поиск одиночных, точно совпадающих ключей в прямом хеше в памяти - это почти то, что вы можете получить, если только ваши данные не поддаются размещению в массиве. (т. е. к нему будут обращаться только серии цифровых клавиш, которые образуют в основном непрерывный диапазон, начиная с 0.)

Если у вас есть несколько возможных ключей, по которым вам может потребоваться выполнить поиск (например, как по имени, так и по идентификатору сотрудника), или если вам нужно выполнить поиск, не основанный исключительно на равенстве (например, "Найти всех сотрудников с последними назовите «Смит» »), тогда вы будете значительно замедлены поиском по ключам хеш-функции, и база данных начнет выглядеть намного лучше.

Еще одним фактором общей производительности является то, что вы упомянули, что ваши хэши «хранятся в нескольких файловых папках». Если вы выполняете только один или несколько поисков, считывание хэшей в память из этих файлов также требует времени, что опять-таки склоняет вещи в пользу использования базы данных, что минимизирует количество ненужных данных, которые считываются с диска.

Так что многое зависит от того, как вам нужен доступ к вашим данным и вашим шаблонам доступа.

Answer 4

Помимо того, что уже было упомянуто, вы получите большую масштабируемость с базой данных, поскольку она может быть выгружена на другой сервер.В течение многих лет MySQL работал над ускорением сложных поисков, а это код, который вам не нужно писать.С бинарным хешем вам нужно беспокоиться о синхронизации на диске, не замедляя работу приложения, обеспечивая атомарность записи на диск, обслуживание и оптимизацию, а также обработку синхронизации, когда несколько процессов получают доступ к данным одновременно.Использование базы данных касается всего этого для вас.

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

Часто хорошей идеей является написать общий API поверх драйвера хеша.Затем, когда масштабируемость или параллелизм становятся проблемой, вы можете просто добавить драйвер MySQL и перенести ваши данные поверх.Конечно, это большое «просто», но это быстрый и простой способ продвижения вперед, который ограничивает влияние на остальную часть вашего программного обеспечения в случае необходимости изменений