Обработка параллелизма с использованием файловой системы VS RDMBS (MySQL)

Question

Я создаю английский веб-словарь, в котором пользователи могут вводить слова и получать определения. Некоторое время я думал об этом, и поскольку данные на 100% статичны, и мне нужно было получать только одно слово за раз, мне было лучше использовать файловую систему (ext3) в качестве системы базы данных, а не использовать MySQL для хранения определений. Я подумал, что будет меньше накладных расходов, учитывая, что вам нужно подключиться к MySQL, и это само по себе очень медленная операция.

Я боюсь, что если бы моя система подверглась бомбардировке, скажем, 500 разборов слов в секунду, было бы мне лучше использовать файловую систему в качестве базы данных? или увеличенное чтение файловой системы будет снижать производительность, а не то, что MySQL может делать изнутри?

В настоящее время иерархия сегментируется по первой букве, второй букве и третьей букве слова. Так что, если вам нужно найти определение «вода», скрипт (PHP) попытается прочитать из «../dict/w/a/t/water.word» (после очистки слова от проблемных символов и нижний регистр)

Я иду в правильном направлении с этим или есть более быстрое решение (не считая хранения определений в памяти, используя что-то вроде memcached)? Повлияет ли количество файлов, хранящихся в каком-либо каталоге, на производительность? Какой приблизительный критерий для количества файлов, которые я должен хранить в каталоге?

Answer 1

Каковы ваши основания полагать, что это решение будет иметь значение для общей эффективности решения? Что он делает, кроме как дать определения?

Есть ли у вас MySQL как часть решения в любом случае, или вам нужно добавить его, если вы выберете его в качестве решения здесь?

Где находится окончательный источник определений? (Возможно, реплицированная) файловая система или какая-то автономная БД?

Похоже, что-то должно быть в БД архитектурно - файловые системы - странное место для отображения большого количества имен в значения (о чем свидетельствует структура вашей файловой системы, разбивающая вещи на начальные буквы)

Если он находится в БД, отвечая на вопросы типа "сколько там определений?" это намного проще, но если вы не заботитесь о таких вещах для своего приложения, это может не иметь значения.

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

Я фанат «сделай это правильно, а затем сделай это быстро», и «правильно» было бы проще достичь с помощью БД.

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

Пол

Answer 2

Вы можете сохранить пул соединений для ускорения соединения с БД.

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

Итак, я третье предложение. Используйте БД.

Но если это невероятно большой словарь, кэширование может означать, что вы почти всегда получаете данные из локальной памяти, поэтому я не думаю, что это станет самой большой проблемой для вашего приложения:)

Answer 3

Тип поиска, который требуется для словаря, - это именно то, в чем хороша база данных. Я думаю, что метод файловой системы, который вы описываете, будет неработоспособным. Не усложняй! Использовать базу данных.

Answer 4

Вы можете также подумать о базе данных no-sql (например, riak, mongo или даже redis) для чего-то подобного. Все они очень быстрые и помогают с вашей репликацией. Mysql может быть чрезмерно убитым и трудно масштабируемым в подобном случае, но в других есть несколько надежных инструментов

Answer 5

Используйте виртуальный диск в вашей оперативной памяти (поищите его в своем дистрибутиве) или, если ваши данные предоставлены PHP с использованием APC, memcache может хорошо работать с MySQL Лично я не думаю, что оптимизация, которую вы проводите здесь, - это действительно то место, где вы должны проводить время. 500 запросов в секунду - это много, я думаю, что использование mysql даст вам лучшие возможности для пересылки на потом. Я думаю, вам нужно сконцентрироваться на особенностях, а не на скорости, если вы хотите дифференцировать себя от своих конкурентов. Также есть несколько хороших разговоров о пользовательском интерфейсе для Интернета, скорость сервера является лишь небольшим фактором во всей картине.

Удачи

Answer 6

Согласившись, что это преждевременная оптимизация и что MySQL, безусловно, будет достаточно производительным для этого варианта использования. Я должен добавить, что вы также можете использовать файловую базу данных, например, очень быстрый Tokyo Cabinet в качестве компромисса. К сожалению, у него нет привязки PHP, поэтому вы можете использовать его дедушку, DBM .

Тем не менее, не используйте файловую систему, нет никаких веских причин, насколько я вижу.

Answer 7

Заставь это работать первым. Преждевременная оптимизация это плохо.

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

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

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

Более того, 1 ГБ данных легко уместится в оперативную память, поэтому вы можете сделать это быстро, загрузив всю базу данных в память во время запуска (до того, как этот узел объявит себя балансировщику нагрузки).

500 поисков в секунду - тривиально мало. Я бы начал беспокоиться о 5000 в секунду на сервер, возможно. Если вы не можете достичь 5000 операций поиска ключей в секунду на современном оборудовании (из базы данных, которая помещается в ОЗУ? !!), в вашей реализации что-то серьезно не так.

Answer 8

Данные составляют примерно пару ГБ. И моя цель - скорость, скорость, скорость (определения будут загружаться с использованием XHR). Данные, как я сказал, являются статическими и никогда не изменятся, и ни в коем случае я бы не использовал ничего, кроме одной операции чтения для каждого запроса. Поэтому мне довольно трудно убедиться в использовании MySQL и всего этого.

Что было бы первым при сбое при высокой нагрузке, используя эту стратегию, файловую систему или MySQL? Что касается масштабирования репликации, это ответ, поскольку данные никогда не изменятся и составляют всего пару ГБ.

Answer 9

БД звучит идеально для ваших нужд. Я также не понимаю, почему memcached имеет значение (насколько велики ваши данные? Не может быть больше, чем несколько ГБ ... верно?)