Плоский файл против базы данных – скорость?

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

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

Какой метод хранения данных я должен использовать?

Плоский файл может быть немного быстрее, но в конечном итоге он будет более багги в долгосрочной перспективе, потому что вместо того, чтобы просто делать сообщения SELECT * FROM messages WHERE room=nnn AND ID > yyy , вам придется загрузить файл, проанализировать он, сканировать каждую строку для идентификатора сообщения, перейти к правильному сообщению, а затем прочитать его.

Это только первая проблема. Текстовый файл не поддерживает запись несколькими пользователями (что, если два человека одновременно отправляются в одну комнату?) И могут легко стать коррумпированными.

Все рассмотренное, я бы сказал, что лучше использовать БД, даже если это что-то простое, как SQLite, которое имеет отличную поддержку PHP. Однако, рассмотрите условие многих пользователей, MySQL, вероятно, намного лучший выбор. Кроме того, у MySQL отличные возможности кэширования, поэтому в большинстве случаев последние данные поступают непосредственно из ОЗУ и будут обслуживаться быстрее, чем вы могли бы сканировать текстовый файл на PHP в любом случае.

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

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

OTOH, всего за 40 или около того, вполне вероятно, что это поместилось бы в ОЗУ, и с таким количеством записей даже самая простая процедура линейного поиска была бы намного быстрее, чем один доступ HD.

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

Просто пойдите с базой данных.

Я брошу свою шляпу на ринг здесь, хотя это старый вопрос. Для скорости, надежности и простоты использования БД является очевидным легким выбором … С одной большой оговоркой, которую многие люди упускают из виду, и это наиболее общие хосты (наиболее распространенная форма веб-хостинга), позволяют только 15 или поэтому соединения сразу, даже VPS, как правило, позволяют только 100-200, выделенные 500 или более. Это означает, что если у вас есть (n) пользователей, которые собирают каждую секунду, эти соединения будут быстро съедаться, даже быстрее, если вы также запускаете какой-либо CMS. Будучи посередине разработки моего собственного кода в чате на VPS, я тоже сталкиваюсь с этими проблемами.

Пока мой метод был таким.

  • Обязательно передайте переменную lastMessageReceived, чтобы ограничить ответ.
  • Если публичный чат передает фильтр временной метки, а также вышеупомянутый
  • если вообще возможно использовать механизм кэширования базы данных, такой как MySQLnd с включенным кэшированием запросов, и TTL устанавливается в зависимости от вашей скорости объединения.
  • Не сходите с ума по скорости объединения. 1-2 секунды интервалы могут показаться аккуратными и быстрыми, но это убьет ваш счет соединения. Снижение этого до 5 с или даже больше не приведет к огромным различиям, и пользователи, вероятно, не заметят, и загрузка вашего сервера будет намного легче. Даже рассмотрите переменную скорость объединения, которая возникает при высокой нагрузке.
  • Напишите ваш ajax для использования тайм-аута вместо интервала для его объединения и поместите вызов тайм-аута в обратный вызов ajax-success, это предотвратит укладку запросов во время пиковой загрузки.
  • И самый большой, если вы используете общий чат с множеством пользователей, пишите свой собственный код для кэширования SQL-запроса в json-файл и подавайте его на ajax-запросы и пишите какой-то пользовательский TTL-код, чтобы проверить его возраст и повторно заполнить его по мере необходимости во время запросов, CRON будет отличным здесь, если ваш хост позволит. Возрастная проверка файла и перенаправление запроса AJAX на него – это функция более высокого уровня с очень небольшими накладными расходами сервера, особенно по сравнению с запросом на БД. И не анализируйте файл в PHP, который chat_243.json отфильтровать старые сообщения, сохраните файл с первым сообщением в имени файла, таким как chat_243.json и сохраните его как уже отформатированный json, а затем просто chat_243.json весь файл, если появится запрос в php с lastMessageReceived = 243 . Поскольку это создаст несколько файлов, вам понадобится функция очистки файлов старше (м) минут, но это также легкая работа для сервера.

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