MYSQL Performance - PullRequest
       17

MYSQL Performance

1 голос
/ 31 июля 2009

Я пытаюсь разработать приложение с карточкой времени. Так что на каждый месяц будет 30 или 31 день. (с полями AM-IN, AM-OUT, PM-IN, PM-OUT и т. д.), который является VARCHAR (4500) в mysql

Моя идея - сохранить данные за один месяц (30 дней) в одной строке в базе данных. Я храню данные за 30 дней в формате XML. поэтому при извлечении выбирается только одна строка.

Все идеально. Работает отлично.

Клиент ожидает, что 1 миллион пользователей будут использовать эту временную карту. Теперь проблема возникает, когда я создал данные о стрессе. Я создал данные о стрессе для 1 миллиона пользователей за 3 года. Создано ровно (1 миллион * 12 месяцев * 3) числовых рядов. Приложение работает нормально. Но когда я вижу использование диска, эта таблица потребляет 50 ГБ. Я уверен, что это потребление 50 ГБ из-за VARCHAR (4500). Если я разбью его на отдельные столбцы, этого вопроса не будет.

Вот мой вопрос. Если я разделю тайм-карту VARCHAR (4500) на отдельные поля, я буду хранить строки для каждого дня. Таким образом, количество сохраненных строк будет (1 миллион * 12 месяцев * 30 дней * 3)

В режиме реального времени (10 000 пользователей параллельно получают доступ к этой странице карты времени) Будет ли tomcat + mysql обрабатывать 10 000 параллельных запросов (я имею в виду выборку 30 записей за удар)?

Какой модал данных использовать 1) Хранение данных за 1 месяц в одной строке
или же 2) Хранение данных за 1 месяц в 30 строках?

Ответы [ 3 ]

1 голос
/ 31 июля 2009

ИМХО Я бы пошел с вашей 2-й моделью данных. (Число строк в день данных) Разбивка данных на отдельные столбцы имеет больше смысла и позволит вам улучшить проверку данных, индексацию, эффективность и т.д. можно свернуть разделы на обратной стороне таблицы основных данных и сохранить их либо в более дешевом хранилище, либо экспортировать в файл, как предложено Италией. Это должно держать вашу таблицу в управляемом размере и обеспечить лучшую производительность запросов. Я рекомендую ознакомиться с различными вариантами подсистемы хранения, которые есть у MySQL, поскольку их аспекты реализации могут значительно изменить производительность в зависимости от необходимой вам пропускной способности.

0 голосов
/ 31 июля 2009

В случае реального времени (10 000 пользователей параллельно обращаются к этой странице карты времени) tomcat + mysql может обрабатывать 10 000 параллельных запросов (я имею в виду выборку 30 записей за удар)?

Нет, производительность зависит от уровня кэширования, если каждый пользователь имеет доступ к своей карте каждый раз (абсолютно случайно) и у вас есть 50 ГБ БД, поэтому вы будете ограничены диском, и нет, вы не сможете ни в коем случае извлекать записи 10 КБ в одну секунду из разных мест на диске.

С другой стороны, 99,9% пользователей имеют доступ только к последним записям, поэтому 50/12/3 ~ = 1,5 Г часто доступ к данным, поэтому они хранятся в кэш-памяти, у вас может быть возможность получать 10K запросов на пользователя на компьютере с большим количеством памяти и процессоров, но я не думаю, что вы можете сделать это в параллельные запросы, потому что MySQL имеет поток на соединение.

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

РЕДАКТИРОВАТЬ в любом случае, если вы попытаетесь сохранить только данные ключа / значения без дополнительной индексации, я бы предложил выбрать что-то более простое, чем полная реляционная база данных, взгляните на http://memcachedb.org/, или отдельное архивное хранилище и хранилище, которое можно обновить - потому что хранилище, которое не обновлено, может храниться по-другому.

0 голосов
/ 31 июля 2009

Какой модал данных использовать 1) Хранение 1 данные за месяц в одной строке или 2) Хранить данные за 1 месяц в 30 строках?

Сохраните текущий месяц так, чтобы он был самым быстрым.

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

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