Comments 16
Насколько понятна ваша мотивация — вы создали базу данных, которая объективно по производительности и функциональности хуже для того, чтобы она взаимодействовала с библиотекой так, как вам этого хочется?
{ макро с картинкой про троллейбус }
{ макро с картинкой про троллейбус }
Такие базы обычно используют в тестах.
Основная мотивация это встраиваемая в процесс nosql база данных не требующая ничего кроме JavaScript. Т.е. отсуствие зависимости от внешних (часто тяжелых) сервисов/библиотек. В этом смысле даже sqlite можно назвать тяжелой зависимостью для JavaScript поскольку она является нативной библиотекой.
По мимо прочего хотелость надежности и легкости в резервном копировании. В контексте того к чему мы шли — это резервное копирование приложения вместе с данными с помощью банального rsync-backup. В таком ключе обновляя приложение, даже если произошли обновления данных очень легко откатываться назад (в случае ошибки например). Т.е. код получается синхронизирован с данными.
Полная совместимость с MongoDB по сути была вторична и не являлась основной целью. Так скажем решили просто не рисковать. В конечном итоге правда это помогло обзавестись несколькими сотнями тестова «за так», просто взяв из проекта нативного драйвера. Сразу кстати скажу есть другие библиотеки которые пишут что они реализуют MongoDB API ( github.com/mWater/minimongo, github.com/louischatriot/nedb). Это не так, они далеки от этого. Наша совместима настолько что «легким движением руки» ее удалось подсунуть в mongoosejs.com.
Что касается производительности, для объема данных который разумен именно для встраиваемой базы данных он вполне на уровне. Кроме прочего это для сервера важно 5 или 10 мс занял запрос. Для десктоп приложения (например собраного на nwjs.io) это фактически без разницы. С другой стороны ставить полноценную MongDB на дексктоп в довесок к небольшому приложению как бы перебор. Ну и например для малюток типа raspberry pi настоящая mongodb может быть тяжеловата.
Как то так. Заранее извиняюсь за поздний ответ, пост проболтался в песочнице больше полутора лет и о том что его опубликовали я узнал случайно.
По мимо прочего хотелость надежности и легкости в резервном копировании. В контексте того к чему мы шли — это резервное копирование приложения вместе с данными с помощью банального rsync-backup. В таком ключе обновляя приложение, даже если произошли обновления данных очень легко откатываться назад (в случае ошибки например). Т.е. код получается синхронизирован с данными.
Полная совместимость с MongoDB по сути была вторична и не являлась основной целью. Так скажем решили просто не рисковать. В конечном итоге правда это помогло обзавестись несколькими сотнями тестова «за так», просто взяв из проекта нативного драйвера. Сразу кстати скажу есть другие библиотеки которые пишут что они реализуют MongoDB API ( github.com/mWater/minimongo, github.com/louischatriot/nedb). Это не так, они далеки от этого. Наша совместима настолько что «легким движением руки» ее удалось подсунуть в mongoosejs.com.
Что касается производительности, для объема данных который разумен именно для встраиваемой базы данных он вполне на уровне. Кроме прочего это для сервера важно 5 или 10 мс занял запрос. Для десктоп приложения (например собраного на nwjs.io) это фактически без разницы. С другой стороны ставить полноценную MongDB на дексктоп в довесок к небольшому приложению как бы перебор. Ну и например для малюток типа raspberry pi настоящая mongodb может быть тяжеловата.
Как то так. Заранее извиняюсь за поздний ответ, пост проболтался в песочнице больше полутора лет и о том что его опубликовали я узнал случайно.
UFO just landed and posted this here
Кажется, minimongo это что-то в эту сторону.
Я бы чуть иначе написал.
Как обычно бывает, нам захотелось сделать модно и на NoSQL
Вот так лучше. В обычной ситуации люди не заморачиваются и поднимают SQLite :)
Как обычно бывает, нам захотелось сделать модно и на NoSQL
Вот так лучше. В обычной ситуации люди не заморачиваются и поднимают SQLite :)
SQLite не есть NoSQL база данных, это во-первых. Во-вторых это бинарная зависимость (нативная библиотека) и мы очень хотели не иметь таких зависимостей.
Ну и к слову, NoSQL это не модно, а удобно, в особенности в JavaScript. Ну так для простоты просто получается прямая цепочка передачи JSON (Бразуер — Сервер — База). Но о вкусах как говорится не спорят, кому то нравится SQL + ORM.
Ну и к слову, NoSQL это не модно, а удобно, в особенности в JavaScript. Ну так для простоты просто получается прямая цепочка передачи JSON (Бразуер — Сервер — База). Но о вкусах как говорится не спорят, кому то нравится SQL + ORM.
Для одного из проектов понадобился встраиваемая БД, скулйат использовать не хотел, так как хотел в случае чего переключиться на использование монги. Остановился на nedb, из очевидных минусов — хранит все данные в JSON-виде, и ни разу не бинарном, все состояния после операций так же хранятся в файле(все состояния после инсертов, апдейтов и прочее), ну и как это обычно бывает, грузит все данные в память.
На будущем проекте обязательно попробую вашу БД.
На будущем проекте обязательно попробую вашу БД.
Данные мы храним похожим образом, в текстовых небинарных файлах. Перед тем как остановится на этом мы перепробовали и оттестировали несколько вариантов, и именно такой оказался наиболее быстрым. Звучит странно, но JSON это нативный способ сериализации для JavaScript и очевидно допиленный до совершенства.
Также старые записи хранятся в файле. Это продиктовано необходисомтью гарантировать надежность, а именно полную порчу базы данных в случае непредвиденного завершения. Правда существует процедура автоматический оптимизации (очистки мусора).
Вот что важно, данные все в памяти не хранятся, только индексы и кэш. Кроме прочего github.com/louischatriot/nedb API только похож на MongoDB но не совместим с ним не разу. Наша база подсовывается в mongoosejs.com и он этого не замечает.
Также старые записи хранятся в файле. Это продиктовано необходисомтью гарантировать надежность, а именно полную порчу базы данных в случае непредвиденного завершения. Правда существует процедура автоматический оптимизации (очистки мусора).
Вот что важно, данные все в памяти не хранятся, только индексы и кэш. Кроме прочего github.com/louischatriot/nedb API только похож на MongoDB но не совместим с ним не разу. Наша база подсовывается в mongoosejs.com и он этого не замечает.
rethinkdb.com
Не вполне понятно, почему «хранение данных в памяти» считается недостатком. Хассо Платтнер* уже давно показал, что с текущим соотношением быстродействия оперативки и накопителей и их возможностями масштабирования — данные в памяти хранить не только можно, но и нужно; а на дисках — по сути дела бэкапы. *(see open.hpi.de/courses/imdb2015 for details)
наверное, потому что, обычно, памяти всегда меньше, чем данных. и заканчиваться она может быстрее, чем диск
Ну, вы вполне можете воткнуть очень много памяти и маленький диск, так что технически это не обязательно так)
Но вообще это вопрос того, что где хранить. Очевидно, что библиотеку изображений никто в памяти держать не будет, а вот какие-то текстовые данные, к котором постоянно идут обращения — только так, места они много не отнимают
Но вообще это вопрос того, что где хранить. Очевидно, что библиотеку изображений никто в памяти держать не будет, а вот какие-то текстовые данные, к котором постоянно идут обращения — только так, места они много не отнимают
Sign up to leave a comment.
Встраиваемая JavaScript база данных с прицелом на API совместимость с MongoDB