Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Будет ли оно работать правильно с частыми одновременными операциями? Например, если штук 10-20 экземпляров скрипта попробуют добавить запись в одну и ту же таблицу?
нет не будет — однозначно нужны блокировки
Значит, особого толка от этой базы не будет и с тем же MySQL ее сравнивать несколько некорректно.
см мой последний комментарий,
говорю как разработчик БД (http://www.slideshare.net/akalend/treedb-keyvalue-nosql-database)
говорю как разработчик БД (http://www.slideshare.net/akalend/treedb-keyvalue-nosql-database)
БД отличается от библиотеки следующими признаками
— управление данными во внешней памяти (на дисках);
— управление данными в оперативной памяти с использованием дискового кэша;
— журнализация изменений, резервное копирование и восстановление базы данных после сбоев;
— поддержка языков БД (язык определения данных, язык манипулирования данными).
С MySQL сравнивать бессмысленно. Они в разных весовых категориях и предназначены для разных задач.
Кстати, самые быстрые настройки для PHP-скриптов habrahabr.ru/blogs/php/112402/
А как решается вопрос с безопасностью и чем же неудобно хранить данные настроек в БД?
А можно пример как выглядит БД? Я к тому, удобно ли что-то исправить быстро ручками
Мне кажется, получить данные из MySQL, обработать их json_encode и отдать клиенту — намного проще, чем пользоваться вашей библиотекой. В MySQL, по крайней мере, в простых случаях нет подводных камней.
имеет право существовать как альтернативное хранилище данных небольших объемов, при малом числе инициализаций (одновременных обращений ).
сложность обработки JSON круче линейной:
недостатки:
— нет одновременной обработки блока данных (подключений)
— нет блокировок
— необходимо всасывать все данные в память каждый раз (на каждую инициализацию, а это время в тестах не учтено) а следовательно большие накладные расходы (память на каждый экземпляр PHP).
следствие: плохо работать при большом числе подключений (клиентов) — начнет все виснуть
сложность обработки JSON круче линейной:
недостатки:
— нет одновременной обработки блока данных (подключений)
— нет блокировок
— необходимо всасывать все данные в память каждый раз (на каждую инициализацию, а это время в тестах не учтено) а следовательно большие накладные расходы (память на каждый экземпляр PHP).
следствие: плохо работать при большом числе подключений (клиентов) — начнет все виснуть
Рекомендации:
— хранить распарсенный JSON в шаредмемори
— добавить lock/unlock
— запустить демона, который делал переодически сохранял данные на диске
только в этом случае можно что-то говорить о «Базе», а так просто обертка над библиотекой по работе с json
— хранить распарсенный JSON в шаредмемори
— добавить lock/unlock
— запустить демона, который делал переодически сохранял данные на диске
только в этом случае можно что-то говорить о «Базе», а так просто обертка над библиотекой по работе с json
Зачем этот велосипед?
Для хранения настроек, а также для данных, к которым нужен максимально быстрый доступ, Facebook рекомендует использовать обычные php массивы в php файле, который замечательно закэшируется в том же apc и при доступе не потребует абсолютно никаких левых вызовов, как в этом примере.
Для хранения настроек, а также для данных, к которым нужен максимально быстрый доступ, Facebook рекомендует использовать обычные php массивы в php файле, который замечательно закэшируется в том же apc и при доступе не потребует абсолютно никаких левых вызовов, как в этом примере.
Автор пытается сделать свой вариант IndexedDb. Не самое удачное решение имхо.
Alert table -> Alter table
Я думаю всё-таки alter, а не alert? А то мне грешным делом подумалось, что вы JS alert этим методом делаете.
А зачем в такого вида БД четкая структура таблицы? Не лучше ли хранить для каждой записи свои поля, как в объекстных БД? Типа [{a:a, b:b, c:c},{a:1, c:2, d:3, e:4, f:5}].
И возможна ли тут выборка со сложными условиями (WHERE (a > b) OR (c > d AND d > e))?
И возможна ли тут выборка со сложными условиями (WHERE (a > b) OR (c > d AND d > e))?
Меня это решение заинтересовало потому, что уже разрабатывал работающую! систему на чем-то похожем ;)
habrahabr.ru/blogs/php/89298/
Если верить тестам — селекты по быстродействию мускулю не уступают, другое дело, что памяти много надо.
ИМХО данное решение может быть юзабельно для сайтов-визиток.
Наклепал дизайн, папку с кодом (и БД) залил на хостинг, получил бабло.
Было бы здорово, если бы автор применил-таки свое решение на реальном примере и похвастался!
habrahabr.ru/blogs/php/89298/
Если верить тестам — селекты по быстродействию мускулю не уступают, другое дело, что памяти много надо.
ИМХО данное решение может быть юзабельно для сайтов-визиток.
Наклепал дизайн, папку с кодом (и БД) залил на хостинг, получил бабло.
Было бы здорово, если бы автор применил-таки свое решение на реальном примере и похвастался!
И чем оно лучше CouchDB/Couchbase? Только тем, что не требует установки?
Позвольте кратко объяснить вам, почему единственное применеие данной билиотеки — развлечение автора, и почему она на порядки хуже даже какого нибудь монго.
Во-первых, любая операция update/delete/insert у вас полностью читает файл, десериализует (json не самый быстрый формат для этого, чем serialize не подошел?), изменяет его, сериализует и записывает назад (да, полностью). Несколько update на базе с 10000 записей легко загрузят даже мощный многоядерный процессор.
Во-вторых, разбор уонструкции Where сделан крайне неэффективно — мало того, что поиск записей проводится полным перебором (про индексы товарищ видимо никогда не слышал), так еще и проверка проводится лишним вложенным циклом.
Ну и про блокировки и журанлы тоже не слышал (хотя я журналы сам не люблю, они только производительность снижают здорово, а пользы от них ноль. Среднестатистическому сайту проще потерять несколько записей при аварийном отключении раз в год, чем тормозить и гудеть диском на каждой записи в базу, каждый день и каждую секунду, увы никто кроме меня этого не понимает).
В общем, закапывайте. Хотя что я переживаю, половина опен сорса так же сделана. Увы, современная молодежь безнадежно испорчена дешевыми гигабайтами и гигагерцами и делает все самым примитивным способом, не думая. Один пишет библиотеку, на каждый чих напрягающую процессор и диск, другой к прости господи, Gtk, прикручивает Питон и пишет плеер какой нибудь аналогичного качества, третий переходит на NET и RIA. Культура программирования еще никогда так низко не падала.
Ну а если хостер запрещает вам юзать MySQL (где вы такого откопали?), возьмите что ли sqlite. Он конечно тоже ужасен, в плане например скорости открытия базы, и у него очень тормозная операция записи (потому что sync() вызывает), но в разы, на порядки лучше этой библиотеки. И индексы умеет.
Во-первых, любая операция update/delete/insert у вас полностью читает файл, десериализует (json не самый быстрый формат для этого, чем serialize не подошел?), изменяет его, сериализует и записывает назад (да, полностью). Несколько update на базе с 10000 записей легко загрузят даже мощный многоядерный процессор.
Во-вторых, разбор уонструкции Where сделан крайне неэффективно — мало того, что поиск записей проводится полным перебором (про индексы товарищ видимо никогда не слышал), так еще и проверка проводится лишним вложенным циклом.
Ну и про блокировки и журанлы тоже не слышал (хотя я журналы сам не люблю, они только производительность снижают здорово, а пользы от них ноль. Среднестатистическому сайту проще потерять несколько записей при аварийном отключении раз в год, чем тормозить и гудеть диском на каждой записи в базу, каждый день и каждую секунду, увы никто кроме меня этого не понимает).
В общем, закапывайте. Хотя что я переживаю, половина опен сорса так же сделана. Увы, современная молодежь безнадежно испорчена дешевыми гигабайтами и гигагерцами и делает все самым примитивным способом, не думая. Один пишет библиотеку, на каждый чих напрягающую процессор и диск, другой к прости господи, Gtk, прикручивает Питон и пишет плеер какой нибудь аналогичного качества, третий переходит на NET и RIA. Культура программирования еще никогда так низко не падала.
Ну а если хостер запрещает вам юзать MySQL (где вы такого откопали?), возьмите что ли sqlite. Он конечно тоже ужасен, в плане например скорости открытия базы, и у него очень тормозная операция записи (потому что sync() вызывает), но в разы, на порядки лучше этой библиотеки. И индексы умеет.
Если уж так мил JSON, то сделайте иерархию в файловой системе и храните все данные в маленьких файликах JSON, только атрибуты одного звена иерархии. Файловая система будет работать быстрее, чем если Вы будете парсать все дерево JSON каждый раз при обращении. Мелкие файлики можно будет просто клеить в более крупные объекты обходя дерево — это быстрее, чем брать один огромный файл и распарсывать и потом сериализировать кусок из него для отдачи клиенту или обработки. Но подобных реализаций, я уверен, достаточно, это имеет смысл делать ради добывания опыта не прямым путем :) чтобы писать СУБД Вам еще нужно подучиться и набраться опыта. А за смелость — хвалю. Хоть и наивно все, но главное, что человек не боится делать что-то «системное», а то нынче уже и массивы сортировать разучились и про стек не слыхивали, а если заикнуться про оптимизацию логических операций через карты Карно, то вообще за динозавра посчитают. Вместо этого повсеместно видим if (VarName==true) {...} else {...} и т.д. Рекомендую читать Дональда Кнута, Гради Буча, как практиков и Глушкова с Винеро, как теоретиков. Проникнитесь системным программированием, тогда можно и к СУБД приступать.
чем mongodb не угодил?
Блин, вот бы я для своей СУБД писал на хабре о том, что скорость работы базы O(N) и приводил красивые графики с временем вставки 10 (!) записей по сравнению с MySQL… Причём и мою СУБД уважаемый egorinsk предлагал закопать, а ведь моя СУБД умеет и одновременную запись и масштабируется не на 10 записей, а, по сути, до упора (до технического ограничения в 2 Гб данных) — главное full scan не делать :)
Как-то не очевидны преимущества jdb перед SQLite ( у которого неслабая скорость, нормальный SQL интерфейс с PHP, индексы и много чего другого ). Странно, что в комментариях никто об этом не вспоминает.
Единственное отличие которое видно — возможность выкладывать json «базы» для чтения непосредственно на клиенте. Однако, это довольно экзотическое применение ( что происходит когда клиент пытается читать в тот момент когда скрипт работает с $jdb? ). К тому же того же самого можно добиваться, заворачивая ответ от SQLite в json_encode().
Единственное отличие которое видно — возможность выкладывать json «базы» для чтения непосредственно на клиенте. Однако, это довольно экзотическое применение ( что происходит когда клиент пытается читать в тот момент когда скрипт работает с $jdb? ). К тому же того же самого можно добиваться, заворачивая ответ от SQLite в json_encode().
Эм, это какой конфиг должен быть, что бы использовать БД для него отдельно?
Но как файловая база данных для несложных проектов — это самый удобный вариант.
Но как файловая база данных для несложных проектов — это самый удобный вариант.
Есть у кого-то живая ссылка на репозиторий?
Выло бы интересно глянуть что там было написано, а ссылка естественно мертвая.
Спасибо.
Выло бы интересно глянуть что там было написано, а ссылка естественно мертвая.
Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP / JSON база данных