open-rethinkdb mid-november 2016: https://docs.google.com/document/d/13TsZoWckcvJpprpL1zU54xsf0Zqm8mfmLkCHZcZbTMI/edit
correction, not open-source since it already is - but to "community maintained" or whatever else you want to call it
(see the google doc report)
1 us
I want to write it on my webpage
@LucasBadico if the images are stored inside rethinkdb, you would want to base64 encode the data and put the encoded image as follows: https://css-tricks.com/data-uris/
And works!
thanks!
not sure
jimmy
now its under the Apache license.
Corps tend to drop GPL like the plague
@ghost202 My company logs about 16 million API log messages a month to a rethink cluster (3 nodes). I can tell you, it's got it's ups and downs, and we're switching to a straight up ELK stack. Rethink struggles to search once the table hits about 30 or 40 million records (~250gigs per node). We could throw hardware at the problem, and optimize some things, but ELK is much more tailor made for this usecase.
I can't really say how many didn't want to use it because of the license, I'm sure there were some, but to say nobody wanted to use it surely is not accurate. I'm only basing this on my own observations on the community. I'm pretty sure I didn't see anyone complaining about the license before the company shut down. After that happened, the licensing became pretty much the only issue people were concerned. After that was dealt with, I haven't seen significant rise in adoption. Tho that's not really fair comparison, because some of the people who were not satisfied with the license might not be interested in rethinkdb because of the fact that the company shut down
@Morgul I don't have any hard numbers to compare elastic to rethinkdb on ... well any use cases, but one thing to consider would be space usage if you have large data sets. As it is now, rethinkdb deoesn't compress anything and it's almost wastefull. I have a database of 100GB+ and the dump of that is in a range of 1.5GB or something similar.
and as you say, elastic is very good at those work loads
@chovy I would also like to point out that mongo is still AGPL licensed and I'm pretty sure no one ever said Mongo has had hard time being adopted by people and companies. Same goes for BerkeleyDB and others: https://en.wikipedia.org/wiki/List_of_software_under_the_GNU_AGPL
@ha1331 Yeah our workload contains a bunch of geojson, which tends to be highly compressible, but as we're using rethink just for logging, we couldn't (well, didn't) clue rethink in on which bits were geometries and which weren't, so I think that our comparison ended up being rather unfair to rethink. Though, I can say that everyone loved ReQL, and we're a little sad to lose it. Still, we basically thoroughly abused a rethink cluster that we started with nothing but the defaults and honestly probably have it on some underpowered vms... and it's just handled it for the last year and a half. I mean, I can't complain too loudly, and it really underscores how well rethink works "out of the box". You can do some pretty nasty things to it and it just keeps going.
Does anyone know why my table would have a key called
args
that has a bunch of descendants called
args?
I can’t figure out if its a rethink query doing this or something else.
it seems to get worse over time. with an update.
I believe its this statement when updating an existing doc
const res = await this.r.table('products').insert(item, {
conflict: (id, oldDoc, newDoc) => {
return Object.assign(item, oldDoc.merge(newDoc.without("createdAt")));
},
returnChanges: true
})
.run(this.conn);
oldDoc.args exists