Форум dkLab и Denwer

[Юрий Насретдинов]

Не всегда есть желание и необходимость ставить базы вроде MySQL, а производительность у SQLite тоже не блещет. Касательно работы веб-сервера, моя база расширения SQLite не требует (у меня на сервере его например не стоит). Так что, не знаю...

[nerezus]

> у меня на сервере его например не стоит
А в чем проблема поставить его или мускул тот же, раз есть свой сервер?)

[Юрий Насретдинов]

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

Также, иногда бывает, что база данных вроде мускула "падает" или достигается лимит подключений к ней. И мою БД можно использовать в качестве "запасного варианта", а не придумывать свою реализацию для хранения информации какую-то самодельную БД, ибо моя база достаточно легко справляется с базой, сопоставимой по размерам с базой этого форума и масштабируется далее. Чего нельзя сказать про всякие "plain text" базы, которые обычного первыми приходят на ум разработчикам своих форматов хранения информации в БД. Ну и база сама гарантирует, что данные не будут повреждены при одновременном доступе, что тоже не всегда так для самодельных скриптов.

[Melethron]

А как решена проблема при одновременном обращении к таблице?

[Юрий Насретдинов]

Melethron
Блокировки.

php.net/flock

[Юрий Насретдинов]

После достаточно долгого «застоя», была переделана система индексов, теперь вместо двоичного дерева используется B-Tree, которое, помимо серьёзного сокращения количества обращений к диску, также является само-балансирующимся. Помимо всего прочего, этот факт означает независимость среднего (а также максимального) времени поиска в индексе от порядка поступления данных и от характера самих данных. Время поиска в Б-дереве составляет log_L(N), где L в данной реализации составляет 85. То есть, если в индексе хранится 85 записей, время поиска условно будет 1, если 7000, то 2, 600 000 -- 3 и т.д. На данный момент реализована лишь операция вставки в Б-дерево (помимо поиска, конечно же), но даже этого достаточно для существенного увеличения производительности (поскольку двоичное дерево, использованное ранее, при поступлении отсортированных данных вырождается в список, увеличение производительности в процентном соотношении может быть произвольным, я лично наблюдал увеличение производительности на примере форума в ~5 раз).

Для UNIQUE индексов используется Б-дерево в чистом виде (и обладает наибольшей производительностью)
Для INDEX используется комбинация Б-дерева и списков (для хранения повторяющихся значений). Поскольку для дублирующихся значений используется внешний список, производительность как поиска, так и вставки может сильно упасть, если повторяющихся значений слишком много (крайне желательно иметь их не больше 100, на количестве значений порядка 1000 можно наблюдать значительное падение производительности).

В выложенной версии напрочь отсутствует реализация update и delete (их код полностью:

Code (php):	скопировать код в буфер обмена
public function update()         {                 return $this->set_error('Update: unsupported operation');         }                 public function delete()         {                 return $this->set_error('Delete: unsupported operation');         }

).

Это связано с переходом на другую структуру хранения индексов (обратно несовместима с предыдущей!) и дальнейшая работа будет направлена на добавление такой поддержки. Текущая реализация занимает в сумме (4 файла) 35 Кб.

Для желающих, как и в прошлые разы, доступна сконвертированная база форума.дклаб (и самописный форум) для получения представления о масштабируемости моей БД (с учетом того, что она полностью на PHP, время открытия большинства тем с сообщениями не превышает 0.1-0.05 сек). База данных и онлайн-пример доступны по требованию (пишите в ЛС).

---

YNDb-latest.zip
Description:	Данный код приводится для ознакомления и не рекомендуется к использованию в важных проектах, несмотря на то, что ошибок в реализации быть не должно.	Download
Filename:	YNDb-latest.zip
Filesize:	10.76 KB
Downloaded:	723 Time(s)

---

[Юрий Насретдинов]

Добавлена первичная поддержка удаления из Б-дерева (возможны проблемы при удалении сразу всех значений, а также возможно образование «мертвых блоки», на которые нет ни одной ссылки, при удалении количества значений порядка L^2 (около 7000)). После удаления значения из Б-дерева оно не балансируется; место, которое занимает Б-дерево на диске, также не возвращается обратно, но может быть повторно использовано, если количество удаленных записей было не слишком велико.

Благодаря введению такой поддержки, операции update() и delete() добавлены обратно (обновление значения в индексе происходит в 2 этапа: удаление старой записи, а потом вставка новой), полностью переписанные, но с теми же недостатками, что и раньше -- невозможность увеличивать длину хранимых строк, невозвращение использованного места под запись в БД, отсутствие механизма повторного использования места из удаленных записей.

Функция update() также может испортить индексы, если вы вставляете записи со значениями для UNIQUE и PRIMARY KEY полей, которые уже существуют в базе. Функция корректно возвратит ошибку «Duplicate unique/primary key», но часть индексов может к тому времени уже быть обновлена, что и вызовет порчу индекса. Сами данные при этом не портятся.

При обновлении значений INDEX полей (а также при удалении значений из INDEX полей) остаются «пустые места» в индексе, которые не используются повторно.

Количество кода заметно подросло (56 Кб), в основном за счет комментариев и отладочного кода.

TODO:

1. перевод primary key на использование Б-дерева (появится возможность вставлять «свои» значения в индекс, возможность вставки значений, превышающих текущий auto_increment)
2. более прозрачный механизм блокировки таблиц, добавление команды наподобие LOCK TABLES в MySQL (может существенно увеличить производительность вставки в БД, а также обеспечить атомарность операций, которые отсутствуют по тем или иным причинам в БД, к примеру, расширенной операции update или собственной реализации аналога REPLACE в MySQL)
3. расширить синтаксис update(), чтобы он мог атомарно модифицировать значения в нужной записи, в том числе и основываясь на предыдущем значении, записанном в БД, аналог запроса "UPDATE ... SET some_counter = some_counter + 1 WHERE ..." в MySQL
4. модифицировать методы insert() и update() таким образом, чтобы они не могли ввести БД в противоречивое состояние, когда файлы индексов не соответствуют данным
5. аналог REPAIR TABLE для проверки целостности хранимых данных и, в случае чего, исправления ошибок
6. аналог OPTIMIZE TABLE для устранения «пробелов» между записями, а также для перестройки индекса с той же самой целью
7. аналог ALTER TABLE для изменения структуры таблицы, в которой уже есть данные
8. <b>!important:</b> написание совместимого с синтаксисом MySQL парсера языка SQL для основных методов -- CREATE TABLE, INSERT, SELECT, UPDATE. В SELECT также постараться включить возможность использования JOIN'ов, хотя бы одного типа (LEFT JOIN).

---

YNDb-latest.zip
Description:	Код представлен для ознакомления с реализацией. На данном этапе использование в качестве полноценной замены MySQL не рекомендуется. Буду очень признателен за тестирование и нахождение багов в реализации, особенно при операциях с индексированными полями.	Download
Filename:	YNDb-latest.zip
Filesize:	14.43 KB
Downloaded:	709 Time(s)

---

[Юрий Насретдинов]

За счёт добавления нового «класса» rfio.php (forum.dklab.ru/viewtopic.php?t=34763) и перевода большинства операций записи на использование обратимых файловых операций, операции update() и insert() теперь ведут себя корректно (впрочем, всеобъемлющего тестирования я не проводил, так что возможно, в некоторых случаях, они всё-таки могут что-нибудь испортить) при добавлении или обновлении записей, которые содержат дубликаты PRIMARY KEY или UNIQUE полей.

Также добавлено 2 метода: lock_table($name) и unlock_table($name) соответственно. Они блокируют таблицу для осуществления атомарных операций. Например, это позволяет сделать «кустарную реализацию» аналога запроса UPDATE ... SET counter=counter+1 WHERE ... в MySQL:

Code (php):	скопировать код в буфер обмена
$db->lock_table('stats'); list($res) = $db->select('stats', array (www.php.net/array)('cond' => 'id = 35')); $res['counter']++; $db->update('stats', array (www.php.net/array)('cond' => 'id = 35'), $res); // если Вы забудете разблокировать таблицу, ничего страшного не случится, но в случае параллельного доступа к этой таблице людям придётся подождать... $db->unlock_table('stats');

Также блокировка таблицы перед тем, как выполнить много операций, к примеру, вставки в БД может увеличить её производительность в ~1.5 (при использовании всех возможных индексов) раза. Если Вы не используете индексы, то увеличение производительности может быть ещё большим.

---

YNDb-latest.zip
Description:	Содержит файлы с базой данных (основной класс YNDb и пара дополнительных), а также файлы для тестирования БД (test*.php)	Download
Filename:	YNDb-latest.zip
Filesize:	21.22 KB
Downloaded:	660 Time(s)

---

[Александр Михалицын]

Юр, а как ставить твой форум без скачивания готовой базы? Можешь выложить тут менее объемную базу?

[Bynthtcyj]

Я немного планировал испоьзовать такую БД. Но все же лпределитесь с лицензией.
Хотя реально использовать все же не смогу так как реальные бесплатные хостинги уже есть с анлим Мускул-базами, но ограничивают до смешного размер файла на диске (не Мускул-базы)

[Юрий Насретдинов]

Проект теперь находится на Google Code, причём идет работа по добавлению поддержки SQL:

code.google.com/p/yndb/

P.S. Лицензию я планирую сделать BSD-style, что даёт возможность даже продавать решения, которые используют мою БД, со своими модификациями, без необходимости выкладывать свои изменения где-либо.

[Александр Михалицын]

Собственно пишу в этой теме, потому что мой вопрос напрямую связан с ней, видел по нету много холиваров на тему "files vs mysql", но ничего вразумительного там нет,
одни только стереотипы и никаких толковых объяснений сути. Собственно вопрос: может ли система хранения данных на пхп составить конкуренцию по скорости mysql'у при одинаковой нагрузке и одинаковом количестве данных (и понятно, что на одинаковых серверах (-:)?

[bæv]

Александр Михалицын wrote:

никаких толковых объяснений сути

— а какое объяснение требуется? Что скрипт, например, сортировки на php заведомо дольше будет выполняться, чем скомпилированная программа?

[Александр Михалицын]

bæv,
да нет же.

>сортировки на php заведомо дольше будет выполняться, чем скомпилированная программа?
а как же тогда высоко-нагруженные проекты, где форумы/сайты работают на файловой БД (написанной на PHP)?

forum.ixbt.com например.

Last edited by Александр Михалицын on Wed Mar 10, 2010 2:16 pm; edited 1 time in total

[bæv]

Александр Михалицын wrote:

а как же тогда высоко-нагруженные проекты, где форумы/сайты работают на файловой БД (написанной на PHP)? forum.ixbt.com

— это должно было быть ссылкой куда-то?

[Александр Михалицын]

bæv,
это должно было быть примером. (-: Исправил.

[dimagolov]

Александр Михалицын, Вы бы привели ссылку не на сам форум, а на информацию о том, на чем он реализован.

[bæv]

dimagolov wrote:

а на информацию о том, на чем он реализован

— именно.

[Юрий Насретдинов]

Александр Михалицын wrote:

Собственно вопрос: может ли система хранения данных на пхп составить конкуренцию по скорости mysql'у при одинаковой нагрузке и одинаковом количестве данных (и понятно, что на одинаковых серверах (-:)?

Ну, я думаю понятно, что:

1. Сам по себе MySQL работает быстрее многих других реляционных СУБД (которые тоже написаны отнюдь не на PHP), но предлагает меньше возможностей
2. Большую роль в любой СУБД играет её архитектура, а именно работа с системой ввода-вывода и хранения данных, кеширование и т.д.
3. При работе с файловыми операциями (fopen/fread/flock/fclose) PHP работает с той же скоростью, что и C -- разница в производительности минимальна
4. Обработка сложных "хитрозакрученных" SQL-запросов является слабым местом в производительности любой реляционной СУБД, и для скриптовых языков вроде PHP это будет особенно заметно
5. Сам по себе PHP предоставляет ненамного меньше возможностей, чем C, а значит в нём можно использовать общепринятые механизмы блокировок / организации хранения данных
6. Реализация очень сложной логики для СУБД на PHP на данный момент не представляется осмысленной из-за того, что одни и те же операции в PHP могут быть в 100 раз медленней, чем на C

Отсюда вывод: скорее всего MySQL будет быстрее в любом случае, но насколько -- сильно зависит от типов запросов, которые подаются в базу данных.
Выборки по первичному ключу или поиск по одному индексированному полю являются "легкими" запросами для СУБД, и производительность таких выборок у моей СУБД в среднем в 1-5 раз меньше, чем у MySQL, что лично я считаю вполне достойным результатом.

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

Так что как-то вот так.

[nazar-pc]

Здравствуйте!
Заинтересовал Ваш проект, он ещё развивается? Прочитал всю тему, но посты не самые свежие...
Я разрабатываю собственную CMS, и хотел бы там сделать возможность создавать сайты маленького размера без MySQL или подобной, но для этого необходима SQL-совместимая БД на PHP. Нагрузка на базу в таком виде будет невелика, так, как всё, что только можно стараюсь кешировать.
Интересно, как обстоят дела с обработкой SQL запросов, и если поддержка уже есть - то на каком уровне?
В моей CMS есть общий интерфейс работы с БД, и нужно будет просто написать типа драйвер для вашей в случае чего...
В любом случае жду ответа.

[Юрий Насретдинов]

Поддержки SQL нет пока что, и будет нескоро. Следить за изменениями можете на сайте проекта code.google.com/p/moosql

[nazar-pc]

Спасибо