2014-11-23 4 views
1

У меня есть программа, которая создает журналы, и эти журналы используются для расчета балансов, трендов и т. Д. Для каждого отдельного клиента. В настоящее время я храню все в отдельных таблицах MYSQL. Я связываю все журналы с конкретным клиентом, соединяя эти две таблицы. Когда я обращаюсь к клиенту, он извлекает все журналы из таблицы log_table и генерирует отчет. Отчет зависит от того, какие фильтры установлены, в основном, для даты и категории.PHP массив VS MSQL table

Меня беспокоит производительность моей программы, когда мы накапливаем больше журналов и клиентов. Моя интуиция подсказывает мне хранить информацию журнала в user_table в виде сериализованного массива, поэтому для всего сеанса используется только один запрос. Затем я могу взять этот массив журналов и фильтровать его с помощью PHP, где, как и раньше, он был отфильтрован в запросе MYSQL (с использованием нескольких методов, таких как BETWEEN для дат и других сравнений).

Вопрос: Как вы думаете, производительность будет улучшена, если я использовал сериализованные массивы для хранения журналов, а не для использования таблицы MYSQL для хранения каждого отдельного журнала? Мы оцениваем около 500-1000 журналов на одного клиента, причем около 50000 клиентов (и растут).

+0

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

+0

Я не уверен Я понимаю. В этом случае я использую две таблицы: client_table и log_table. Клиент_таблица имеет идентификатор, который используется для привязки каждого отдельного журнала к соответствующему клиенту. Я надеюсь, что в этом есть смысл. –

+0

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

ответ

0

Похоже, вы не понимаете, что делает базы данных мощными. Речь идет не о «хранении данных», а о «хранении данных способом, который может быть проиндексирован, оптимизирован и отфильтрован». Вы не храните сериализованные массивы, потому что база данных ничего не может с этим поделать. Все, что он видит, представляет собой одну строку без какой-либо структуры, с которой она может иметь смысл работать. Использование этого способа устраняет всю причину даже для использования базы данных.

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

  • Является сериализованным массивом в db быстрее, чем собственный PHP? Нет, конечно нет. Вы заставили базу данных работать как плоский файл с дополнительными служебными данными на dbms.
  • Использует базу данных правильно быстрее, чем собственный PHP? Обычно, да, много.

Плюс, и эта часть важна, это означает, что ваша база данных может жить «в любом месте», в том числе на более быстрой машине рядом с вашим веб-сервером, чтобы ваша база данных могла возвращать результаты в 0,1 с, а не подталкивать PHP 100% -ный процессор, чтобы фильтровать ваши данные и не позволять пользователям вашего сайта получать результаты страницы, потому что вы заблокировали все потоки. На самом деле, по этой причине совершенно бессмысленно сохранять эту задачу на PHP, даже если вы плохо выполняете свою схему и запросы, забудьте о кешировании результатов и последующем поиске внутри этих кешированных результатов, забудьте проиндексировать таблицы на колонках для чрезвычайно быстрого поиска и т. д.

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

0

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

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

Теперь, если у вас есть 10 миллиардов строк, и вы хотите сделать сумму на 10 000 из них, вероятно, было бы более эффективно сохранить эту сумму где-то. Всякий раз, когда новая строка добавляется, удаляется или обновляется, что повлияет на эту сумму, вы также можете изменить эту сумму. Рассмотрим банк, где все элементы в книге хранятся в таблице, но баланс хранится в учетной записи пользователя и не рассчитывается на основе всех транзакций каждый раз, когда пользователь хочет проверить его баланс.

Смежные вопросы