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

[Ф@РТОВЫЙ]

В данный момент под моим началом разрабатывается довольно сложная 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-приложений использует именно БД а не файлы? Неужели только из-за того, что им лень написать аналогичные способы для получения конкретных данных? :)

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

[Shurr]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Ф@РТОВЫЙ]

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

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

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

[Shurr]

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

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

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

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

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

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