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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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