производительность веб-приложения с большим количеством вставок

Question

Какова лучшая стратегия ввода-вывода для веб-приложения с высоким трафиком, которое регистрирует поведение пользователя на веб-сайте и где ВСЕ трафик приведет к записи ввода-вывода? Будет ли запись в файл, а в одночасье - вставки в базу данных? Или просто сделать INSERT (или INSERT DELAYED) за запрос? Я понимаю, что для правильного рассмотрения этой проблемы потребуется гораздо более подробная информация об архитектуре, но толчок в правильном направлении будет очень оценен.

Answer 1

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

Answer 2

Моим инстинктом было бы использовать только базу данных, избегая прямой файловой системы IO любой ценой. Если вам нужно создать какой-то файловый артефакт, я бы использовал ночное задание cron (или что-то в этом роде), чтобы читать записи DB и записывать в файловую систему.

ТАКЖЕ: используйте только «INSERT DELAYED» в случаях, когда вы не против потерять несколько записей в случае сбоя сервера или перезагрузки, поскольку некоторые записи почти наверняка будут потеряны.

Answer 3

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

Письмо непосредственно в файловую систему будет ограничено полосой пропускания, а не записывается в БД, который затем пишет, прямо потому, что БД может - теоретически - писать более эффективными размерами, смежно и в «удобные» времена ,

Answer 4

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

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

Этот журнал в конечном итоге превысил лимит памяти phps и, как таковой, стал узким местом для всего проекта.

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

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

Answer 5

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

Answer 6

Есть более простой способ ответить на этот вопрос. Проанализируйте производительность двух решений.

Создайте одну страницу, которая выполняет вставку БД, другую, которая записывает в файл, а другую, которая не делает ни того, ни другого.В противном случае страницы должны быть одинаковыми. Ударьте каждую страницу с помощью тестера нагрузки (например, JMeter) и посмотрите, что такое влияние на производительность.

Если вам не нравятся номера производительности, вы можете легко настроить каждую страницу, чтобы попытаться оптимизировать производительность или попробовать новые решения ... все от использования MSMQ, поддерживаемого MSSQL, до отложенных вставок в общие журналы для отдельных файлов с работником базы данных БД.

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

Answer 7

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

1. Как указано выше, запись данных в таблицу хоппера, если какая-либо фреймворк поддерживает пакетные вставки, а затем использовать их, это ускорит его. Затем каждый запрос x выполняет слияние (через вызов SP) в главную таблицу, где вы можете нормализовать данные с низкой энтропией. Например, если вы сохраняете HTTP-тип запроса (get/post/etc), это может быть только когда-либо несколько типов и лучше хранить как Int, а также улучшать производительность запросов ввода-вывода +. Ваши мастер-таблицы также могут быть проиндексированы так, как вы обычно делали.

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

Надеются, что это помогает, Ace

Answer 8

Привета из левого поля, но никто не спросил (и вы не указали), насколько важно, чтобы вы никогда, никогда не теряли данные?

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

Answer 9

При работе с РСУБД наиболее важной задачей является оптимизация операций записи на диск. Что-то где-то дошло до флеша() к постоянному хранилищу (дискам) для завершения каждой транзакции, которая ОЧЕНЬ дорогая и требует много времени. Минимизация количества транзакций и максимизация количества записанных последовательных страниц является ключом к производительности.

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

Моя рекомендация - отправлять в очередь сообщения и периодически .. говорить каждые 15 секунд или около того начать транзакцию ... отправить все вложенные вставки ... совершить транзакцию.

Если ваша база данных поддерживает отправку нескольких записей журнала в одном запросе/команде, это может оказать заметное влияние на производительность, когда есть некоторая сетевая латентность между приложением и РСУБД за счет сокращения количества обращений в оба конца.

Некоторые системы поддерживают массовые операции (BCP), обеспечивающие очень эффективный метод для массовой загрузки данных, который может быть быстрее, чем использование запросов «вставки».

Сохранение использования индексов и выбор последовательных первичных ключей.

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

Answer 10

Вы регистрируете больше, чем будут доступны в журналах веб-сервера? Это может быть довольно много, например, Apache 2.0 log information.

Если нет, то вы можете использовать хорошую старую технику буферизации, а затем пакетную запись. Вы можете буферизировать в разных местах: в памяти на вашем сервере, а затем вставлять их в db или пакетную запись в файл каждые X запросов и/или каждые X секунд.

Если вы используете MySQL, существует несколько различных вариантов/методов для эффективного загрузки большого количества данных: LOAD DATA INFILE, INSERT DELAYED и так далее.

Подробные данные на insertion speeds.

Некоторые другие советы включают:

• расщепления данных в разных таблицах за период времени (т.е. в день или в неделю)
• с использованием нескольких DB соединений
• с использованием нескольких БД серверов
• имеют хорошее оборудование (SSD/многоядерный)

В зависимости от масштаба и доступных ресурсов, o разные способы. Поэтому, если вы дадите более подробную информацию, я могу дать более конкретные советы.

Answer 11

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