PHP / MYSQL - толкать его до предела?

Question

Я уже некоторое время кодирую php и довольно крепко держу его, MySQL, ну, скажем так, я могу заставить его работать.

Я хотел бы создать скрипт статистики, чтобы отслеживать статистику других сайтов, аналогичную очевидному statcounter, google analytics, mint и т. Д.

Мне, конечно, хотелось бы правильно закодировать это, и я не вижу, чтобы MySQL нравилось от 20 000 000 до 80 000 000 вставок (925 вставок в секунду "примерно **") ежедневно.

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

Я на правильном пути? Мне просто нужно нажать в правильном направлении, причем это способ вдыхать 1000 псевдо «MySQL» вставок в секунду и правильный способ сделать это.

Пример вставки: IP, time (), http_referer и т. Д.

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

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

Answer 1

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

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

Начните с установки примера схемы с точки зрения ТОЧНОЙ информации, которую вам нужно хранить, и при этом вы сами (через пересмотры) проведете к тому, что будет работать для вас.

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

Answer 2

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

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

MySQL предлагает способ отделить это; это называется INSERT DELAYED. По сути, вы говорите базе данных «вставьте эту строку, но я не могу остаться, пока вы это делаете», а база данных говорит: «Хорошо, я получил вашу строку, я вставлю ее, когда у меня будет минута». Вполне возможно, что это уменьшает проблемы с блокировкой, поскольку позволяет одному потоку в MySQL выполнять вставку, а не к тому, к чему вы подключаетесь. К сожалению, он работает только с таблицами MyISAM.

Другое решение, которое является более общим решением проблемы, состоит в том, чтобы иметь демон регистрации, который принимает вашу информацию регистрации и просто помещает ее в очередь, куда бы она ни шла. Хитрость в том, чтобы сделать это быстро, это шаг в очереди. Такое решение может предоставить syslogd.

Answer 3

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

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

Это дает меньший удар по производительности для ведения журнала и хорошо проиндексированную нормализованную структуру для запросов / анализа.

Answer 4

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

1. Вам нужно будет регулярно разбивать вашу таблицу аудита (ежечасно, ежедневно?), Если не что иное, чтобы вы могли отбросить старые разделы, чтобы разумно управлять пространством. УДАЛЕНИЕ 10М строк не круто.
2. Ваши веб-серверы (поскольку у вас будет довольно большая ферма, верно?), Вероятно, захотят выполнять вставку большими партиями асинхронно. У вас будет процесс-демон, который читает журналы с плоскими файлами на компьютере с веб-сервером и объединяет их в пакеты. Это важно для производительности InnoDB и во избежание замедления аудита веб-серверов. Более того, если ваша база данных недоступна, ваши веб-серверы должны продолжать обслуживать веб-запросы и по-прежнему проверять их (в конечном итоге)
3. Поскольку вы собираете большие объемы данных, потребуется некоторое суммирование для того, чтобы сообщить об этом с разумной скоростью - то, как вы это делаете, во многом зависит от вкуса. Делайте разумные выводы.
4. Настройка двигателя InnoDB - вам нужно будет значительно настроить двигатель InnoDB - в частности, взгляните на переменные, управляющие его использованием очистки диска. Записывать журнал для каждого коммита не будет круто (возможно, если он не на SSD - если вам нужна производительность И долговечность, рассмотрите SSD для журналов) :) Убедитесь, что ваш буферный пул достаточно большой. Лично я бы использовал плагин InnoDB и опцию «файл на таблицу», но вы также можете использовать MyISAM, если полностью понимаете его характеристики и ограничения.

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

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

Не забудьте протестировать все это на оборудовании производственной спецификации (мне не нужно вам об этом говорить, верно?).

Answer 5

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

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

Answer 6

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

Это добавило бы некоторую сложность. Вы проверяли или рассматривали тестирование с регулярными запросами? Т.е. увеличить счетчик с помощью запроса UPDATE (потому что вам не нужна каждая запись в отдельной строке). Вы можете обнаружить, что это не так сильно тормозит, как вы думали, хотя, очевидно, если вы запускаете 80 000 000 просмотров страниц в день, у вас, вероятно, совсем нет места для маневра.