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

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

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

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

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

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

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

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

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

Павел

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи

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