- Интерфейс для написания плагинов. Расширять функциональность самой CouchDB - можно.
Об этом говорилось ещё в 2010 году и в документации есть парочка рабочих примеров. Можно, но... делать это - отвратительно! (Конечно, если Вы не гик и можете позволить себе жить процессом, а не результатом). Мне было не просто отладить свой плагин, лопативший базы и объединяющий их записи по определённым условиям: создавал его на JavaScript (под движок или SpiderMonkey или V8). Тем не менее, Scout, ElasticSearch, Lucene, BackBone и $.Couch (последняя пара - не совсем плагины, но очень полезные библиотеки) - показатели того, что создавать плагины можно. Этому способствует такой вот API (да, эта картинка). - Предметно-ориентированный язык программирования для создания индексов, функций проверки и т.п.. Это что-то вроде SQL. Хм... Для прикладных задач вполне годится JavaScript (или CoffeeScript - для ярых эстетов). Зачем усложнять? Впрочем, можно привести много причин "зачем"...
- Гибкая система разрешения конфликтов документов. Репликация - большая головня боль для разработчиков SQL-систем. NoSQL позволяет разработчикам сосредоточиться на задаче, взяв на себя большую часть сложностей репликации. Но отдавать роботам решать всё за нас - это не правильно (пока процесс не отлажен). Например, при репликации бывают моменты, когда документ изменён одновременно несколькими пользователями и каждый желает записать свои изменения в хранилище. Хотелось бы иметь что-то более настраиваемое, чем просто "получить список конфликтующих документов и выбрать вручную нужный".
- Хранение прикреплённых файлов вне базы. CouchDB хранит свои данные в одном файле. Этот файл при работе с базой никогда не становится меньше , данные никогда не перезаписываются (Вы можете только настроить периодическое сжатие файла). Это делает CouchDB очень надёжным хранилищем, но прикреплённые файлы сильно портят картину, т.к. при каждом обновлении документа, делается их полная копия... Да, места может потребоваться много. Это решается частичным обновлением документа (которого пока нет). Хранить файлы вне базы добавит сложностей в администрировании, но, видимо, есть задачи, когда без этого не обойтись: ведь этот пункт далеко не в конце списка необходимого в NoSQL.
- Определение целостности базы и восстановление в случае сбоев. Здесь имеется ввиду собрать вместе утилиты для контроля целостности и организовать удобный интерфейс для работы с ними. Потому что само хранилище CouchDB по надёжности сопоставимо с файловой системой. У Вас часто повреждаются хранимые на диске офисные документы? (Надеюсь, нет; иначе - пора бы обновить компьютер). Вот, так же "часто" будет "ломаться" база CouchDB. Впрочем, и здесь есть куда расти. Например, добавить хранение информации для восстановления файла; контрольные суммы на документы, B-деревья, представления; утилиты, позволяющие "распотрошить" поломанный файл CouchDB и вытащить оттуда всё, что ещё можно вытащить. Если Вам нужна большая надёжность, подключайте кластеры с BigCouch или посмотрите в сторону CouchBase - эти проекты выросли из CouchDB и ориентированы на потребности бизнеса.
^
Комментариев нет:
Отправить комментарий