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

Question

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

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

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

Answer 1

Плоские файлы?Нееееет...

Используйте хороший движок базы данных (MySQL, SQLite и т.д.).Затем, для достижения максимальной производительности, используйте memcached для Кэш Содержание.

---

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

Имейте в виду пару вещей:

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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.

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

  

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

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

  

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

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

  

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

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

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

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