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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

До сих пор мой метод был таким.

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

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