#php #mysql #database #scalability
#php #mysql #База данных #масштабируемость
Вопрос:
Рассмотрим создание PHP-сайта с высоким трафиком и множеством параллельных пользователей. Какая из возможных абстракций MySQL (ORM или СУБД) является наилучшей с точки зрения эффективности (15-20 таблиц базы данных с суммой около 100000 элементов и объединением запросов между не более чем 4 таблицами)?
Где-то я слышал, что библиотеки Doctrine подходят или я должен использовать фреймворк, такой как Zend? Какие из этих решений для баз данных построены поверх PDO и не требуют особого обучения (в настоящее время я использую чистый PHP)?
Комментарии:
1. Вы должны использовать решение, наиболее подходящее для проблемы .
Ответ №1:
Независимо от решения DB, вам следует рассмотреть возможность использования такой системы, как MemCached. При правильной стратегии кэширования вы значительно уменьшите нагрузку, которую ваши базы данных создают на вашем сервере.
Комментарии:
1. APC — еще одно решение для кэша с общей памятью
2. Обновление: APC постепенно прекращается в более поздних версиях PHP (начиная с 5.5). Оно заменяется Zend OPCache, который не поддерживает пользовательское кэширование. Поэтому, если вы думаете, что собираетесь перейти на более поздние версии PHP без необходимости переписывания кода, вам следует подумать о том, чтобы вообще не использовать APC.
Ответ №2:
ORM или любой другой уровень моделирования данных никогда не повысят производительность. Их единственная цель — ускорить время разработки и упростить обслуживание. Они, как известно, плохо справляются с принятием решений, когда дело доходит до фактического правильного использования отношений, и в конечном итоге запрашивают все таблицы, чтобы найти правильные данные. На таком уровне сложных запросов вы не сможете абстрагироваться от этих взаимосвязей без ущерба для производительности.
MySQL подходит как минимум для пары миллионов записей (я использовал его для более чем 100 миллионов в одной таблице). Для повышения производительности обычно требуется иметь хотя бы настройку master / slave и некоторый метод распределения операций чтения между ними. База данных почти всегда будет ограничивающим фактором производительности. Вы всегда можете добавить больше веб-серверов и получить баланс нагрузки перед ними, чтобы решить другую сторону проблемы, но настройка базы данных всегда немного сложнее в обслуживании.
Вы должны подумать о том, почему вы хотите использовать ORM. Если это из соображений разработки, это нормально, но будьте уверены, что ваша производительность пострадает. В противном случае придерживайтесь запросов. ORM добавляет третий уровень кода для работы и изучения. Если вы знаете PHP и MySQL, нужно ли вам изучать третий язык, чтобы эффективно их использовать? Чаще всего ответ отрицательный.
У вас есть много вариантов на выбор, но имейте в виду, что в какой-то момент выбранный вами фреймворк / ORM не будет вести себя так, как вы хотите, и чтобы заставить его вести себя в соответствии с вашими желаниями, вам придется много искать и копаться в коде. Это классическая проблема — сэкономить время заранее и заплатить за него позже или потратить время заранее без возможной отдачи позже.
Комментарии:
1. Спасибо. И каково ваше мнение об этой доктрине решения OODBMS, потому что я читал, что она построена поверх PDO. Является ли Doctrine лучшим решением, чем чистые запросы?
2. С точки зрения чего? Производительность? Нет. Удобство использования? Зависит от вашего мнения. Лично я чувствую себя более комфортно, создавая запросы, чем абстракции объектов, но я недавно использовал CakePHP на работе и понимаю, что это упрощает задачу, когда вам не нужно беспокоиться об этом. Я использовал Doctrine с Symfony, и все в порядке, но в конечном итоге вы все равно пишете псевдо-SQL через их функции, поэтому на этом уровне я в конечном итоге спрашиваю себя: «В чем смысл?». Я уже знаю SQL, поэтому абстрагируюсь от этого, ограничивая запросы, которые я могу написать, просто не помогает.
3. Например:
$items = Doctrine_Query::create()->from('Example e')->leftJoin('e.Foobar')->where('e.id = ?', 20)->execute();vs raw SQL. Если вы знаете SQL, то это просто еще один уровень сложности. Если нет, то, возможно, имеет смысл использовать ORM, пока вы не изучите все тонкости SQL-запросов.4. Как насчет функций кэширования запросов и результатов в большинстве ORM? Я чувствую, что они обычно компенсируют любые накладные расходы, альтернативой является создание собственного
5. MySQL имеет встроенное кэширование запросов, поэтому, опять же, необработанные запросы ВСЕГДА будут работать лучше, чем ORM, если вы знаете, как писать запросы. Если нет, то, вероятно, это промывка. Подумайте также о количестве кода, который необходимо выполнить, чтобы поддерживать эти отношения из набора результатов запроса. Это очень существенное и то, что вы очень мало контролируете. Однако для новичка это было бы вполне адекватно, но я надеюсь, что новичок не сможет создать высокопроизводительное программное обеспечение.
Ответ №3:
Решения ORM смогут оптимизировать некоторые аспекты, если вы кэшируете данные запроса и используете объектный API запланированным и преднамеренным образом.
Базы данных столбцов / документов [nosql: hbase, mongo] повысят производительность, если у вас много (миллионы ) записей, и они все еще растут.
Memcached поможет, если у вас много свободной памяти и особенно если выполняется много повторяющихся запросов.