2013-10-09 2 views
0

Я собираюсь создать веб-проект PHP, который будет состоять из большой базы данных. База данных будет MYSQL и будет хранить более 30000 записей в день. Для оптимизации БД я решил использовать библиотеку MEMCACHED. Я иду правильно, или какая-то другая альтернатива может быть использована для преодоления проблемы оптимизации данных. Я просто хочу обеспечить более быстрый поиск и вставку. Может ли кто-нибудь посоветовать мне, какой инструмент я должен использовать и как, поскольку данные будут постепенно увеличиваться с большей скоростью? Должен ли я использовать концепцию реляционного отображения объектов?Оптимизируйте большую и постепенно увеличивающуюся базу данных

+1

Лучше всего, чтобы попытаться создать несколько тестовых данных на сервер, способный, и посмотреть, как она работает в качестве прототипа. Если вы храните 30 тыс. Записей в день, создайте данные за 6 месяцев и посмотрите, как они работают. Затем попробуйте 12 месяцев и посмотрите, приемлемо ли замедление. Возможно, вы можете заархивировать некоторые из них, когда достигнет определенного возраста? (Кроме того, этот вопрос трудно ответить, поскольку он не очень специфичен). – halfer

+0

ORMs ускоряют процесс разработки и замедляют работу приложения. Мне они нравятся, но вам нужно решить, приемлемо ли компромисс в вашем конкретном случае. – halfer

ответ

1

Для этого можно использовать Master &. В основном это была бы комбинация 2 дБ для операции чтения и другая для операции записи.

0

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

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

Учитывая ваш номер (30k), вы бы усреднили примерно 3 вставки/секунду, которые я бы предположил, что даже самые дешевые машины могут справиться с легкостью. Что касается чтений, то ценность данных за годы должна была составлять чуть менее 11 млн. Записей. Вы можете захотеть разбить данные (уровень mysql или уровень приложения), если поиск будет медленным, но я сомневаюсь, что вам нужно будет с такими относительно небольшими объемами. Реальный разработчик различий будет, если число чтений на 1000 раз больше, чем количество вставок, тогда вы можете посмотреть, что предложили @ram sharma и настроить реплицированную модель master-slave, где мастер принимает все записи, а подчиненные - только для чтения.

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

EDIT: что касается использования ORM, это ваш выбор и на самом деле не изменит ситуацию относительно скорости БД, хотя он может добавить до миллисекунды конечному пользователю. Обычно это стоит того, что я нахожу в своем опыте.

Приветствия -

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