couchdb 气垫船限制,将任意 erlang 术语存储到 Couchdb
Posted
技术标签:
【中文标题】couchdb 气垫船限制,将任意 erlang 术语存储到 Couchdb【英文标题】:couchdb hovercraft limitations, storing arbitrary erlang terms into Couchdb 【发布时间】:2010-06-22 08:52:56 【问题描述】:所以我一直在搞乱气垫船并遇到了一些令人讨厌的限制,这可能是由于内部 couchdb 将与文档关联的键/值对处理为不透明字符串(json 字符串)。
即: - doc _id 只能是二进制字符串 (utf8) - 此处不允许使用复杂的 erlang 术语 - 键/值对只能是二进制字符串或原子或列表(不允许元组或任意二进制文件)。
我期待在其中存储任意 erlang 术语,而不是先将它们编码为 JSON。是的,这是可能的,但随后整个视图系统(以及 http api、通知、验证、索引)停止工作。 这也很好,我可以围绕它进行编码,不使用蒲团,手动映射/减少文档并将结果存储为文档(实际上更好,因为这些结果可以复制到其他数据库/节点,不像视图结果(不复制 - 如果我错了,请纠正我))。
真正的问题似乎是,如果没有视图,就无法获得存储在数据库中的所有键的列表,至少不能通过当前的气垫船 api。这是在整个数据库上手动减少地图的展示停止器,而无需事先知道 doc _id 是什么。
关于如何在数据库中获取这些键的列表的任何想法?通过 erlang 调用,可能进入 couchdb 的内部?
现在对我来说更加明显的是,couchdb 的直接 erlang api 完全是后来的事情。
【问题讨论】:
我正在考虑切换到 Riak,看起来对 erlang 更友好 【参考方案1】:作为 Hovercraft 的作者,我同意“couchdb 的直接 erlang api 完全是事后”的说法。
只有在将 CouchDB 从 HTTP 服务器转换为 SMTP 服务器时,才应该使用 Hovercraft。 HTTP 将比 Hovercraft 更好地扩展。
应该可以使用内部 _changes API 来迭代数据库中的所有文档并逐步维护二级索引。
至于在 CouchDB 中存储非 JSON 数据,这听起来很冒险,因为没有人会注意确保我们不会破坏您的用例。
但是,如果您玩得开心,请务必继续。而且我喜欢为气垫船打补丁,所以任何小事情都可能会被退回。
谢谢, 克里斯
【讨论】:
以上是关于couchdb 气垫船限制,将任意 erlang 术语存储到 Couchdb的主要内容,如果未能解决你的问题,请参考以下文章