Author |
Message |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Sat Jan 10, 2009 6:48 am (написано за )
Post subject:
|
|
Не всегда есть желание и необходимость ставить базы вроде MySQL, а производительность у SQLite тоже не блещет. Касательно работы веб-сервера, моя база расширения SQLite не требует (у меня на сервере его например не стоит). Так что, не знаю...
|
|
Back to top |
|
 |
nerezus
Заглянувший
Joined: 09 Jan 2009
Posts: 5
Карма: -2 поощрить/наказать
|
Posted: Sun Jan 11, 2009 5:00 am (спустя 22 часа 12 минут; написано за 26 секунд)
Post subject:
|
|
> у меня на сервере его например не стоит А в чем проблема поставить его или мускул тот же, раз есть свой сервер?)
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Sun Jan 11, 2009 8:17 am (спустя 3 часа 16 минут; написано за )
Post subject:
|
|
Ну, вообще, моя БД актуальна для бесплатных хостингов или же хостингов, где есть дешевые тарифы без мускула. Также я планирую использовать свою БД для хранения базы пользователей и, может, какой-либо еще информации для своего файлового менеджера. Также, иногда бывает, что база данных вроде мускула "падает" или достигается лимит подключений к ней. И мою БД можно использовать в качестве "запасного варианта", а не придумывать свою реализацию для хранения информации какую-то самодельную БД, ибо моя база достаточно легко справляется с базой, сопоставимой по размерам с базой этого форума и масштабируется далее. Чего нельзя сказать про всякие "plain text" базы, которые обычного первыми приходят на ум разработчикам своих форматов хранения информации в БД. Ну и база сама гарантирует, что данные не будут повреждены при одновременном доступе, что тоже не всегда так для самодельных скриптов.
|
|
Back to top |
|
 |
Melethron
Заглянувший
Joined: 11 Mar 2009
Posts: 13
Карма: 0 поощрить/наказать
|
Posted: Fri Apr 17, 2009 10:39 pm (спустя 3 месяца 6 дней 14 часов 22 минуты; написано за 32 секунды)
Post subject:
|
|
А как решена проблема при одновременном обращении к таблице?
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Fri Apr 17, 2009 10:49 pm (спустя 9 минут; написано за 26 секунд)
Post subject:
|
|
Melethron
Блокировки. php.net/flock
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Fri Jul 17, 2009 8:23 pm (спустя 2 месяца 29 дней 21 час 34 минуты; написано за 14 минут 59 секунд)
Post subject:
|
|
После достаточно долгого «застоя», была переделана система индексов, теперь вместо двоичного дерева используется 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 сек). База данных и онлайн-пример доступны по требованию (пишите в ЛС).
Description: |
Данный код приводится для ознакомления и не рекомендуется к использованию в важных проектах, несмотря на то, что ошибок в реализации быть не должно. |
|
 Download |
Filename: |
YNDb-latest.zip |
Filesize: |
10.76 KB |
Downloaded: |
699 Time(s) |
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Wed Jul 22, 2009 1:59 am (спустя 4 дня 5 часов 35 минут; написано за 23 минуты 27 секунд)
Post subject:
|
|
Добавлена первичная поддержка удаления из Б-дерева (возможны проблемы при удалении сразу всех значений, а также возможно образование «мертвых блоки», на которые нет ни одной ссылки, при удалении количества значений порядка L^2 (около 7000)). После удаления значения из Б-дерева оно не балансируется; место, которое занимает Б-дерево на диске, также не возвращается обратно, но может быть повторно использовано, если количество удаленных записей было не слишком велико. Благодаря введению такой поддержки, операции update() и delete() добавлены обратно (обновление значения в индексе происходит в 2 этапа: удаление старой записи, а потом вставка новой), полностью переписанные, но с теми же недостатками, что и раньше -- невозможность увеличивать длину хранимых строк, невозвращение использованного места под запись в БД, отсутствие механизма повторного использования места из удаленных записей. Функция update() также может испортить индексы, если вы вставляете записи со значениями для UNIQUE и PRIMARY KEY полей, которые уже существуют в базе. Функция корректно возвратит ошибку «Duplicate unique/primary key», но часть индексов может к тому времени уже быть обновлена, что и вызовет порчу индекса. Сами данные при этом не портятся. При обновлении значений INDEX полей (а также при удалении значений из INDEX полей) остаются «пустые места» в индексе, которые не используются повторно. Количество кода заметно подросло (56 Кб), в основном за счет комментариев и отладочного кода. TODO:- перевод primary key на использование Б-дерева (появится возможность вставлять «свои» значения в индекс, возможность вставки значений, превышающих текущий auto_increment)
- более прозрачный механизм блокировки таблиц, добавление команды наподобие LOCK TABLES в MySQL (может существенно увеличить производительность вставки в БД, а также обеспечить атомарность операций, которые отсутствуют по тем или иным причинам в БД, к примеру, расширенной операции update или собственной реализации аналога REPLACE в MySQL)
- расширить синтаксис update(), чтобы он мог атомарно модифицировать значения в нужной записи, в том числе и основываясь на предыдущем значении, записанном в БД, аналог запроса "UPDATE ... SET some_counter = some_counter + 1 WHERE ..." в MySQL
- модифицировать методы insert() и update() таким образом, чтобы они не могли ввести БД в противоречивое состояние, когда файлы индексов не соответствуют данным
- аналог REPAIR TABLE для проверки целостности хранимых данных и, в случае чего, исправления ошибок
- аналог OPTIMIZE TABLE для устранения «пробелов» между записями, а также для перестройки индекса с той же самой целью
- аналог ALTER TABLE для изменения структуры таблицы, в которой уже есть данные
- <b>!important:</b> написание совместимого с синтаксисом MySQL парсера языка SQL для основных методов -- CREATE TABLE, INSERT, SELECT, UPDATE. В SELECT также постараться включить возможность использования JOIN'ов, хотя бы одного типа (LEFT JOIN).
Description: |
Код представлен для ознакомления с реализацией. На данном этапе использование в качестве полноценной замены MySQL не рекомендуется. Буду очень признателен за тестирование и нахождение багов в реализации, особенно при операциях с индексированными полями. |
|
 Download |
Filename: |
YNDb-latest.zip |
Filesize: |
14.43 KB |
Downloaded: |
688 Time(s) |
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Mon Aug 10, 2009 12:22 am (спустя 18 дней 22 часа 23 минуты; написано за 9 минут 41 секунду)
Post subject:
|
|
За счёт добавления нового «класса» 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 (при использовании всех возможных индексов) раза. Если Вы не используете индексы, то увеличение производительности может быть ещё большим.
Description: |
Содержит файлы с базой данных (основной класс YNDb и пара дополнительных), а также файлы для тестирования БД (test*.php) |
|
 Download |
Filename: |
YNDb-latest.zip |
Filesize: |
21.22 KB |
Downloaded: |
637 Time(s) |
|
|
Back to top |
|
 |
Александр Михалицын
Модератор
Joined: 23 May 2008
Posts: 1299
Карма: 83 поощрить/наказать
|
Posted: Wed Aug 26, 2009 12:51 pm (спустя 16 дней 12 часов 28 минут; написано за 53 секунды)
Post subject:
|
|
Юр, а как ставить твой форум без скачивания готовой базы? Можешь выложить тут менее объемную базу?
|
|
Back to top |
|
 |
Bynthtcyj
Guest
Карма: 388 поощрить/наказать
|
Posted: Tue Sep 22, 2009 12:11 pm (спустя 26 дней 23 часа 19 минут; написано за 3 минуты 9 секунд)
Post subject:
|
|
Я немного планировал испоьзовать такую БД. Но все же лпределитесь с лицензией. Хотя реально использовать все же не смогу так как реальные бесплатные хостинги уже есть с анлим Мускул-базами, но ограничивают до смешного размер файла на диске (не Мускул-базы)
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Tue Sep 29, 2009 10:22 pm (спустя 7 дней 10 часов 10 минут; написано за 1 минуту 27 секунд)
Post subject:
|
|
Проект теперь находится на Google Code, причём идет работа по добавлению поддержки SQL: code.google.com/p/yndb/
P.S. Лицензию я планирую сделать BSD-style, что даёт возможность даже продавать решения, которые используют мою БД, со своими модификациями, без необходимости выкладывать свои изменения где-либо.
|
|
Back to top |
|
 |
Александр Михалицын
Модератор
Joined: 23 May 2008
Posts: 1299
Карма: 83 поощрить/наказать
|
Posted: Mon Mar 08, 2010 7:42 pm (спустя 5 месяцев 8 дней 21 час 19 минут; написано за 3 минуты 38 секунд)
Post subject:
|
|
Собственно пишу в этой теме, потому что мой вопрос напрямую связан с ней, видел по нету много холиваров на тему "files vs mysql", но ничего вразумительного там нет, одни только стереотипы и никаких толковых объяснений сути. Собственно вопрос: может ли система хранения данных на пхп составить конкуренцию по скорости mysql'у при одинаковой нагрузке и одинаковом количестве данных (и понятно, что на одинаковых серверах (-:)?
|
|
Back to top |
|
 |
bæv
Модератор «Дзена»

Joined: 27 Aug 2003
Posts: 7275
Карма: 9986 поощрить/наказать
|
Posted: Mon Mar 08, 2010 8:11 pm (спустя 29 минут; написано за 1 минуту 13 секунд)
Post subject:
|
|
Александр Михалицын wrote: |
никаких толковых объяснений сути | — а какое объяснение требуется? Что скрипт, например, сортировки на php заведомо дольше будет выполняться, чем скомпилированная программа?
|
|
Back to top |
|
 |
Александр Михалицын
Модератор
Joined: 23 May 2008
Posts: 1299
Карма: 83 поощрить/наказать
|
Posted: Tue Mar 09, 2010 12:47 pm (спустя 16 часов 36 минут; написано за 2 минуты 2 секунды)
Post subject:
|
|
bæv, да нет же. >сортировки на php заведомо дольше будет выполняться, чем скомпилированная программа? а как же тогда высоко-нагруженные проекты, где форумы/сайты работают на файловой БД (написанной на PHP)? forum.ixbt.com например.
Last edited by Александр Михалицын on Wed Mar 10, 2010 2:16 pm; edited 1 time in total
|
|
Back to top |
|
 |
bæv
Модератор «Дзена»

Joined: 27 Aug 2003
Posts: 7275
Карма: 9986 поощрить/наказать
|
Posted: Tue Mar 09, 2010 10:13 pm (спустя 9 часов 25 минут; написано за 24 секунды)
Post subject:
|
|
Александр Михалицын wrote: |
а как же тогда высоко-нагруженные проекты, где форумы/сайты работают на файловой БД (написанной на PHP)? forum.ixbt.com | — это должно было быть ссылкой куда-то?
|
|
Back to top |
|
 |
Александр Михалицын
Модератор
Joined: 23 May 2008
Posts: 1299
Карма: 83 поощрить/наказать
|
Posted: Wed Mar 10, 2010 2:17 pm (спустя 16 часов 3 минуты; написано за 19 секунд)
Post subject:
|
|
bæv, это должно было быть примером. (-: Исправил.
|
|
Back to top |
|
 |
dimagolov
Участник форума
Joined: 04 Feb 2007
Posts: 1664
Карма: 96 поощрить/наказать
Location: Christ Church, Barbados
|
Posted: Wed Mar 10, 2010 3:57 pm (спустя 1 час 40 минут; написано за 31 секунду)
Post subject:
|
|
Александр Михалицын, Вы бы привели ссылку не на сам форум, а на информацию о том, на чем он реализован.
|
|
Back to top |
|
 |
bæv
Модератор «Дзена»

Joined: 27 Aug 2003
Posts: 7275
Карма: 9986 поощрить/наказать
|
Posted: Wed Mar 10, 2010 7:49 pm (спустя 3 часа 52 минуты; написано за 20 секунд)
Post subject:
|
|
dimagolov wrote: |
а на информацию о том, на чем он реализован | — именно.
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Fri Mar 12, 2010 12:28 pm (спустя 1 день 16 часов 39 минут; написано за 14 минут 25 секунд)
Post subject:
|
|
Александр Михалицын wrote: |
Собственно вопрос: может ли система хранения данных на пхп составить конкуренцию по скорости mysql'у при одинаковой нагрузке и одинаковом количестве данных (и понятно, что на одинаковых серверах (-:)? | Ну, я думаю понятно, что:- Сам по себе MySQL работает быстрее многих других реляционных СУБД (которые тоже написаны отнюдь не на PHP), но предлагает меньше возможностей
- Большую роль в любой СУБД играет её архитектура, а именно работа с системой ввода-вывода и хранения данных, кеширование и т.д.
- При работе с файловыми операциями (fopen/fread/flock/fclose) PHP работает с той же скоростью, что и C -- разница в производительности минимальна
- Обработка сложных "хитрозакрученных" SQL-запросов является слабым местом в производительности любой реляционной СУБД, и для скриптовых языков вроде PHP это будет особенно заметно
- Сам по себе PHP предоставляет ненамного меньше возможностей, чем C, а значит в нём можно использовать общепринятые механизмы блокировок / организации хранения данных
- Реализация очень сложной логики для СУБД на PHP на данный момент не представляется осмысленной из-за того, что одни и те же операции в PHP могут быть в 100 раз медленней, чем на C
Отсюда вывод: скорее всего MySQL будет быстрее в любом случае, но насколько -- сильно зависит от типов запросов, которые подаются в базу данных. Выборки по первичному ключу или поиск по одному индексированному полю являются "легкими" запросами для СУБД, и производительность таких выборок у моей СУБД в среднем в 1-5 раз меньше, чем у MySQL, что лично я считаю вполне достойным результатом. Если требуются сложные выборки с большим количеством джойнов, сложными группировками и т.д., про высокую производительность в этом случае можно забыть, и, более того, в моей СУБД поддержка каких сколько-нибудь сложных операций (в контексте SQL) просто отсутствует. Так что как-то вот так.
|
|
Back to top |
|
 |
nazar-pc
Заглянувший
Joined: 02 Jan 2011
Posts: 2
Карма: 0 поощрить/наказать
|
Posted: Sun Jan 02, 2011 8:25 pm (спустя 9 месяцев 21 день 7 часов 56 минут; написано за 5 минут 50 секунд)
Post subject:
|
|
Здравствуйте! Заинтересовал Ваш проект, он ещё развивается? Прочитал всю тему, но посты не самые свежие... Я разрабатываю собственную CMS, и хотел бы там сделать возможность создавать сайты маленького размера без MySQL или подобной, но для этого необходима SQL-совместимая БД на PHP. Нагрузка на базу в таком виде будет невелика, так, как всё, что только можно стараюсь кешировать. Интересно, как обстоят дела с обработкой SQL запросов, и если поддержка уже есть - то на каком уровне? В моей CMS есть общий интерфейс работы с БД, и нужно будет просто написать типа драйвер для вашей в случае чего... В любом случае жду ответа.
|
|
Back to top |
|
 |
Юрий Насретдинов
Модератор

Joined: 13 Mar 2003
Posts: 8642
Карма: 198 поощрить/наказать
Location: 007 495
|
Posted: Mon Jan 03, 2011 12:46 pm (спустя 16 часов 21 минуту; написано за )
Post subject:
|
|
Поддержки SQL нет пока что, и будет нескоро. Следить за изменениями можете на сайте проекта code.google.com/p/moosql
|
|
Back to top |
|
 |
nazar-pc
Заглянувший
Joined: 02 Jan 2011
Posts: 2
Карма: 0 поощрить/наказать
|
Posted: Mon Jan 03, 2011 12:56 pm (спустя 10 минут; написано за 7 секунд)
Post subject:
|
|
Спасибо
|
|
Back to top |
|
 |
|