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

Question

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

Вы можете сохранить пул соединений, чтобы ускорить подключение к DB.

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

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

Paul

Answer 6

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

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

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

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

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

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

Answer 7

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

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

Answer 8

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

Успехов

Answer 9

Вы могли бы также думать о базе данных нет-SQL (как Riak, Монго, или даже Redis) на что-то вроде этого. Все они очень быстрые и помогают с вашей репликацией. Mysql может быть чрезмерно убит и трудно масштабируется в подобном экземпляре, но у других есть некоторые надежные инструменты