Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 186
Ничего в этом не понимаю, но это круто!
Спасибо :). Но это будет действительно круто, если удастся сделать достаточно быструю реализацию SQL, чтобы была возможность иметь быструю и масштабируемую БД на PHP. Тогда хостеры задумаются над тем, чтобы сделать свои тарифные планы более осмысленными, и предоставлять тот же MySQL на самых дешевых тарифах — ведь иначе есть альтернатива: использовать мою БД, которая, к тому же, работает вполне шустро :).
Еще есть хостеры без поддержки mysql даже на самом дешевом тарифе? Я конечно понимаю, что есть, но не стоит это приводить как аргумент к тому, ради чего делается такая система. Не серьезно это…
Конечно, есть (например: peterhost.ru/plans_domashniy.shtml). Я скажу честно: конечная цель — это сделать возможным работу скриптов, которые требуют MySQL, без наличия этой базы данных. Ну и в качестве альтернативного MySQL движка в случае, если MySQL «упал».
интересно что будет делать альтернативный mysql движок если сервер mysql «упал» :)?
Я имел ввиду использование моей БД для дублирования или кэширования данных скрипта, той же CMS. В случае падения мускула скрипт переходит на альтернативный движок, и продолжает работу. Операции вставки, естественно, нужно производить и в мускул и в мою бд, чтобы была возможность потом эти данные «достать»
Как-то неубедительно звучит. Тормозить свой код дублированием в несколько баз из-за параноидальной боязни отвала MySQL ни кто не будет. Лучше сразу выбросить эту сферу применения из разработки, дабы не тратить свое время понапрасну =)
согласитесь это тупо. вариант использования «в качестве альтернативного MySQL движка в случае, если MySQL упал» предлагаю вычеркнуть.
Можете обосновать (кроме уменьшения производительности)?
существенно увеличивается время разработки. зачем мне этот гемморой? мускуль падает редко. если падает, то скрипт на кроне его поднимает.
ну а если задача серьезная и аптайм критичен, тогда есть другие решения. стоят дороже, но все равно надежность, производительность и функционал во много раз больше чем у движка СУБД на PHP.
а ваше решение подходит для мелких задач. хотя я все же не понимаю чем не угодил sqlite3.
ну а если задача серьезная и аптайм критичен, тогда есть другие решения. стоят дороже, но все равно надежность, производительность и функционал во много раз больше чем у движка СУБД на PHP.
а ваше решение подходит для мелких задач. хотя я все же не понимаю чем не угодил sqlite3.
Занимался раньше хостингом…
Смысл в том, что они не предоставляют mysql на начальных тарифных планах не потому, что жадничают, а просто применение mysql означает определенную нагрузку, а, значит, проект серьёзный и за него надо платить дороже.
На шареде на среднем сервачке с cPanel рядом с вами могут жить еще 100-500 таких же… Можно уточнить в саппорте сколько еще клиентов хостится рядом с вами и разделить мощности сервера поровну — узнаете, сколько дали вам. Если дать mysql всем — все его и будут применять — по сути, самая популярная база для создания сайтов. А если это случится и скажем те же 6 страничек сайта-визитки будут браться из базы, а не просто лежать в .html на диске — возрастёт нагрузка на сервер, в итоге либо придется меньше клиентов класть на сервер, либо у всех начнутся тормоза в часы пик.
Вообщем, я убедился на личном опыте, что нормального хостинга дешевле 7-10 баксов в месяц не бывает — а если там предоставляется mysql — то скорее всего, хостер — новичок или просто демпингует. Точнее, иногда бывает — я сам сейчас такой использую, но это просто по знакомству и, как признается сам хостер — держит этот сервер просто ради фана, без прибыли, а сам уже давно занимается не шаредом, а дедиками (серверы в аренду)…
Кроме того, стоит оценить еще и нагрузку на техподдержку. Как вы думаете, кто больше задаст вопросов — человек, у которого портал на php-mysql или тот, кто просто 6 html страничек? Да, можно использовать sqllite или хранить в файлах — но, согласитесь, это не популярный путь и как правило те, кто идут по этому пути, уже мало нуждаются в техподдержки. Большинство разработчиков-нубов ставят именно попсовые php-mysql движки а-ля Joomla и прочее. Тем самым если каждому дать по mysql и дать это дешево, тут же набегут нубы-халявщики со желанием сделать очередной смехосисечный портал за 3 бакса, завалят техподдержку вопросами и в итоге всем будет только хуже…
Смысл в том, что они не предоставляют mysql на начальных тарифных планах не потому, что жадничают, а просто применение mysql означает определенную нагрузку, а, значит, проект серьёзный и за него надо платить дороже.
На шареде на среднем сервачке с cPanel рядом с вами могут жить еще 100-500 таких же… Можно уточнить в саппорте сколько еще клиентов хостится рядом с вами и разделить мощности сервера поровну — узнаете, сколько дали вам. Если дать mysql всем — все его и будут применять — по сути, самая популярная база для создания сайтов. А если это случится и скажем те же 6 страничек сайта-визитки будут браться из базы, а не просто лежать в .html на диске — возрастёт нагрузка на сервер, в итоге либо придется меньше клиентов класть на сервер, либо у всех начнутся тормоза в часы пик.
Вообщем, я убедился на личном опыте, что нормального хостинга дешевле 7-10 баксов в месяц не бывает — а если там предоставляется mysql — то скорее всего, хостер — новичок или просто демпингует. Точнее, иногда бывает — я сам сейчас такой использую, но это просто по знакомству и, как признается сам хостер — держит этот сервер просто ради фана, без прибыли, а сам уже давно занимается не шаредом, а дедиками (серверы в аренду)…
Кроме того, стоит оценить еще и нагрузку на техподдержку. Как вы думаете, кто больше задаст вопросов — человек, у которого портал на php-mysql или тот, кто просто 6 html страничек? Да, можно использовать sqllite или хранить в файлах — но, согласитесь, это не популярный путь и как правило те, кто идут по этому пути, уже мало нуждаются в техподдержки. Большинство разработчиков-нубов ставят именно попсовые php-mysql движки а-ля Joomla и прочее. Тем самым если каждому дать по mysql и дать это дешево, тут же набегут нубы-халявщики со желанием сделать очередной смехосисечный портал за 3 бакса, завалят техподдержку вопросами и в итоге всем будет только хуже…
Ну, и, плюс к этому, иногда установление соединения — слишком дорогая операция, если Вы хотите выполнить всего 1 запрос. Моя БД в этом случае работает быстрее :).
Есть хостеры с поддержкой MySQL, но с ограничением количества запросов к БД в час. Я как раз с таким столкнулся.
Например, мое приложение может не нагружать сервер даже на 1% (из 15% доступных по тарифу), а вот лишний запрос к БД трижды подумаешь можно ли сделать. Думаю, что в таких случаях доведенная до ума разработка автора была бы весьма полезна для хранения каких-либо дополнительных данных (например, для создания очереди почтовых сообщений, т.к. их тоже нельзя рассылать много за короткий промежуток времени, а лезть за каждым в MySQL — чревато превышением лимита запросов к БД).
Например, мое приложение может не нагружать сервер даже на 1% (из 15% доступных по тарифу), а вот лишний запрос к БД трижды подумаешь можно ли сделать. Думаю, что в таких случаях доведенная до ума разработка автора была бы весьма полезна для хранения каких-либо дополнительных данных (например, для создания очереди почтовых сообщений, т.к. их тоже нельзя рассылать много за короткий промежуток времени, а лезть за каждым в MySQL — чревато превышением лимита запросов к БД).
А теперь дай ответ: кто будет лучше потдерживать СУБД ты или компания MySQL?
Нет такой компании. Есть Sun и Oracle, который её вот-вот купит. И что будет с MySQL — непонятно. Так что тут сложный вопрос :).
Ну то что с ним будет всё впорядке это уж наверника, а за вашу разработку я не уверен, какие у вас планы?
За компанию MySQL простите, у меня была пена у рта когда я писал.
За компанию MySQL простите, у меня была пена у рта когда я писал.
Про MySQL AB вы не слышали? ru.wikipedia.org/wiki/MySQL_AB
Проблема хостера в другом — в том что ограничивать ресурс per-user в MySQL просто нечем. Если добавить такой функционал в MySQL то ето будет предел мечтаний хостера.
Вот ведь времени много бывает у людей свободного =))))
Цель для меня так оказалась и неясна… А вообще каждый уважающий себя программист похожим занятием занимался рано или поздно я думаю.
Цель для меня так оказалась и неясна… А вообще каждый уважающий себя программист похожим занятием занимался рано или поздно я думаю.
Коммерческих целей я не преследую… Я просто был ошеломлён тем результатом, который можно «выжать» базы данных на PHP, так что я решил поделиться этим с сообществом :). Понятно, что каждый этим занимался, вот только не думаю, что кто-то делал БД с поддержкой индексов: в интернете таких движков ведь нет…
Молодцом! :)
Спасибо за карму, перенёс в блог «Я безумный» :).
Вообще вы конечно молодец, что разрабатываете такую вещь. Я думаю очень полезно в плане собственного развития, но вот практической пользы извините не вижу. Не кажется мне, что это (база данных на PHP) действительно может быть востребовано и иметь хоть какое-то серьезное практическое применение. Она по определению не будет быстрее/надежнее/… чем тем же Mysql, SqlLite, Postgre и т д в силу только того, что написана на PHP. Конечно, вы сейчас может и получаете на каких-то тестах хорошие результаты, но это только от того, что пока ваше ядро очень легкое и имеет лишь малый функционал от вышеуказанных СУБД.
Так может лучше применить ваши знания и написать полноценную субд на подходящем для этого языке, которая уже будет составлять какую-то более реальную конкуренцию тому же MySql?
В общем исследовательский труд — это очень здорово, этим в состоянии заниматься далеко не каждый программист. Но еще лучше, когда этот исследовательский труд имеет практическое значение
Так может лучше применить ваши знания и написать полноценную субд на подходящем для этого языке, которая уже будет составлять какую-то более реальную конкуренцию тому же MySql?
В общем исследовательский труд — это очень здорово, этим в состоянии заниматься далеко не каждый программист. Но еще лучше, когда этот исследовательский труд имеет практическое значение
Спасибо К.О.
На самом деле, база данных даже сейчас не такая уж «лёгкая», дело совсем не в этом, ИМХО. PHP может выдерживать подключение достаточно громоздких библиотек без особой потери производительности (благодаря eAccelerator: dklab.ru/chicken/nablas/49.html). Моя библиотека работает быстро (при использовании индексов) благодаря некоторым фундаментальным особенностям архитектуры БД, а не из-за малого количества кода — ведь он исполняется в цикле большое количество раз, и это на самом деле те места, которые нужно оптимизировать. К примеру, используется кэширование дескрипторов файлов, которое позволяет увеличить производительность базы в целом раза в 2, а самих вызовов fopen — раз в 5. Это системные вещи.
Собственно, вся цель разработки БД именно на PHP — показать, что производительность БД может и не ограничиваться интерпретатором PHP, а ограничиваться самой системой и её архитектурой. И производительность будет только увеличиваться, с улучшением архитектуры.
Собственно, вся цель разработки БД именно на PHP — показать, что производительность БД может и не ограничиваться интерпретатором PHP, а ограничиваться самой системой и её архитектурой. И производительность будет только увеличиваться, с улучшением архитектуры.
Нет ни слова про многопользовательский доступ, атомарные операции и транзакции. Без этого базу можно считать легкой.
Все операции с базой — атомарны и нормально работают при одновременном доступе (за исключением очень редких случаев с дублированием UNIQUE индекса, когда база может попортить себе INDEX файлы).
Есть поддержка принудительной блокировки таблицы —
Поддержку транзакций я добавлю, через некоторое время. У меня есть соответствующая библиотека, поддерживающая откат изменений, внесённых в файлы :).
Есть поддержка принудительной блокировки таблицы —
$db->lock_table('table_name');
/* несколько операций с БД, к примеру, продвинутый update таблицы */
$db->unlock_table('table_name');Поддержку транзакций я добавлю, через некоторое время. У меня есть соответствующая библиотека, поддерживающая откат изменений, внесённых в файлы :).
Все операции с базой — атомарны и нормально работают при одновременном доступе
Чем обеспечивается атомарность и корректная работа при параллельном доступе?
Насчёт атомарности я наверное всё же погорячился — если вдруг вырубят электричество во время совершения какой-нибудь операции, то индексы и данные могут попортиться (метод repair() я добавлю через некоторое время). Но в остальном, всё это обеспечивается с помощью файловых блокировок.
Если интересно: при выполнении любого запроса происходит открытие и эксклюзивная блокировка файла со структурой. После того, как запрос выполнится полностью, файл «отпускается», хотя может оставаться заблокированным до конца работы из-за особенностей кэширования дескрипторов
Смысл такой базы очевиден, если требуется реализация простейшего функционала БД. Допустим, авторизация пользователей или гостевая книга. Нагрузки мизерные, используется 2-3-4 простейших селекта/инсерта. Для этих нужд такая база идеальна и продук получается «из коробки» без танцев с бубном с MySQL даже если он на хостинге и присутствует.
Так что труд автора далеко не напрасен.
Так что труд автора далеко не напрасен.
быстрее-проще-надежнее сделать тогда это на файлах или файловых дб, движки которых таки есть в пхп
На самом деле, с движками этих баз часто бывают казусы, ну и, вроде бы, эту поддержку нужно добавлять во время компиляции.
ru.php.net/manual/en/dba.requirements.php
ru.php.net/manual/en/dba.requirements.php
К несчастью для твоей системы она сильно проигрывает этим базам по той простой причине, что они, в отличии от твоей, написаны на С…
Всё зависит от размера БД. Уверен, что на базе в 150 000 записей моя БД будет работать быстрее, если использовать индексы :).
Делай сравнительные тесты и доказывай превосходство своей задумки — другого способа заинтересовать потенциальных помощников в разработке я не вижу =)
А, я наврал :). По сравнению с key=>value database, вроде BDB, моя база конечно будет проигрывать, если её использовать таким же образом. Но если нужны более продвинутые вещи, вроде индексирования нескольких полей, то тут сравнение будет неадекватным, ибо в dba()-функциях такой поддержки нет
Получилось «ни то ни сё».
С одной стороны… такая разработка интересна для не навороченных скриптов, где держать отдельную СУБД смысла нет, но оказывается, что имеющиеся решения будут работать быстрее вашей системы. Сами пишите: «key=>value database, вроде BDB, моя база конечно будет проигрывать». Для мелких скриптов этого хватит.
С другой стороны… ваша система может быть быстрее только с более сложными вещами, а этого, понятное дело, особо не нужно для простеньких скриптов. Опять же ваша цитата: «Но если нужны более продвинутые вещи, вроде индексирования нескольких полей».
Пока так и не могу понять, где применить такое решение.
С одной стороны… такая разработка интересна для не навороченных скриптов, где держать отдельную СУБД смысла нет, но оказывается, что имеющиеся решения будут работать быстрее вашей системы. Сами пишите: «key=>value database, вроде BDB, моя база конечно будет проигрывать». Для мелких скриптов этого хватит.
С другой стороны… ваша система может быть быстрее только с более сложными вещами, а этого, понятное дело, особо не нужно для простеньких скриптов. Опять же ваша цитата: «Но если нужны более продвинутые вещи, вроде индексирования нескольких полей».
Пока так и не могу понять, где применить такое решение.
я думаю гостевой книге похрен на PHP или на C/C++ :). но я бы все равно sqlite заюзал. благо есть дба
sqlite вам в помощь.
А зачем нужен SQL? Ты ведь не собираешься использовать эту БД ни где кроме как в ПХП? Тогда можно обойтись удобным API. В этом случае и работать быстрее будет, поскольку SQL еще и парсить надо, что весьма накладно. Если и поддерживать SQL, то чисто в довесок, а основной упор делать на написание удобных и быстрых функций самых востребованных операций.
Я хочу сделать хотя бы такую возможность, чтобы можно было запускать тот же PhpBB без MySQL, пусть и с потерей производительности.
Врятли это получится. Во-первых, придется поддерживать весь функционал SQL как минимум тот, что использует php (а он его использует весьма обширно). Во-вторых придется убедить разработчиков phpBB реализовать поддержку твоей базы в коде, что весьма и весьма сомнительно.
Я бы пошел именно по пути предоставления сильно упрощенной функциональности SQL, но с максимальной оптимизацией. То есть реализовывать только самые быстрые механизмы БД. Тот же MySQL изначально был сильно урезанным и за счет этого выполнялся очень быстро, хотя и не предоставлял таких возможностей, как, например, Oracle (и сейчас не предоставляет). Тебе нужно идти темже путем, только уже по отношению к MySQL.
Тогда база может найти своего потребителя.
Я бы пошел именно по пути предоставления сильно упрощенной функциональности SQL, но с максимальной оптимизацией. То есть реализовывать только самые быстрые механизмы БД. Тот же MySQL изначально был сильно урезанным и за счет этого выполнялся очень быстро, хотя и не предоставлял таких возможностей, как, например, Oracle (и сейчас не предоставляет). Тебе нужно идти темже путем, только уже по отношению к MySQL.
Тогда база может найти своего потребителя.
> Во-вторых придется убедить разработчиков phpBB реализовать поддержку твоей базы в коде, что весьма и весьма сомнительно.
Почему? Ведь в PhpBB итак уже есть поддержка множества БД, той же PostgreSQL. Если база будет достаточно надёжна и быстра, почему бы им не включить её в дистрибутив, или хотя бы в виде мода?
Почему? Ведь в PhpBB итак уже есть поддержка множества БД, той же PostgreSQL. Если база будет достаточно надёжна и быстра, почему бы им не включить её в дистрибутив, или хотя бы в виде мода?
Поддержка множества? Насколько я знаю 2 или 3 базы всего поддерживается. А движков — десятки. Вот из этого я и сделал вывод, что включить поддержку нераспространенной БД в код phpBB весьма проблематично. И, как мне кажется, модом новую БД к форуму не прикрутишь — нужна модификация ядра. Но тут не уверен — не интересовался.
Так сделайте поддержку вашей СУБД в этой треклятой phpBB и распространяйте в качестве довеска, там же тысяча и один мод (или как там они называются). Я бы всё же поступил, как Вам советуют другие участники дискуссии — если уж делаете быструю базу для «левых» хостингов и нересурсопотребных проектов — но максимизируйте скорости, обёртку для SQL лучше вынести в расширение — если это Ваша самоцель сделать SQL-like СУБД.
Лучше ORM сделайте на основе БД.
От всей души вас поздравляю с результатом и по-доброму завидую вашему мужеству, чести и терпению! ))
Идея интересна, и если проект будет развиваться, то в своей работе обязательно постараюсь подыскать пару интересных, подходящих задачек для вашей бд!
Идея интересна, и если проект будет развиваться, то в своей работе обязательно постараюсь подыскать пару интересных, подходящих задачек для вашей бд!
Как насчёт воспользоваться sqlite? Вы ведь сами в первом абзаце его упомянули.
Если поддержка SQLite есть, то лучше, конечно же, воспользоваться ей :). Но если Вы хотите обеспечить максимальную переносимость своих скриптов, то можно воспользоваться и моей бд, ей никакие расширения пхп не нужны.
>можно воспользоваться и моей бд, ей никакие расширения пхп не нужны
Никакие, кроме самой себя — а это уже достаточно стрёмно.
Вообще задача обеспечить максимальную переносимость требует уточнения. С mysql переносимость уже практически есть, а если и нет — проще и надёжней сменить хостера.
Действительно, лучше энергию куда-то в другое русло направить. То что Вы делаете — не имеет будущего.
Никакие, кроме самой себя — а это уже достаточно стрёмно.
Вообще задача обеспечить максимальную переносимость требует уточнения. С mysql переносимость уже практически есть, а если и нет — проще и надёжней сменить хостера.
Действительно, лучше энергию куда-то в другое русло направить. То что Вы делаете — не имеет будущего.
если я хочу обеспечить максимальную переносимость, то я воспользуюсь ORM или в крайнем случае напишу одну фабрику и ровно один интерфейс, который нужно будет реализовывать
<занудство>
Может все таки вы разрабатываете не БД, а СУБД ;)
</занудство>
Может все таки вы разрабатываете не БД, а СУБД ;)
</занудство>
что у вас с локингом? как лочите файлы/записи?
flock()
лочите всю таблицу? ваша бэда плотно воткнёт при любом параллельном доступе и нетривиальном размере таблицы.
что делаете с удалёнными записями, как высвобождаете место?
что делаете с удалёнными записями, как высвобождаете место?
Да, блокировка всей таблицы :). Также поступает и MySQL для всех движков, кроме InnoDB.
Ничего :). Место не высвобождается. Я планирую добавить список свободных ячеек в будущем, вместе с row splitting. В архитектуре БД такая возможность предусмотрена, так что кода нужно будет написать немного. Вы можете сами посмотреть, собственно :).
P.S. Ну и сама БД не рассчитана на много одновременных пользователей, как и SQLite. Просто есть защита от повреждения данных, не более того.
что делаете с удалёнными записями, как высвобождаете место?
Ничего :). Место не высвобождается. Я планирую добавить список свободных ячеек в будущем, вместе с row splitting. В архитектуре БД такая возможность предусмотрена, так что кода нужно будет написать немного. Вы можете сами посмотреть, собственно :).
P.S. Ну и сама БД не рассчитана на много одновременных пользователей, как и SQLite. Просто есть защита от повреждения данных, не более того.
> сама БД не рассчитана на много одновременных пользователей
я предполагаю, что это станет проблемой даже для не сильно посещаемого форума, с парой-тройкой одновременно активных юзеров. а это как раз и есть ваша ЦА, насколько я понял.
в общем-то, я поддерживаю вас в вашем начинании. практическое применение маловероятно, но экспу прокачать можно :)
парсер sql-я, кстати, можете попробовать взять из мускуля — он там то ли на лексе, то ли на якке написан, может удастся перегнать в пхп.
я предполагаю, что это станет проблемой даже для не сильно посещаемого форума, с парой-тройкой одновременно активных юзеров. а это как раз и есть ваша ЦА, насколько я понял.
в общем-то, я поддерживаю вас в вашем начинании. практическое применение маловероятно, но экспу прокачать можно :)
парсер sql-я, кстати, можете попробовать взять из мускуля — он там то ли на лексе, то ли на якке написан, может удастся перегнать в пхп.
я предполагаю, что это станет проблемой даже для не сильно посещаемого форума
Это какая посещаемость, примерно? Даже если страницы форума будут генерироваться за 0.1 сек, то форум сможет выдерживать 10 посещений в секунду, а это — порядка 700 000 хитов в сутки. Это, кажись, довольно посещаемый форум :).
> если страницы форума будут генерироваться за 0.1 сек
это если будут. а не будут, поверьте мне. все популярные движки, как бы помягче сказать, не очень-то оптимизированы. моя оценка для средних размеров форума, с учётом обстоятельств (шаред хостинг) и движка бэды (ненативный интерпретируемый PHP) — 300-400 мсек.
всё это накроется довольно быстро, и хорошо если можно будет быстренько сменить плогин бд и переехать на нормальную СУБД.
это если будут. а не будут, поверьте мне. все популярные движки, как бы помягче сказать, не очень-то оптимизированы. моя оценка для средних размеров форума, с учётом обстоятельств (шаред хостинг) и движка бэды (ненативный интерпретируемый PHP) — 300-400 мсек.
всё это накроется довольно быстро, и хорошо если можно будет быстренько сменить плогин бд и переехать на нормальную СУБД.
Не хочу вас разочаровывать, но ваша работа полезна только одному человеку — вам лично :) В реальности есть sqlite для хранения данных в фалах, и она поддержвиает и индексы, и SQL (правда у нее ест дурь, она при открытии файла считывает в память все индексы вроде, и как я понимаю, делает это на каждом запросе к старнице, так что старая добрая MySQL остается лучшим вариантом).
Аргумент про дешевые хостинги — имхо неубедителен, 5 сэкономленных долларов не стоят этой возни и тем более переписывния кода приложения (SQL же не поддерживается?). В общем, займитесь уже чем-нибудь полезным. Вот мне например нужен очень быстрый аналог apc_cache/memcached (кеша в памяти с поиском по ключу), только на файлах. Быстрый — значит чтоб работал без считывания в память всего файла и не создавал каталоги с тысячами мелких файлов :)
Ну по крайней мере скиллы автора в пхп и устройстве БД я так думаю неплохо прокачались :)
Аргумент про дешевые хостинги — имхо неубедителен, 5 сэкономленных долларов не стоят этой возни и тем более переписывния кода приложения (SQL же не поддерживается?). В общем, займитесь уже чем-нибудь полезным. Вот мне например нужен очень быстрый аналог apc_cache/memcached (кеша в памяти с поиском по ключу), только на файлах. Быстрый — значит чтоб работал без считывания в память всего файла и не создавал каталоги с тысячами мелких файлов :)
Ну по крайней мере скиллы автора в пхп и устройстве БД я так думаю неплохо прокачались :)
Вот мне например нужен очень быстрый аналог apc_cache/memcached (кеша в памяти с поиском по ключу), только на файлах.
Berkeley DB и аналоги?
Для задач кеша с тегами BDB подходит не лучшим образом, и требует плясок вокруг сборки расширений (для freebsd, как минимум).
А зачем нам теги?)) Для массовой инвалидации ключей часто можно обойтись и без них. У меня просто есть идея сделать что-то вроде fallback-кеша на тот случай когда нормальный недоступен (например shared хостинг), а тупо в файлах информацию хранить не хочется.
Да, кстати в указанных условиях необходимость установки расширений — это тоже проблема.
Да, кстати в указанных условиях необходимость установки расширений — это тоже проблема.
Спасибо, посмотрю.
Не отговаривайте человека (всё «полезное» субъективно).
Было время я тоже реализовывал запросы SQL к собственной БД (точнее к файлам данных). По жизни мне потом всё это пригодилось.
Да и простые задачи, где надобность в MySQL отсутствует, существуют, так что кому то обязательно пригодятся данные наработки.
Было время я тоже реализовывал запросы SQL к собственной БД (точнее к файлам данных). По жизни мне потом всё это пригодилось.
Да и простые задачи, где надобность в MySQL отсутствует, существуют, так что кому то обязательно пригодятся данные наработки.
Я всё же планирую добавить поддержку SQL на уровне, достаточном для работы «средненьких» скриптов (используя диалект MySQL) в том числе и для Joomla, PhpBB и пр.
> займитесь уже чем-нибудь полезным. Вот мне например нужен очень быстрый
> аналог apc_cache/memcached (кеша в памяти с поиском по ключу), только на
> файлах. Быстрый — значит чтоб работал без считывания в память всего
> файла и не создавал каталоги с тысячами мелких файлов :)
Присоединяюсь к пожеланию :)
Писать SQL на php можно только от нечего делать, а задачка про кеш с поддержкой тегов — очень популярная. Если получиться написать быстро работающий кеш с удобным API — такая библиотека реально пригодится очень многим.
В отличие от фигово работающего велосипеда СУБД с собственным диалектом SQL :)
> аналог apc_cache/memcached (кеша в памяти с поиском по ключу), только на
> файлах. Быстрый — значит чтоб работал без считывания в память всего
> файла и не создавал каталоги с тысячами мелких файлов :)
Присоединяюсь к пожеланию :)
Писать SQL на php можно только от нечего делать, а задачка про кеш с поддержкой тегов — очень популярная. Если получиться написать быстро работающий кеш с удобным API — такая библиотека реально пригодится очень многим.
В отличие от фигово работающего велосипеда СУБД с собственным диалектом SQL :)
sphinx на xml разве не это решает?
Наконец-то пхпшники признали, что далеко не всё стоит писать на интерпретируемых языках.
Интересная разработка. Практических применений действительно не так просто придумать. Как мысль — распространение PHP веб-сайта на CD. База данных копируется во временную директорию и работа ведется с ней.
А вот опыт действительно бесценный и выстрелить может в совершенно неожиданном направлении. Скажем написать движок БД на джаваскрипте — чем не идея.
А вот опыт действительно бесценный и выстрелить может в совершенно неожиданном направлении. Скажем написать движок БД на джаваскрипте — чем не идея.
я подумывал о том, чтобы реализовать кеш CMS MODx в бд (сейчас он хранится в serialised-виде).
и для этой задачи разработка автора может хорошо подойти — ну не городить же ради этого огород из двух полноценных баз :)
и для этой задачи разработка автора может хорошо подойти — ну не городить же ради этого огород из двух полноценных баз :)
Это всё — отличная идея для небольших сайтов на php-mysql движках (ну да, бывает в лень делать сайт с нуля, даже из 6 страниц).
Прекрасно было бы, если бы осталась возможность свободного конвертирования в MySQL и из MySQL — тогда это будет прекрасная… эм… вещь для тех кто отлаживает сайты на локальном компе.
Прекрасной идеей было бы сделать возможность по крону синхронизировать вашу базу с какой либо базой в MySQL.
Ещё бы я мог посоветовать связаться с разработчиками популярных CMS или самому сделать совместимость вашей ДБ с Drupal, Joomla и подобными, когда ваша идея будет окончательно воплощена в жизнь.
В общем то — интересно, будем тестить.
Прекрасно было бы, если бы осталась возможность свободного конвертирования в MySQL и из MySQL — тогда это будет прекрасная… эм… вещь для тех кто отлаживает сайты на локальном компе.
Прекрасной идеей было бы сделать возможность по крону синхронизировать вашу базу с какой либо базой в MySQL.
Ещё бы я мог посоветовать связаться с разработчиками популярных CMS или самому сделать совместимость вашей ДБ с Drupal, Joomla и подобными, когда ваша идея будет окончательно воплощена в жизнь.
В общем то — интересно, будем тестить.
А как обстоит дело с одновременной записью?
Да, интересуют такие моменты, как одновременная запись с двух источников, чтение и запись. Как переносит база нагрузки хотя бы при выборке 5-10 различными клиентами?
До этого я видел постоянные упоминания «очень быстрой выборки», потому чтогладиолус индексы. Протестируйте на сотне тысяч строк Вашу СУБД и SQLite к примеру. А потом уже посмотрим — стоит ли игра свеч.
До этого я видел постоянные упоминания «очень быстрой выборки», потому что
Я сранивал с MySQL, и могу сказать, что работает она раз в 10 медленней. Стоит ли игра свеч — я думаю, что всё-таки стоит, потому что на маленьких объемах БД оно работает быстрее мускула за счёт отсутствия необходимости установления соединения с базой, которое может длиться достаточно долго. Но если вдруг база станет большой, то производительность не упадёт до нуля — всё останется вполне работающим :).
Используются файловые блокировки. Причём, в отличие от txtSQL, у меня нет таких глупостей, как
Если Вы читали ман по PHP, то там очень ясно написано, что использовать flock() вместе с w бессмысленно — всё равно данные сначала стираются, а потом уже файл блокируется. То есть, есть шанс потерять содержимое этого файла :).
@fopen($filename.".MYD", 'w') or $this->_error(E_USER_ERROR, 'Error opening table '.$arg['table']);
@flock($fp, LOCK_EX);Если Вы читали ман по PHP, то там очень ясно написано, что использовать flock() вместе с w бессмысленно — всё равно данные сначала стираются, а потом уже файл блокируется. То есть, есть шанс потерять содержимое этого файла :).
И да, совсем забыл — откуда название YNDB?
СУБД на ПХП — такое конечно и в страшном сне не приснится. Но вот если проект будет развиваться в сторону LINQ-подобия — думаю многие скажут вам спасибо.
У нас сейчас идет курс «Обработка запросов в БД». Так вот, написать простейшую СУБД несложно. Это дело месяца. Интерпретировать SQL тоже относительно несложно. Самые сложные части — это когда подключаешь полноценные индексы и непосредственная работа с файлами, построение наилучших планов и т.д. Вообще идея интересная, если бы не на php, то подключился бы.
Проекты смежной направленности (правда, похоже, заброшенные). Возможно, есть смысл поглядеть на то, как у них сделаны некоторые вещи, например, парсер SQL запросов.
sourceforge.net/projects/ffdb-php/
www.c-worker.ch/txtdbapi/index_eng.php
sourceforge.net/projects/ffdb-php/
www.c-worker.ch/txtdbapi/index_eng.php
Кем вам приходится Дмитрий Котеров? :)
Да, уникальная разработка — СУБД для нищебродов.
Чем не угодили sqlite, dbase, dbm?
Чем не угодили sqlite, dbase, dbm?
А вы бы не могла прикрутить свою базу к Wordpress? Тогда бы можно было вещать много сайтов на WP на обычном хостинге.
Очень интересная разработка. Попробуйте посмотреть на Doctrine, там, на сколько знаю, используется библиотека разбора SQL выражения. Заодно и с данной ORM можно поддержку сделать ;)
Честно скажу, не встречал, хотя, в принципе, понимаю, о чём Вы говорите.
Или я не понял мысли, или это пишется в течении получаса-часа самостоятельно.
Возможно, автору требуется масштабируемое решение? Тогда это не пишется за час…
Возможно. Но что значит масштабируемое?
Ему не важно — «как там внутри лягут эти данные».
В простейшем случае решение с file_put_contents() масштабируется неограничено. И таки пишется за час.
Ему не важно — «как там внутри лягут эти данные».
В простейшем случае решение с file_put_contents() масштабируется неограничено. И таки пишется за час.
Масштабируемость любой СУБД, по сути, характеризуется тем, что при увеличении количества данных в 10 раз, время выполнения запроса увеличивается _на_ фиксированную величину. А если тупо записывать и считывать все данные целиком, то время для выполнения запросов будет расти линейно с объемом данных.
А теперь представьте, что нужно обновить единственную запись в 100-метровом файле. Находиться она может потенциально в любом его месте. Вот в таком случае «масштабируемое» означает, что, независимо от того, какого размера таблица, время обновления одной из ее записей будет укладываться в определенный фиксированный интервал времени.
А теперь представьте, что файл у вас может быть не один, не в одном каталоге и даже! не на одной машине.
И в таком случае «масштабируемое» означает лишь наличие денег у вас в кармане для покупки дополнительных дисковых хранилищ. Потому что время доступа к любой записи не растет вовсе.
И все это дает вам банальный file_put_contents().
И в таком случае «масштабируемое» означает лишь наличие денег у вас в кармане для покупки дополнительных дисковых хранилищ. Потому что время доступа к любой записи не растет вовсе.
И все это дает вам банальный file_put_contents().
Я всегда думал, что оптимизировать код дешевле, чем покупать новое оборудование.
применительно к ситуации с обновлением одной строки, file_put_contents() будет хорошо масштабироваться ровно до тех пор пока размер файла не превышает размер блока ФС, а затем начнет работать все медленнее.
применительно к ситуации с обновлением одной строки, file_put_contents() будет хорошо масштабироваться ровно до тех пор пока размер файла не превышает размер блока ФС, а затем начнет работать все медленнее.
Вы плохо думали. Если решение линейно и неограничено масштабируется — дешевле купить оборудование.
На определенном этапе, возможно, вы сможете сделать оптимизацию, но не ранее чем оборудования у вас будет достаточно много, чтобы окупить ее.
Применительно к вашему аргументу… ПК будет хорошо справлятся со своей работой ровно до тех пор, пока у него хватает памяти, затем начнет работать все медленнее :)
Вам еще не кажется что вы говорите чепуху?
При росте среднего объема единичной записи у вас любая система будет работать медленнее. Но предложеное решение по-прежнему будет масштабироваться линейно.
file_put_contents() на RAM диск по скорости будет сопоставим с memcached. Небольшой и простенький демон обеспечит персистентость данных на RAM диске даже при выключении питания.
На определенном этапе, возможно, вы сможете сделать оптимизацию, но не ранее чем оборудования у вас будет достаточно много, чтобы окупить ее.
Применительно к вашему аргументу… ПК будет хорошо справлятся со своей работой ровно до тех пор, пока у него хватает памяти, затем начнет работать все медленнее :)
Вам еще не кажется что вы говорите чепуху?
При росте среднего объема единичной записи у вас любая система будет работать медленнее. Но предложеное решение по-прежнему будет масштабироваться линейно.
file_put_contents() на RAM диск по скорости будет сопоставим с memcached. Небольшой и простенький демон обеспечит персистентость данных на RAM диске даже при выключении питания.
Можно все же услышать, что именно «внятного» требуется? Видимо выходные сказываются и я не понимаю, что конкретно вам не хватает.
Если вы хотите автогенерацию БД на базе свойств объектов (или ключей массива) — это одно.
Если вы хотите просто хранить сериализованные объекты/массивы (которые в сериализованном виде ничем друг от друга не отличаются и не требуют специальных схем данных) — это другое.
Если вы хотите автогенерацию БД на базе свойств объектов (или ключей массива) — это одно.
Если вы хотите просто хранить сериализованные объекты/массивы (которые в сериализованном виде ничем друг от друга не отличаются и не требуют специальных схем данных) — это другое.
Откровенно говоря не встречал. Наиболее близко к тому что пишете это ORM вроде Doctrine/Propel.
А MongoDB на первый взгляд похож на key-value хранилище.
Просто при автогенерации встает вопрос связей. Вам их придется указывать явно где-то в коде для автогенерации.
Или же реализовывать все связи программно.
В противном случае мы получим лишь набор таблиц доступных исключительно по key-value.
А такой вопрос, в связи с чем возникло желание runtime автогенерации? Исходя из моего личного опыта это один из симптомов лени при недостаточно опыте :) или необходимости EAV.
А MongoDB на первый взгляд похож на key-value хранилище.
Просто при автогенерации встает вопрос связей. Вам их придется указывать явно где-то в коде для автогенерации.
Или же реализовывать все связи программно.
В противном случае мы получим лишь набор таблиц доступных исключительно по key-value.
А такой вопрос, в связи с чем возникло желание runtime автогенерации? Исходя из моего личного опыта это один из симптомов лени при недостаточно опыте :) или необходимости EAV.
Посмотрел, да, пожалуй, ближе к CouchDB.
Если лень — то это пройдет :)
Посмотрите в сторону Doctrine. YAML очень прост.
User:
columns:
id:
primary: true
autoincrement: true
type: integer(4)
username: string(255)
password: string(255)
relations:
Groups:
class: Group
refClass: UserGroup
foreignAlias: Users
www.doctrine-project.org/documentation/cookbook/1_1/en/my-first-project
Все нужные классы для PHP и таблицы для СУБД она создаст сама.
Если лень — то это пройдет :)
Посмотрите в сторону Doctrine. YAML очень прост.
User:
columns:
id:
primary: true
autoincrement: true
type: integer(4)
username: string(255)
password: string(255)
relations:
Groups:
class: Group
refClass: UserGroup
foreignAlias: Users
www.doctrine-project.org/documentation/cookbook/1_1/en/my-first-project
Все нужные классы для PHP и таблицы для СУБД она создаст сама.
1. ezpdo — не проще и не легче в работе, чем Doctrine. Просто немного разная идеология — вместо централизованного хранения информации о структуре(Doctrine) и автогенерируемых моделей, мы ее раздергали по моделям(ezpdo), которые нам приходится писать руками (как я это ненавижу :)
В сухом остатке набирать кода надо больше для ezpdo.
2. Я начинал как-то писать такой слой абстракции, который начиная с EAV разворачивал систему в денормализованые таблицы, там где это было нужно. Но… овчинка выделки не стоит.
Поясню почему — во-первых, постоянный профайлинг — замедляет работу и существенно.
во-вторых, автоматическое решение всегда оказывалось хуже ручной оптимизации.
в-третьих, мне не удалось полностью исключить вмешательство человека на конечной стадии принятия решений (продолжать оптимизировать, или удовлетвориться достигнутым).
Как итог — осталась идея экспертной системы, для точечных оптимизаций на уже готовых наборах данных.
Но не runtime решение.
В сухом остатке набирать кода надо больше для ezpdo.
2. Я начинал как-то писать такой слой абстракции, который начиная с EAV разворачивал систему в денормализованые таблицы, там где это было нужно. Но… овчинка выделки не стоит.
Поясню почему — во-первых, постоянный профайлинг — замедляет работу и существенно.
во-вторых, автоматическое решение всегда оказывалось хуже ручной оптимизации.
в-третьих, мне не удалось полностью исключить вмешательство человека на конечной стадии принятия решений (продолжать оптимизировать, или удовлетвориться достигнутым).
Как итог — осталась идея экспертной системы, для точечных оптимизаций на уже готовых наборах данных.
Но не runtime решение.
Похожим образом, кстати, реализован persistence в Google DataStore. Класс и его свойства содержат аннотации, указывающие как что хранить.
Мне как закостенелому SQL-щику это кажестя странным, хотя я понимаю, что с точки зрения нормальных разработчиков так лучше :-)
Мне как закостенелому SQL-щику это кажестя странным, хотя я понимаю, что с точки зрения нормальных разработчиков так лучше :-)
Кому что удобнее. Это уже больше вкусовые предпочтения.
Просто лично я, хотел бы избежать даже вот такого
/**
* Class of a book
* @orm mysql://dbuser:secret@localhost/ezpdo
*/
class Book {
/**
* @orm char(64)
*/
public $title;
}
В общем, чем меньше я нажимаю клавиши, тем больше я доволен :)
А почему конфиги это зло я не понял :(
Просто лично я, хотел бы избежать даже вот такого
/**
* Class of a book
* @orm mysql://dbuser:secret@localhost/ezpdo
*/
class Book {
/**
* @orm char(64)
*/
public $title;
}
В общем, чем меньше я нажимаю клавиши, тем больше я доволен :)
А почему конфиги это зло я не понял :(
Ммм. Фокус в чем.
Поскольку для юнит-тестирования достаточно рассмотреть пару типичных случаев и предельные варианты.
То оптимизация на юнит-тестах это бред. Причем полнейший :(
Оптимизировать можно и нужно только на реальных данных взятых из продакшена.
Поскольку для юнит-тестирования достаточно рассмотреть пару типичных случаев и предельные варианты.
То оптимизация на юнит-тестах это бред. Причем полнейший :(
Оптимизировать можно и нужно только на реальных данных взятых из продакшена.
Интересная разработка, вот только делать поддержку SQL, я думаю, смысла нет.
Из вашей разработки может получится отличная объектная база на пхп, узкие места потом можно оптимизировать, написав библиотеку в качестве расширения к пхп, но для начала надо чтобы всё работало как часы:)
Из вашей разработки может получится отличная объектная база на пхп, узкие места потом можно оптимизировать, написав библиотеку в качестве расширения к пхп, но для начала надо чтобы всё работало как часы:)
Работа с Б-деревьями на данный момент является узким местом :). Но я всё же хочу обойтись без расширений PHP, иначе смысл теряется: ведь есть уже SQLite и BDB-подобные движки, соперничать с которыми я пока что не готов :).
А что касается работы, как часы — она и сейчас работает достаточно надёжно. Просто нет некоторых важных возможностей, вроде обновления текстовых полей с увеличением их длины (для этого требуется делать row splitting, что довольно муторно).
А что касается работы, как часы — она и сейчас работает достаточно надёжно. Просто нет некоторых важных возможностей, вроде обновления текстовых полей с увеличением их длины (для этого требуется делать row splitting, что довольно муторно).
Понятно :)
Хорошо было бы внести понятие схем — описываете объекты которые участвуют в системе, а ваш компонент сам разбирает как их хранить. Потом просто работаете с объектами и их коллекциями.
Потом можно сделать обёртки над коллекциями и объектами, которые будут исходя из описаний делать формы и гриды для работы. Таким образом, получаем что-то типа phpmyadmin для вашей объектной базы.
Будет весело и интересно, ручаюсь :)
Хорошо было бы внести понятие схем — описываете объекты которые участвуют в системе, а ваш компонент сам разбирает как их хранить. Потом просто работаете с объектами и их коллекциями.
Потом можно сделать обёртки над коллекциями и объектами, которые будут исходя из описаний делать формы и гриды для работы. Таким образом, получаем что-то типа phpmyadmin для вашей объектной базы.
Будет весело и интересно, ручаюсь :)
На каком-то простом уровне, может выглядеть примерно вот так:
http://pastebin.ru/306928
http://pastebin.ru/306928
Следующий этап — СУБД на Javascript. С индексами на куках.
Автор этого проекта твёрд и решителен, но вызывает некоторое сожаление — словно летящий лом, брошенный мимо цели.
Чувак, ты крут. Хочу помочь тебе с SQL (я сам когда-то пытался сделать подобное, но задумка умерла на начальном этапе реализации, вроде осталось немного наработок). SQL я люблю, благо с mysql и oracle есть хороший опыт в этой области.
Когда я сам подумывал начать разрабатывать СУБД на PHP (тоже просто так из спортивного интереса), я расчитывал, что она будет реализовывать единый SQL-интерфейс доступа к разнородным данным, хранящимся в плоских файлах, в других СУБД, в книгах Excel, на вебе и т.п.
Одно из применений в таком случае, например, это упрощение реализации процессов ETL. Представим на минуточку, что станет возможным быстрое написание следующих сценариев:
где $date_yesterday — переменная PHP. Хотя, да, я знаю про существование Oracle HS, плюс, наверняка, существуют и другие решения. но пускай «цветут сто цветов» (с)
Когда я сам подумывал начать разрабатывать СУБД на PHP (тоже просто так из спортивного интереса), я расчитывал, что она будет реализовывать единый SQL-интерфейс доступа к разнородным данным, хранящимся в плоских файлах, в других СУБД, в книгах Excel, на вебе и т.п.
Одно из применений в таком случае, например, это упрощение реализации процессов ETL. Представим на минуточку, что станет возможным быстрое написание следующих сценариев:
insert into mysql.fact_table1 (col_date, col1, col2, col3, col4)
select col_date, col1, col2, col3, col4 from oracle.some_table1
where col_date >= $date_yesterday
union all
select col_date, col1, col2, col3, col4 from csv.some_table2
where col_date >= $date_yesterday;
delete from mysql.dim_table1;
insert into mysql.dim_table1 (col1, d1, d2)
select col1, d1, d2 from webxml.some_table3;
commit;
где $date_yesterday — переменная PHP. Хотя, да, я знаю про существование Oracle HS, плюс, наверняка, существуют и другие решения. но пускай «цветут сто цветов» (с)
Кстати, автор часто упоминает индексы, и возросшую при их применении производительность. Однако, стоит понимать, что существование индексов могут ускорить работу SELECT (и то, далеко не всех) за счет существенного снижения скорости работы DML.
Похожий эффект на производительность СУБД имеют ограничения целостности (CONSTRAINT), которые тоже являются одной из важнейших компонент БД.
Похожий эффект на производительность СУБД имеют ограничения целостности (CONSTRAINT), которые тоже являются одной из важнейших компонент БД.
Ребят, есть одно немаленькое практическое приложение такой СУБД. У гугла есть отличный хостинг Appspot. Думаю не стоит рассказывать о его прелестях. Но проблема в том, что он пока не поддерживает РНР. Наши западные коллеги догадались, как там запускать РНР интерпретатор, написанный на поддерживаемой гуглом яве. Но тут всплывает второй неприятный момент: хоть сам интерпретатор поддерживает MySQL, то аппспот его не поддерживает. У них есть своя СУБД, с которой тоже можно работать, но нужно хорошенько в нее вгрызстся. А с СУБД на чистом РНР я думаю не возникнет никаких проблем с переносимостью кода, типа «локальный сервер с РНР -> обычный хостинг -> Google appspot».
Есть, кстати, реализации BDB на Java — www.oracle.com/database/berkeley-db/je/index.html. Производительность — сумасшедшая :).
Я просто не совсем хочу вмешивать Яву в РНР. Посему решение на чистом РНР более предпочтительно.
Да, в таком случае, если БД будет «нормальной», такой подход может иметь право на жизнь :).
Я к тому, что на моем компе у меня родной, зендовский интерпретатор, на котором эти Явовские фишки не пройдут. А пишу я именно под этот интерпретатор. А уже на гугле явовский. Посему именно чисто РНРое решение.
Вот кстати и какой никакой, а вектор приложение усилий — в сторону адаптации именно под гугл аппспот. И вполне очевидная практическая польза.
У них BigTable — это тот еще ад. Как я видел в одной из презентаций на эту тему: «BigTable is not an RDBMS». Этим все сказано. В данном случае, конечно, решение сильно нишевое (да и кто сказал, что оно будет работать? разве в AppEngine разрешена работа с файлами вообще?), но легкая переносимая СУБД на языке, который используется буквально всюду, однозначно надет свое применение.
Вы — молодец. Я поддерживаю ваше начинание
Есть баг — если инклюдить внутри функции — лимиты по дефолту не проставляются и выдается пустой массив по селекту.
$LIMIT_START = 0;
$LIMIT_LEN = 30;
надо поменять на
$GLOBALS[LIMIT_START] = 0;
$GLOBALS[LIMIT_LEN] = 30;
$LIMIT_START = 0;
$LIMIT_LEN = 30;
надо поменять на
$GLOBALS[LIMIT_START] = 0;
$GLOBALS[LIMIT_LEN] = 30;
Я сделал проще — заменил переменные на константы с похожими именами :). Я как-то не предполагал, что кто-то будет из функции инклюдить мой класс… __autoload, чтоли?
Все изменения я пока что вношу в ветку SQL-0.0.1: code.google.com/p/yndb/source/browse/#svn/branches/SQL-0.0.1, её можно забрать с SVN.
Спасибо за багрепорт :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Движок СУБД на PHP