Что быстрее, плоские файлы или база данных оперативной памяти MySQL?

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

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

Если вам нужна сохраняемость данных, используйте СУБД, например MySQL.

Как правило, БД лучше, однако, если вы используете небольшой, в основном статический объем данных, это может повысить производительность (и простоту) при использовании плоских файлов.

Все, что угодно, кроме тривиального обмена данными, и я бы, однако, выбрал БД.

1 - Где плоский файл может быть полезен: Плоский файл может быть быстрее, чем база данных, но в очень специфических приложениях. Они быстрее, если данные считываются от начала до конца без какого-либо поиска или записи. Если данные не помещаются в память и их необходимо полностью прочитать, чтобы выполнить работу, это "может" быть быстрее, чем база данных. Кроме того, если записи намного больше, чем чтения, плоский файл также блестит, большинству настроек баз данных по умолчанию потребуется, чтобы запросы на чтение ждали завершения записи, чтобы поддерживайте индексы и внешние ключи. Выполнение запросов на запись обычно происходит медленнее, чем простое чтение.

TD/LR весион: Используйте плоские файлы для системы, основанной на заданиях (она же, простой анализ журналов), а не для запросов веб-поиска.

2- Яма с плоскими файлами падает: Если вы собираетесь использовать плоский файл, вам нужно будет синхронизировать ваши сценарии при изменении файла с помощью пользовательского механизма блокировки. Что может привести к замедлению, повреждению вплоть до мертвой блокировки, если у вас есть ошибка.

База данных на основе 3-Озу? Большинство баз данных имейте в памяти кэш для результатов запросов, индексов поиска, что делает их очень трудными для обработки с помощью плоского файла. Поскольку они кэшируются в памяти, выполнение их полностью из памяти в большинстве случаев неэффективно и опасно. Лучше правильно настроить конфигурацию базы данных.

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

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

5 - могут ли несколько сценариев одновременно подключаться к одной и той же БД?

Да, это называется объединением соединений. В php (на стороне клиента) его функция открывает соединение с помощью mysql-pconnect (http://php.net/manual/en/function.mysql-pconnect.php ). Вы можете настроить я думаю, что максимальное открытое соединение в php.ini. Аналогичная настройка на стороне сервера mysql определяет максимальное количество одновременных клиентских подключений в /etc/mysql/my.cnf.

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

В конфигурации Apache также имеется один пул соединений/пул потоков для обычных веб-клиентов. См. httpd.conf.

Извините за стену текста, было скучно. Льюис.

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

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

Я бы сказал, что база данных MySQL была бы лучшим выбором, если у вас нет какого-либо механизма для борьбы с блокировками неструктурированных файлов (и каким-либо способом контроля доступа). В этом случае уровень БД (независимо от конкретной СУБД) действует как косвенный уровень, позволяя вам не беспокоиться об этом.

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

Если в вашей системе есть кэш PHP (который кэширует скомпилированный код PHP в памяти, например APC), попробуйте поместить свои данные в файл PHP в виде кода PHP. Если вам нужно записать данные, возникают некоторые проблемы с безопасностью.

Мне нужен простой способ для нескольких запуск PHP-скриптов для обмена данными.

APC и memcached являются хорошими вариантами в зависимости от контекста. общая память также может быть опцией.

Должен ли я создать базу данных MySQL с механизмом хранения оперативной памяти и обмениваться данными через нее (могут ли несколько сценариев одновременно подключаться к одной и той же базе данных?)

Это тоже неплохой вариант, но, вероятно, он будет не таким быстрым, как APC или сохраненный в памяти.

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

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

Если это хранилище данных, к которому могут обращаться несколько авторов одновременно, ни в коем случае НЕ используйте плоский файл! Писать в неструктурированный файл из нескольких процессов, скорее всего, приведет к повреждению файла. Вы можете заблокировать файл, но вы рискуете столкнуться с проблемами конкуренции при блокировке и длительным временем ожидания блокировки.

Обработка параллельных записей является причиной существования таких приложений, как mysql и memcached.