Jump to content
СофтФорум - всё о компьютерах и не только

хранение данных php-приложения: MySQL vs. файлы


Recommended Posts

В данный момент под моим началом разрабатывается довольно сложная CMS. По этому поводу меня навело на некоторые раздумья недавнее известие о намерении кампании IBM купить кампанию Sun Microsystems с вытекающими отсюда последствиями, в частности то что IBM собирается "задушить" проект MySQL, принадлежащий сегодня Sun, т.к. он является конкурентом IBM DB2.

Разрабатываемая нами CMS ореентирована на российский рынок, а основной СУБД рунета является MySQL. У меня есть опасения, что деньги IBM совместно с законадательством РФ сведет использование MySQL на хостингах рунета до минимума. До получения данной информации, мной планировалось сделать CMS ориентированую на MySQL дабы не нагружать функционал поддержкой многих СУБД. А сейчас сам собой встает вопрос об обратном, в том числе о поддержке DB2, которая на хостингах рунета мною раньше не встречалась :)

Теперь несколько интересных моментов. Размышления привели меня к проведению некоторых экспериментов, в частности я решил произвести замеры быстродействия записи и чтения данных. Тестирование проводилось на ОС Windows XP SP3 и на Infra Linux под обоими ОС стоит одинаковое ПО: Apache 2.2.4 PHP 5.2.4 MySQL 5.0.45

замеры проводились по 5 раз на каждой из ОС, и взяты средние результаты

для замеров использовались одни и те же данные (500 записей), и такие получились средние результаты:

MySQL

Запись: 0.890574932098 сек

Чтение: 0.0270199775696 сек

Текстовый файл (данные писались и читались встроенными функциями php, записи занесены построчно, а поля разделены спец символом)

Запись: 0.0818409919739 сек

Чтение: 0.019228219986 сек

PHP файл (при записи строился php-код добавляющий данные в массив, а вместо чтения файл присоеденялся инклудом)

Запись: 0.0814089775085 сек

Чтение: 0.0270419120789 сек

При чтении самым медленным оказался инклуд, на малозначимые доли секунды его опережает запрос к БД, а вот текстовый файл обогнал их в 1.5 раза. Еще более интересная картина вырисовывается при записи данных, у текстового и php файлов показатели примерно равные, что естественно, так как механизм их записи один и тот же, а вот MySQL работает примерно в 10 раз медленнее. Так почему же большинство php-приложений использует именно БД а не файлы? Неужели только из-за того, что им лень написать аналогичные способы для получения конкретных данных? :)

Вообщем, кто это осилил и имеет на этот счет умные мысли, делимся! :)

Link to comment
Share on other sites

По поводу IBM и MySQL.

Во-первых Sun отказались от сделки.

Во-вторых - задушить MySQL не так уж и просто, тем более что тот же Monty с компанией единомышленников разрабатывают новый движок Maria уже вне MySQL.

Теперь по поводу файлов. Достоверность постановки эксперимента внушает серьезные сомнение по ряду причин:

1. 500 записей - настолько детское число, что даже обсуждать не хочется. Попробуй поработать хотя бы с 50 тысячами записей, 500 тысяч - лучше, 5 миллионов - совсем хорошо. При этом обрати внимание не только на скорость, но и на объем памяти, потребляемой приложением.

2. Подробности ты не расписал, поэтому я попробую предположить как был организован эксперимент:

Запись: только добавление новых записей. Удаление не тестировалось, соответственно при работе с файлами просто добавлялась запись в конец файла.

Чтение: простое последовательное чтение данных из одной таблицы (файла). Максимум - выборка по одному из параметров. Джоины, сортировки, группировки, подзапросы - все лесом.

Типы данных: численные и строковые, может быть дата. LOB и иже с ним скорее всего ушли в игнор.

Все это предположения, если я ошибся - поправь.

Итого: если твоя CMS не использует транзакции, выборки только простые а ля одна таблица и выборка по полю, удаление данных происходит крайне редко, используются только простые типы данных, и все это крутится на объеме порядка 500 записей - работать с файлами будет действительно быстрее.

P.S. Хотелось бы напомнить, что реляционная БД в итоге тоже хранит данные в файлах. Т.е. то, что ты делаешь - это крайне упрощенный аналог БД. И как любой упрощенный узкоспециализированный аналог - такая схема при определенных условиях может работать быстрее. Если же условия меняются, потребности в дополнительном функционале растут, то может обнаружиться, что маленький самодельный фреймворк раздулся до неимоверных размеров и стал причиной дикой боли в заднем проходе разработчиков. После чего приходится выделять много денег: либо на полномасштабную переделку фреймворка, который обычно вследствие родовых травм косметическому ремонту уже не подлежит, либо на замену своего велосипеда сторонним решением. В случае если денег нет - проект умирает. Дай бог, чтобы у руководства хватило ума и смелости, тогда смерть приходит быстро и безболезненно. Иначе - проект гибнет долго, в страшных корчах, причиняя по ходу много страданий своим создателям и тем, кто приходит на место павших в этой неравной схватке двух якодзун.

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

Link to comment
Share on other sites

То что в случае работы большого проекта на файлах придется изобретать велосипед, я осознаю, как и осознаю то что хорошие велосипеды изобретаются не часто.

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

Тогда собственно остается другой вопрос, какой вариант оптимальнее, либо более простая в разработке, и впоследствии более простая в использовании сторонними разработчиками дополнений версия, где только MySQL с таблицами формата MyISAM (самое популярное на сегодня) и никаких других СУБД; или же поддержка большинства существующих сегодня СУБД, а так же возможность дополнять список поддерживаемых СУБД не изменяя координально движка? :D

Link to comment
Share on other sites

Тогда собственно остается другой вопрос, какой вариант оптимальнее, либо более простая в разработке, и впоследствии более простая в использовании сторонними разработчиками дополнений версия, где только MySQL с таблицами формата MyISAM (самое популярное на сегодня) и никаких других СУБД; или же поддержка большинства существующих сегодня СУБД, а так же возможность дополнять список поддерживаемых СУБД не изменяя координально движка?

Вообще-то подобные вещи определяются требованиями к продукту. Но, судя по всему, требований как таковых нет.

Тогда стОит попробовать определиться с аудиторией: кто будет использовать этот движок, сколько у него будет денег, где и как он будет хоститься, при каких условиях его может не удовлетворять MySQL?

Если и с этим определенности не будет - исходи из сроков и бюджета, выделенного на проект.

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

P.S. В свете последних событий смерть MySQL грозит не от DB2, а от Oracle. Но моего мнения это не меняет - задушить подобный проект очень и очень непросто.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...