我喜欢像CouchDB这样的面向文档的数据库.我正在寻找简单的模拟.
我的要求就是:
我不需要的是REST/HTTP接口(我将在进程中使用它).此外,我不需要所有可扩展性的东西.
据我了解,您可以将任何非结构化信息输入到面向文档的数据库中.让我们想象一下这样的文档:
{
name: 'John Blank',
yearOfBirth: 1960
}
稍后,在新版本中,此结构将重构为
{
firstname: 'John',
lastname: 'Blank',
yearOfBirth: 1960
}
如何使用面向文档的数据库执行此操作？您是否必须准备合并脚本,这会改变数据库中的所有条目？或者有更好的方法可以处理结构的变化吗？
只是想知道在设计面向文档的数据库时是否有任何指导方针,我特别谈到CouchDb.
我知道无模式的东西可以采取我们想要的形状但是,有没有最好的做法？
提前致谢!= d
我正在尝试使用cbdocloader 工具将多个 JSON 文档从 zip 文件添加到我的 couchbase 服务器（每个 JSON 文档都在它自己的文件中，并且该文件以 id.json 命名）。使用以下命令语法
./cbdocloader -n localhost:8091 -u Administrator -p xxx -b ships -s 100 ~/json-docs.zip
但是，我收到以下回复
[2015-08-21 21:08:35,522] - [rest_client] [140411799267072] - INFO - existing buckets : [u'beer-sample', u'default']
[2015-08-21 21:08:35,530] - [rest_client] [140411799267072] - INFO - http://localhost:8091//pools/default/buckets with param: proxyPort=11211&bucketType=membase&authType=sasl&name=ships&replicaNumber=1&saslPassword=&ramQuotaMB=100
[2015-08-21 21:08:35,543] - [rest_client] [140411799267072] - ERROR - http://localhost:8091//pools/default/buckets error 400 reason: Warning: you do not have enough servers to support this number of replicas., RAM quota specified …我正在使用以下视图函数来迭代数据库中的所有项目(以便查找标记),但我认为如果数据集很大,性能非常差.还有其他方法吗？
def by_tag(tag):
return '''
function(doc) {
if (doc.tags.length > 0) {
for (var tag in doc.tags) {
if (doc.tags[tag] == "%s") {
emit(doc.published, doc)
}
}
}
};
''' % tag
使用CouchDB,我目前有一个代表一个想法的文档,你可以评价这个想法.每个想法都是一个文档,每个评级都是一个不同的文档.我这样做是为了避免在人们评价想法时出现并发访问问题.
我的文档看起来像那样(我简化了它们):
一个主意:
{
"_id": "idea1",
"title": "A great idea"
}
评分:
{
"_id": "rating1",
"rating": 1,
"author": "author1"
}
{
"_id": "rating2",
"rating": 1,
"author": "author2"
}
我目前使用reduce函数来返回我的想法ID和他/她的评级(一个简单的评级总和):
地图:
function(doc) {
if (doc.type == "rating")
emit(doc.idea_id, doc.rating);
}
降低:
function(keys, values, rereduce) {
return sum(values);
}
我的问题是:我如何"加入""想法"文档,其中减少的结果代表了该想法的评级？
我需要在一个小型数据库(64MB)上做一些基准测试,我需要弄清楚用PyMongo将整个Mongo集合提取到python对象的最聪明的方法是什么？在JavaScript中,有toArray()方法但我在python中找不到类似的东西.提前致谢!
在数据库使用方面,过去十年是ORM的时代,数百人争相在普通的老式RMDBS中坚持我们的对象图.现在,我们似乎正在目睹面向文档的数据库时代的到来.这些 数据库针对无架构文档进行了高度优化,但对于它们并行扩展和查询群集的能力也非常具有吸引力.
面向文档的数据库与RDBMS相比还具有一些优势,可以在面向对象的设计中保持数据模型的持久性.由于表是无模式的,因此可以将属于不同类的对象并排存储在继承层次结构中.此外,随着域模型的更改,只要代码可以处理从旧版本的域类中获取对象,就可以避免在每次更改时都迁移整个数据库.
另一方面,面向文档的数据库的性能优势主要出现在存储更深层文档时.在面向对象的术语中,由其他类组成的类,例如,博客文章及其注释.在大多数这样的例子中,我可以提出,例如博客,读取访问的收益似乎被每次新评论时必须写整个博客文章"文档"的惩罚所抵消.添加.
在我看来,面向文档的数据库可以为面向对象的系统带来显着的好处,如果一个人非常小心地组织深度图中的对象,这些图是针对数据读写方式而优化的,但这意味着了解用例面前.在现实世界中,我们经常不知道,直到我们实际上有一个实时实现,我们可以分析.
那么关系型和面向文档的数据库是一个波动和环形交叉口的情况吗？我对人们的意见和建议感兴趣,特别是如果有人在面向文档的数据库上构建了任何重要的应用程序.
如果您使用无模式数据库(特别是面向文档的数据库,如CouchDB,Couchbase,MongoDB)并希望更改特定对象的数据表示格式,则可以保留旧格式的现有记录并以新格式创建新记录.它被宣布为无模式数据库的主要优势之一(我认为因为你可以避免停机).另一方面,处理同类数据的许多格式是不方便和低效的.那么在无模式数据库中将数据从一种格式迁移到另一种格式的好方法/策略是什么？
data-migration document-oriented-db schemaless nosql couchbase
大家都说mongoDB是CAP定理中的CP!但是使用主从复制时,它也具有高可用性(如果主要失败,其余成员将自动尝试选择新的主要).我的问题是,在哪些情况下(以及如何)它可以拥有AP(具有最终一致性)？
我在电子应用程序上使用pouchDb.在传递给pouchDb之前,数据存储在postgres数据库中.在某些情况下,要弄清楚如何以文档方式构建数据并不难.
我主要担心的是关系.例如:
我有数据类型项目,项目有很多事件.现在我在每个事件上都有一个名为project_id的字段.因此,当我想要获得ID为'project/1'的项目的事件时,我会这样做
_db.allDocs({
include_docs: true,
startkey: 'event',
endkey: 'event\uffff'
}).then(function(response){
filtered = _.filter(response['rows'], function(row){
return row['doc']['project_id'] == 'project/1'
});
result = filtered.map(function(row){
return row['doc']
})
});
我已经读过这allDocs是性能最好的API,但是,在这种情况下是否有更方便的视图？
另一方面,当我显示包含所有项目的列表时,每个项目都需要显示它具有的事件数.在这种情况下,我似乎必须再次运行allDocs,include_docs: false以便计算项目所具有的事件数.
有观点会改善这种情况吗？
另一方面,我正在考虑在Project文档中创建一个包含所有事件ID的数组,以便我可以轻松计算它有多少事件.在这种情况下,我应该使用allDocs吗？有没有办法将ID数组传递给allDocs？或者更好的是在该数组上使用循环并为每个id调用get(id)？
这种方式比第一种更有效吗？
谢谢!
由于它的规范化,我在MySQL数据库方面遇到了一些性能问题.
我使用数据库的大多数应用程序都需要执行一些重型嵌套查询,在我的情况下需要花费大量时间.使用索引运行查询可能需要2秒钟.没有索引约45秒.
几个月前我遇到的一个解决方案就是使用更快,更线性的基于文档的数据库,在我的案例中,Solr作为主数据库.一旦MySQL数据库中的某些内容发生了变化,就会通知Solr.
这非常有用.使用Solr数据库的所有查询只需要大约3 毫秒.
数字看起来不错,但我遇到了一些问题.
MySQL数据库大约200mb,Solr db包含大约1.4Gb的数据.每次我需要更改表/列时,数据库都需要重新编制索引,在此示例中需要花费12个小时.
视图依赖于某个对象.它不关心它自身的对象是Active Record对象还是Solr对象,只要它可以在它上面调用一组属性.
像这样.
# Controller
@song = Song.first
# View
@song.artist.urls.first.service.name
在我的情况下,问题是从Solr返回的数据是这样的平坦.
{
id: 123,
song: "Waterloo",
artist: "ABBA",
service_name: "Groveshark",
urls: ["url1", "url2", "url3"]
}
这迫使我构建一个可以传递给视图的活动记录对象.
我的问题
有没有更好的方法来解决这个问题？某种可以快速处理复杂查询的超级快速主要只读数据库会很好.